🦊 Современное состояние безопасности CI/CD и как предотвратить распространенные ошибки

Постоянно растущая потребность в более быстрой и структурированной разработке привела к тому, что инструменты CI/CD стали неотъемлемой частью процессов разработки в организации.

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

И с ростом числа функций и возможностей, которыми обладают инструменты CI/CD, они также требуют определенного уровня доступа для выполнения этих различных функций.

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

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

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

Вот почему использование неправильно настроенных или уязвимых инструментов CI/CD может привести к значительному увеличению поверхности атаки вашей организации.

Инциденты, связанные с безопасностью CI/CD

Нарушения в инструментах CI/CD часто происходят из-за неправильной конфигурации или устаревшего программного обеспечения.

Поскольку современные взломы часто автоматизированы, “автоматическому боту” (подобному тем, что пытаются войти в систему по SSH по всему интернету) не требуется много времени, чтобы начать сканирование узлов, на которых установлены устаревшие версии, либо с помощью захвата баннеров, либо просто перебором уязвимостей PoC на общедоступном CI/CD-инструменте.

Недавняя уязвимость в GitLab позволяла использовать серверы с устаревшими установками GitLab для проведения DoS-атак, что, помноженное на количество серверов с устаревшей версией GitLab, привело к DDoS-атакам в Интернете со скоростью более 1 ТБ/с.

Помимо рассылки интернет-атак (незаконное действие в большинстве стран), в GitLab были уязвимости, связанные с авторизацией, которые также позволяли неавторизованным пользователям войти в ваш инстанс.

Аналогично, были уязвимости, связанные с ACL, которые позволяли взломанным, но авторизованным учетным записям выталкивать и извлекать данные из зон несанкционированного доступа в вашем экземпляре GitLab.

Хотя эти уязвимости были устранены в будущих сборках GitLab, по-прежнему важно следить за обновлениями и, в свою очередь, обновлять свои экземпляры (чаще всего самостоятельно), чтобы уменьшить площадь атаки.

Аналогичным образом, популярный CI/CD-инструмент Jenkins с открытым исходным кодом в последнее время был обременен большим количеством CVE, начиная от XSS/CSRF-уязвимостей и заканчивая уязвимостями обхода разрешений, которые угрожают раскрыть конфиденциальную информацию злоумышленникам.

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

Недавняя уязвимость в Travis CI привела к тому, что переменные окружения внедрялись через pull request в виде файлов .travis.yml, а учитывая принцип работы Git, простого удаления файла из Git было недостаточно для защиты различных секретов проекта.

Аналогичным образом, даже если ваш Git-репозиторий был приватным и секреты не были утечены через сам репозиторий, если ваш процесс развертывания использует Git и клонирует репозиторий на производственный экземпляр, любой пользователь, имеющий доступ к вашему производственному веб-приложению, сможет загрузить или просмотреть файл .travis.yml, содержащий секреты вашего приложения/сборки.

Наиболее распространенные ошибки CI/CD, которые приводят к утечке данных и сетевым вторжениям

Захаркоженные учетные данные

Подобно тому, как человеку требуются определенные учетные данные для доступа к машине (например, серверу), чтобы развернуть на ней собранный код, инструменты CI и CD требуют аналогичного, если не такого же, уровня доступа для сборки и развертывания кода на производственных серверах.

Эти учетные данные, хранящиеся в системах CI/CD, могут быть любыми – от SMTP-серверов, используемых для отправки почтовых уведомлений о завершении сборки или ошибках сборки, до чего-то потенциально более опасного, например, доступа на уровне SSH/root к серверным системам, которые будут использоваться для развертывания собранного кода.

Рассмотрим пример CircleCI:

version: 2.1
executors:
  my-executor:
    docker:
      - image: cimg/ruby:3.0.3-browsers
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference

jobs:
  my-job:
    executor: my-executor
    steps:
      - run: echo outside the executor

В разделе auth для контейнера docker мы видим переменную $DOCKERHUB_PASSWORD, которая вводится/заменяется CircleCI в процессе сборки, так что пароль скрыт в самом конфигурационном файле.

Однако, если не использовать эти переменные и не определять пароль, учетные данные могут быть украдены, если конфигурационный файл по ошибке станет общедоступным.

Захардкоженные учетные данные являются распространенным источником компрометации, исходящей от систем CI/CD.

