Исследователи из компании Wiz, специализирующейся на облачной безопасности, Юваль Аврахами и Нир Охфелд обнаружили критическую уязвимость под названием CodeBreach, затрагивающую систему Amazon Web Services (AWS) CodeBuild. Проблема заключалась не в самом сервисе CodeBuild, а в специфической неправильной конфигурации конвейеров непрерывной интеграции (CI), в частности, в фильтрах веб-хуков. Отчет об этом открытии был передан изданию The Hacker News, что пролило свет на серьезные риски в управлении процессами сборки программного обеспечения.
Техническая суть уязвимости крылась в механизме фильтрации веб-хуков AWS, предназначенных для того, чтобы только доверенные события инициировали сборку CI. Сбой произошел из-за некорректного использования регулярных выражений (Regex): шаблон не был правильно «заякорен» (anchored). Система должна была пропускать только конкретный идентификатор доверенной учетной записи GitHub или Enterprise Server (Actor ID), например, гипотетический ID
Для эксплуатации этой уязвимости исследователи использовали логику присвоения идентификаторов GitHub, которые выдаются последовательно. В настоящее время ID состоят из 9 цифр. Специалисты Wiz подсчитали, что новые идентификаторы будут включать в себя старые доверенные 6-значные ID примерно каждые пять дней. Сценарий атаки предполагал использование GitHub Apps для автоматического создания приложений и соответствующих им пользователей-ботов. Инициируя сотни регистраций, злоумышленник мог сгенерировать целевой Actor ID (например,
Основной мишенью в данном исследовании стал проект
Контекст обнаружения CodeBreach тесно связан с общей тенденцией проблем безопасности CI/CD. В Wiz охарактеризовали ситуацию как «хрестоматийный пример... идеальный шторм для взломов с высокой степенью воздействия, не требующих предварительного доступа». Ранее компания Sysdig детализировала небезопасные рабочие процессы GitHub Actions, где использование триггера
Аналогичные риски были описаны в анализе Orca Security, который назвал этот феномен «pull_request_nightmare» (кошмар pull request). Уязвимости подобного рода затрагивали такие корпорации, как Google, Microsoft, NVIDIA и другие компании из списка Fortune 500. Исследователь Рой Нисими отметил, что злоупотребление
В ответ на обнаружение CodeBreach AWS оперативно выпустила рекомендации и устранила выявленные проблемы. Были проведены ротации учетных данных и обеспечена безопасность процессов сборки, содержащих учетные данные в памяти. В официальном заявлении было подтверждено, что уязвимость являлась проектно-специфической неправильной конфигурацией фильтров Actor ID. При этом AWS подчеркнула, что не обнаружила никаких доказательств эксплуатации CodeBreach в реальных условиях («in the wild»).
Для предотвращения подобных инцидентов эксперты рекомендуют строгий набор стратегий смягчения последствий. Необходимо гарантировать, что ненадежные участники не могут запускать привилегированные конвейеры, и включить шлюз сборки «Pull Request Comment Approval». Также рекомендуется использовать раннеры, размещенные в CodeBuild, для управления триггерами через рабочие процессы GitHub. Критически важно проверять, чтобы шаблоны regex в фильтрах веб-хуков были жестко привязаны (anchored). В части управления учетными данными следует генерировать уникальный PAT для каждого проекта CodeBuild, минимизировать права этих токенов и рассмотреть возможность использования выделенной непривилегированной учетной записи GitHub.
Изображение носит иллюстративный характер
Техническая суть уязвимости крылась в механизме фильтрации веб-хуков AWS, предназначенных для того, чтобы только доверенные события инициировали сборку CI. Сбой произошел из-за некорректного использования регулярных выражений (Regex): шаблон не был правильно «заякорен» (anchored). Система должна была пропускать только конкретный идентификатор доверенной учетной записи GitHub или Enterprise Server (Actor ID), например, гипотетический ID
755743. Однако из-за ошибки фильтр позволял пройти любому ID, который являлся «надстрокой» (superstring) доверенного значения, например, 226755743, так как он содержит внутри себя нужную последовательность цифр. Для эксплуатации этой уязвимости исследователи использовали логику присвоения идентификаторов GitHub, которые выдаются последовательно. В настоящее время ID состоят из 9 цифр. Специалисты Wiz подсчитали, что новые идентификаторы будут включать в себя старые доверенные 6-значные ID примерно каждые пять дней. Сценарий атаки предполагал использование GitHub Apps для автоматического создания приложений и соответствующих им пользователей-ботов. Инициируя сотни регистраций, злоумышленник мог сгенерировать целевой Actor ID (например,
226755743) и использовать его для обхода фильтра regex, тем самым запуская вредоносную сборку. Основной мишенью в данном исследовании стал проект
aws-sdk-js-v3 (AWS JavaScript SDK). В результате успешной эксплуатации была скомпрометирована учетная запись aws-sdk-js-automation и, что более критично, токен личного доступа (Personal Access Token — PAT), принадлежащий этому пользователю. Это предоставило бы полные административные привилегии над репозиторием. Последствия могли быть катастрофическими: от полного захвата репозиториев AWS GitHub и внедрения вредоносного кода в SDK до компрометации самой консоли AWS и бесчисленных приложений, использующих этот инструментарий. Контекст обнаружения CodeBreach тесно связан с общей тенденцией проблем безопасности CI/CD. В Wiz охарактеризовали ситуацию как «хрестоматийный пример... идеальный шторм для взломов с высокой степенью воздействия, не требующих предварительного доступа». Ранее компания Sysdig детализировала небезопасные рабочие процессы GitHub Actions, где использование триггера
pull_request_target создавало риск утечки привилегированного токена GITHUB_TOKEN через единственный запрос на слияние (pull request) из форка. Аналогичные риски были описаны в анализе Orca Security, который назвал этот феномен «pull_request_nightmare» (кошмар pull request). Уязвимости подобного рода затрагивали такие корпорации, как Google, Microsoft, NVIDIA и другие компании из списка Fortune 500. Исследователь Рой Нисими отметил, что злоупотребление
pull_request_target позволяет эскалировать права от ненадежного форка до удаленного выполнения кода (RCE) на раннерах, эксфильтрации секретов и внедрения вредоносного кода в основную ветку разработки. В ответ на обнаружение CodeBreach AWS оперативно выпустила рекомендации и устранила выявленные проблемы. Были проведены ротации учетных данных и обеспечена безопасность процессов сборки, содержащих учетные данные в памяти. В официальном заявлении было подтверждено, что уязвимость являлась проектно-специфической неправильной конфигурацией фильтров Actor ID. При этом AWS подчеркнула, что не обнаружила никаких доказательств эксплуатации CodeBreach в реальных условиях («in the wild»).
Для предотвращения подобных инцидентов эксперты рекомендуют строгий набор стратегий смягчения последствий. Необходимо гарантировать, что ненадежные участники не могут запускать привилегированные конвейеры, и включить шлюз сборки «Pull Request Comment Approval». Также рекомендуется использовать раннеры, размещенные в CodeBuild, для управления триггерами через рабочие процессы GitHub. Критически важно проверять, чтобы шаблоны regex в фильтрах веб-хуков были жестко привязаны (anchored). В части управления учетными данными следует генерировать уникальный PAT для каждого проекта CodeBuild, минимизировать права этих токенов и рассмотреть возможность использования выделенной непривилегированной учетной записи GitHub.
