Что может пойти не так с CI/CD pipelines?

Непрерывная интеграция и непрерывная поставка (CI/CD) pipelineОни являются основой любой организации, занимающейся разработкой программного обеспечения, которая создает программное обеспечение «современным» способом. Автоматизация дает огромные возможности, но большинство разработчиков упускают из виду ответственность, которую она влечет за собой.

Застройщик: Да, мы берем CI/CD безопасность серьезно и иметь строгий контроль над сопровождающими кода, проверять commits перед слиянием; рабочие места и pipelineподдерживаются старшими сотрудниками, они следят за тем, чтобы секреты не разглашались. pipelineс. И инструмент был установлен персоналом, который знает это дело. Что может пойти не так?

Уважаемый разработчик, CI/CD Системы сложны. Широкая поверхность атаки привлекла злоумышленников. Лучше быть осторожным и никогда не быть самоуверенным.

Конфигурация по умолчанию иногда сохраняется и становится лучшим другом для хакеров. Критические недостатки могут присутствовать в CI/CD pipeline источников, в конфигурации системы или вокруг процесса и контекста pipeline и как это срабатывает.

В этом посте мы поставим себя на место плохих актеров. Представьте себе, что мы читаем размышления М3М3Н70 (Memento Mori?) и Болотная ярость где-то в даркнете, возможно, на незападном языке, но никогда не упускайте из виду, что зло распространяется по всему миру.

 

В старые добрые времена это было так просто…

М3М3Н70: Возвращаясь к старым добрым временам, наш бизнес был ооочень простым… Нулевые дни были легко висящими плодами, приложения были широко открыты с легко эксплуатируемыми уязвимостями, и мы могли мгновенно двигаться в сторону.

Болотная ярость: Фу#@Черт ! Некоторые еще были безумны, но все изменилось. Большие парни приложили много усилий к этому дерьму AppSec.

М3М3Н70: Да. Но новые дураки — это разработчики. Для нас было проще использовать инструменты, которые используют эти ребята. CI, в частности, — это золотая жила! Токены доступа к облаку, SCM учетные данные, пароли к производственной базе данных, закрытые ключи SSH, учетные данные других пользователей CI... Переход от скучных вопросов разработки к реальным вещам оказался довольно тривиальным.

Автоматизация для создания, тестирования и развертывания программного обеспечения с CI/CD Инструмент часто требует передачи секретов командам по шагам. И часто они просачиваются, с печально известными последствиями.