• 🦊 Добавление Gitleaks в пайплайн Gitlab CI
• 🌐 GitLab Watchman – Аудит Gitlab на предмет конфиденциальных и учетных данных

Неправильно сконфигурированные контейнеры

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

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

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

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

см. как проверить Docker:

• 🐳 Сканирование образов Docker на наличие уязвимостей с помощью Trivy
• 🐳 Как проверить изменения в файловой системе контейнера Docker
• 🐳 dockle: линтер + проверка образов на безопасность
• 🐳 Обзор сканеров безопасности контейнеров для поиска уязвимостей
• 🐳 Как использовать Harbor для сканирования образов Docker на наличие уязвимостей

Неправильная конфигурация или неправильное использование переменных окружения

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

Еще один источник неправильного использования переменных окружения связан с использованием Git, где в публичные репозитории часто попадают ошибочные коммиты, содержащие файлы .env, часто используемые для хранения переменных окружения.

Удаление этих файлов из Git’а считается решением проблемы, но учитывая, что Git содержит историю каждого файла и изменения, злоумышленникам не составит труда просмотреть историю репозитория и получить эти учетные данные из удаленных в прошлом файлов.

Поскольку члены команды работают по всему миру, команды часто полагаются на инструменты обмена сообщениями, такие как Slack, для публикации информации о состоянии сборки.

Jenkins использует пайплайны для улучшения процессов CI/CD с помощью функций, которые включают объявление статуса сборки через Slack во время или после процесса сборки; например:

import groovy.json.JsonOutput
// Add whichever params you think you'd most want to have
// replace the slackURL below with the hook url provided by
// slack when you configure the webhook
def notifySlack(text, channel) {
    def slackURL = 'https://hooks.slack.com/services/xxxxxxx/yyyyyyyy/zzzzzzzzzz'
    def payload = JsonOutput.toJson()
    sh "curl -X POST --data-urlencode \'payload=${payload}\' ${slackURL}"
}

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

Чтобы предотвратить подобные ситуации, URL-адрес хука должен быть настроен как секретный и не открываться открытым текстом в конфигурационных файлах.

Неправильно настроенные инструменты CI/CD

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

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

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

GitLab – это популярный инструмент с открытым исходным кодом, используемый для собственного хостинга Git и CI/CD.

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

Использование CircleCI требует создания конфигурационного файла в формате YAML под названием config.yml, который содержит различные “инструкции”, которым CircleCI следует для запуска процесса сборки.

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

Сейчас давайте рассмотрим конфигурацию CI:

version: 2.1

# Define the jobs we want to run for this project
jobs:
  build:
    docker:
      - image: cimg/<language>:<version TAG>
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
    steps:
      - checkout
      - run: echo "this is the build job"
  test:
    docker:
      - image: cimg/<language>:<version TAG>
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
    steps:
      - checkout
      - run: echo "this is the test job"

# Orchestrate our job run sequence
workflows:
  build_and_test:
    jobs:
      - build
      - test:
          requires:
            - build

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

Но если этот конфигурационный файл утечет из-за его публичной видимости в вашем репозитории GitHub, злоумышленники могут получить доступ к вашим приватным шаблонам контейнеров docker hub.

Аналогичным образом, популярное самораспространяемое CI/CD программное обеспечение GitLab недавно поставлялось с учетными данными по умолчанию для входа пользователя  root – “5iveL!”.

Поскольку этот пароль часто оставляли без изменений, многие GitLab неизбежно подвергались взлому.

Инструменты CI/CD, не являющиеся самостоятельными хостингами, также подвержены неправильной конфигурации.

CircleCI тоже можно очень легко неправильно сконфигурировать, выложив в открытый доступ config.yml проекта.

Этот config.yml содержит каждый шаг, который должен быть выполнен CircleCI, и может содержать имена хостов и другую конфиденциальную информацию, такую как SSH-ключи для производственных или тестовых развертываний, куда будет отправлен собранный код.

Устаревшие инструменты CI/CD

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

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

Заключение

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

Использование On Prem/SaaS-решений часто рассматривается как решение для снижения требований к безопасности организации, но, как показывает недавний опыт, размещенные/SaaS-инструменты также могут внести уязвимости безопасности в ваши проекты.

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

см. также:

🦊 GitLab настройка 2FA для всех пользователей