Pipelineнам нужны секреты, которые иногда раскрываются

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Возможно, в старые добрые времена в истории Git можно было найти .env файл (разработчик забыл добавить его в .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

который использовался в рабочем процессе GitHub .github/deploy.yaml там было что-то вроде этого:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: вау! Эти ключи aws работали! Сначала мы протестировали безобидное изменение в приложении, а затем добавили его, поскольку эти ребята, похоже, не знали об этом. Бинго! Какая кампания…

Злоумышленник просто использовал ключи AWS для загрузки модифицированного приложения с вредоносным ПО, а затем выполнил команду развертывания с такими учетными данными. Утечка секретов, а также информация, содержащаяся в pipeline. «Что за кампания!» вероятно, означает, что Мементо нанес ущерб бедной жертве.

Memento сообщает нам, что как только произошла утечка секрета, как в примере с ключами доступа AWS, вам необходимо отозвать секрет (повернуть указанные выше ключи). немедленно. Всегда есть окно экспозиции между утечкой commit и секретное аннулирование; переписать историю Git сложно (даже самое жесткое авторитарное государство пробовало такое переписывание истории, но безуспешно) и, вероятно, неэффективно (наши друзья могли бы клонировать раньше хранилища с секретной утечкой commit). Немедленно меняйте ключи и молитесь, читая журналы активности целевой учетной записи во время окна воздействия!

Вероятно, организациям следует запретить использование долгосрочных секретов в CI/CD pipelinesи замените их временными учетными данными. В предыдущем примере с ключами AWS в действиях GitHub безопаснее использовать Поставщик OpenID Connect (OIDC) для получения кратковременных учетных данных, необходимых для действий.

Болотная ярость: Тебе так повезло! Утечка скриптов с жестко закодированными ключами в прежние времена была обычной практикой, даже в общедоступных корзинах S3. Все, что вам нужно было сделать, это пройтись по объектам в ведре и выполнить поиск, чтобы найти интересные вещи.

Иногда область, используемая для развертывания (корзина AWS S3 в этом примере), была открыта для чтения посторонними из-за ошибки конфигурации (которая осталась незамеченной). Что Болотная ярость использовалось что-то вроде этого:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Корзина, вероятно, была создана в шаблоне обеспечения, который можно было автоматически сканировать на наличие недостатков безопасности.

Конфигурация инструмента по умолчанию была для нас игрушкой.

Чтобы привести конкретные примеры, давайте поговорим о Jenkins , один из самых популярных инструментов CI.

Болотная ярость: Помните этот флажок «Включить безопасность» в Jenkins и сколько организаций решили не активировать его ради удобства? И те "Любой может сделать что угодно» Комбинации разрешений по умолчанию? И эти надоедливые плагины Jenkins, такие как Плагин GitHub OAuth? Парень, который его настроил, выбрал «Предоставить разрешения на чтение всем аутентифицированным пользователям» и «Использовать разрешения репозитория GitHub», предоставив нам доступ ко всем их проектам.

(Извини, Дженкинс, что поставил тебя в пример 😉

Сохраняйте приверженность (даже приверженность) принципам безопасности. Одним из них является Безопасность по умолчанию принцип: элементы управления должны быть установлены по умолчанию на максимально безопасные настройки. Безопасность должна быть встроена в CI/CD инструменты и pipelineЭто с нуля, а не второстепенная мысль. Но дружелюбие и удобство часто вступают в противоречие с безопасностью.

В случае Дженкинса встроенная аутентификация слишком хрупка: никогда не используйте встроенные механизмы аутентификации в Jenkins. Лучше выбрать сторонний механизм (SAML, LDAP, Google…) с плагином стратегии авторизации на основе ролей («RBAC»). И будьте предельно осторожны с admin счет.

Позаботьтесь о том, как работает и pipeline обрабатываются файлы в Jenkins. То же самое с Плагин конфигурации как кода и его файлы конфигурации, которые применяются к конфигурации Jenkins.

Переход от самостоятельного размещения CI/CD систем в облачные SaaS-системы устраняет некоторые потенциальные риски, допускающие горизонтальное перемещение в сети организации, но добавляет другие, такие как необходимость открывать внешние соединения между существующими внутренними системами и внешними CI/CD инструмент.

Организации должны проявлятьcisе. Должная осторожность при закалке CI/CD системы, начиная с самых строгих настроек и постепенно открывая минимально необходимые разрешения для pipeline шаги.

Настройка безопасности в CI/CD инструменты могут быть сложным делом. Многие имеют плагины или расширения, которые имеют большинство уязвимостей и нуждаются в обновлении.

Сканеры неправильной конфигурации безопасности для таких сложных инструментов или тесты могут помочь.

Внедрение кода в pipeline команды для удовольствия и прибыли

М3М3Н70: Вы когда-нибудь использовали Untrusted Code Checkouts, уязвимые действия и сценарии, уязвимые для внедрения команд?

В этом разделе показано, что pipeline сам по себе может иметь ошибки в кодировании, которые позволяют злоумышленникам внедрить выполнение произвольного кода в pipeline без изменения pipeline сам источник. Например, используя PR

Первый пример неудачный рабочий процесс GitHub:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

Объединяя pull_request_target Триггер рабочего процесса с явной проверкой ненадежного PR — опасная практика, которая может привести к компрометации репозитория. В этом примере неудачная комбинация:

• pull_request_target событие, которое по умолчанию имеет разрешение на запись в целевой репозиторий и секреты целевого репозитория, даже из внешних форков, и запускается в контексте целевого репозитория PR,
• получить PR-код из источника, ненадежного репозитория,
• запускать любой сценарий, который может работать с контентом, контролируемым PR, как в случае с npm install и
• не использовать условие для запуска pull_request_target событие будет запускаться только в том случае, если PR присвоен какой-либо ярлык «этот PR был проверен» (внешние пользователи не могут назначать ярлыки PR).

Во втором примере используются ненадежные входные данные (из проблемы, комментария или pull request) как источник аргументов, передаваемых в pipeline команда через выражения. Это pipeline версия уязвимости внедрения команд ОС.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Операция запуска генерирует временный сценарий оболочки на основе шаблона с $ заменен, что делает его уязвимым для внедрения команд оболочки. Злоумышленник с поддельной учетной записью GitHub может создать проблему с заголовком. a"; bad_code_goes_here;#, и бум! 

Болотная ярость: О, эти ребята открыли дверь для внедрения команд, просто открыв задачу…

В действиях GitHub были уязвимости выполнения кода, например Gajira-комментарий, теперь исправлено. Пожалуйста прочти «Ненадежный ввод в рабочих процессах GitHub» для получения полной информации.

Мораль этой истории: Никогда не оформляйте заказ и не создавайте PR из ненадежных источников без предварительной проверки PR. «Недоверенный» здесь, за исключением случаев драконовской аутентификации происхождения, может означать любую потенциально взломанную учетную запись разработчика.

 

Здесь произошло непреднамеренное размещение вредоносного ПО!

Непрерывное развертывание — это кульминация автоматизации, но эта кульминация может быть сорвана из-за отсутствия надлежащего контроля за утверждением на pipeline потока.

Риски полностью автоматического развертывания из исходного кода commit для производственных систем включает возможность развертывания вредоносного кода в производственных средах без обнаружения, а также вероятность ошибок в процессе развертывания, которые могут привести к сбоям или сбоям в работе.

Чтобы смягчить эти риски, организациям часто рекомендуется сделать «жесткий перерыв» в процессе развертывания, что требует человеческое одобрение перед развертыванием выпусков в конечных средах.

Они закрывают двери

Болотная ярость: Эти радостные пароли по умолчанию в CI/CD Инструменты вытираются. Доступ к /var/lib/jenkins/secrets/initialAdminPassword теперь мертвый путь. Многие инструменты сейчас поддерживают 2FA, которую Covid сделал популярной, и даже самые ленивые программисты используют ее!

М3М3Н70: Мы боремся с 2FA, но это не так просто. Трудно атаковать этих ребят, так как «Scatter Swine» сделали с Twilio. С ключами WebAuthn все гораздо сложнее. По крайней мере, мы можем попытаться украсть файлы cookie, чтобы обойти MFA, но нужно взломать ящик разработчика.

Многофакторная аутентификация — хороший шаг в правильном направлении для ограничения риска утечки секретов аутентификации. Большинство современных инструментов DevOps поддерживают MFA. И ключи аутентификации под WebAuthn/U2F (см. проект ФИДО2), возможно, являются лучшим вариантом для MFA в DevOps, если им правильно управлять.

Болотная ярость: Ребята из DevOps просыпаются. У них в крови чертовы «наименьшие привилегии». И они больше не кодовые обезьяны. Теперь рецензенты ловят нас с поличным.

По факту, pipelineТеперь они стали немного более надежными, чем пару лет назад, с удаленными слабыми действиями и скриптами, а также с дополнительными этапами тестирования безопасности, которые даже обнаружили наши дропперы, скрытые скрытно. commitписьма и пакеты, которые мы угнали.

Вопрос к читателю: является ли процесс сборки ПО из исходников и развертывания в продакшен рискованным делом? Можете ли вы увидеть свой DevOps на стадии старые добрые времена для плохих парней?

Итоговые рекомендации

С чего начать CI/CD pipelineс?

Первая рекомендация здесь проста: внимательно обзоре pipelines (они есть критической ресурсы) по вопросам безопасности. Обзоры являются дорогостоящими, но необходимыми и должны проводиться надлежащим образом. Рецензенты должны знать, на что следует обратить внимание. Каждый шаг необходимо проверять на наличие недостатков.

Возможно, поможет группа экспертов-рецензентов, вооруженных автоматическими сканерами вредоносного кода.

Вторая рекомендация – обучать разработчиков, которые пишут pipelines и поддерживать их в безопасности. Что следует учитывать:

• Как правильно обрабатывать аутентификацию с помощью внутренних и облачных сервисов, избегая хлопот с обработкой долгосрочных учетных данных.
• Как ограничить pipelines к точному набору ресурсов, к которым ему необходим доступ. Принцип наименьших привилегий снова сияет.
• Как написать шаги, которые нужно сделать pipelineВоспроизводимость, как при закреплении версии, и позволяет избежать уязвимостей, связанных с внедрением команд.
• Как одобрять развертывания с точки зрения безопасности (они другие!): какая безопасность standards должны быть сопоставлены и как добавить соответствующие проверки/ворота в pipelines.

Третья рекомендация – настроить CI/CD система с должной осторожностью. Надежная аутентификация, отсутствие паролей по умолчанию и небезопасных настроек, минимальные привилегии… Позаботьтесь об уязвимостях в установленных плагинах и расширениях. Это может стать темой следующих публикаций, пожалуйста, следите за обновлениями.

Четвертая рекомендация – использовать CI/CD pipelineдля автоматизации безопасности. Анализ исходного кода (SAST), анализ состава источника (SCA), сканирование утечек секретов, инструменты защиты от вредоносных программ, сканеры безопасности контейнеров или автоматизированные детекторы времени выполнения (DAST и вредоносные программы) могут регулярно запускаться на pipeline. И ваша организация может применять standards о освещении сканирования безопасности в CI/CD.

Напоминаем, что эти инструменты не исключают экспертную оценку из уравнения, иначе у вас может возникнуть ложное чувство безопасности.

Если вы разбираетесь в десятках лучших OWASP, то вам стоит обратить внимание на недавний хороший проект. OWASP Top 10 CI/CD Угроза безопасности.

Примечание об отказе от ответственности

(1) Примеры в этом посте используют GitHub в качестве SCM, AWS как поставщик облачных услуг и GitHub Actions или Jenkins как CI/CD Инструмент. Они не слабее/безопаснее своих альтернатив. Никаких плохих намерений в прессе! Эти инструменты мощные и должны использоваться надлежащим образом.

(2) М3М3Н70 и Болотная ярость являются вымышленными персонажами. Любое сходство с людьми или группами, живыми или мертвыми, просто случайно… или нет?

Чтобы узнать больше

• Хеймор А. и др. «10 реальных историй о том, как мы пошли на компромисс CI/CD pipelines». Группа компаний NCC, январь 2022 г.
• configure-aws-credentials Действие GitHub и Настройка OpenID Connect в Amazon Web Services для получения подробной информации о том, как запускать команды AWS для развертывания в рабочих процессах GitHub.
• Лобачевский Я. «Обеспечение безопасности ваших действий и рабочих процессов GitHub. Часть 1. Предотвращение запросов pwn». Лаборатория безопасности GitLab, декабрь 2020 г.
• Лобачевский Я. «Обеспечение безопасности действий и рабочих процессов GitHub. Часть 2. Ненадежные входные данные». Лаборатория безопасности GitLab, январь 2021 г.
• ОВАСП. «OWASP Топ 10 CI/CD Риски безопасности””. июль 2022 г.
• Зальцер Дж. и Шредер М. «Защита информации в компьютерных системах». Апрель 1975 года. Принципы безопасности развивались вместе с технологиями, но 47 лет спустя большинство идей безопасности и безопасности остаются в силе.
• НКСК Великобритании. «Безопасность сборки и развертывания pipeline . Национальный центр кибербезопасности Великобритании, февраль 2019 г.