Исследователи из компании Wiz обнаружили, что некорректная конфигурация в сервисе сборки кода от AWS могла привести к масштабному компрометированию ключевых репозиториев кода и приложений AWS в GitHub.
Уязвимость возникла из-за тонкого недочета в том, как конвейеры непрерывной интеграции (CI) AWS CodeBuild для репозиториев обрабатывали триггеры сборки. «Всего двух недостающих символов в фильтре регулярного выражения (regex) было достаточно, чтобы неаутентифицированные злоумышленники проникли в среду сборки и похитили привилегированные учетные данные», — заявили исследователи в своем четверговом блоге.
Фильтр regex, лежащий в основе проблемы, представляет собой автоматическое правило сопоставления шаблонов, которое сканирует вывод логов на наличие секретов и скрывает их, чтобы предотвратить утечку.
Эта проблема позволила полностью захватить контроль над ключевыми репозиториями AWS в GitHub, в частности над AWS JavaScript SDK — основной библиотекой, на которой функционирует консоль AWS.
«Это демонстрирует всю мощь и риски уязвимостей цепочки поставок», — сообщил CSO Юваль Авраами, один из авторов отчета об этой ошибке. — «Именно поэтому атаки на цепочки поставок набирают обороты: один крошечный недочет может привести к невероятно разрушительной атаке».
После того как в августе прошлого года AWS была предупреждена об уязвимости, компания оперативно устранила брешь и внедрила глобальные меры по укреплению безопасности в сервисе CodeBuild, чтобы исключить возможность аналогичных атак. Подробности об этой проблеме Wiz и AWS раскрывают только сейчас.
AWS сообщила CSO, что «обнаружила отсутствие влияния на конфиденциальность или целостность какой-либо среды клиента или сервиса AWS». Компания также рекомендовала разработчикам соблюдать лучшие практики при использовании AWS CodeBuild.
Однако исследователи Wiz призвали разработчиков, использующих этот продукт, принять меры для защиты своих проектов от подобных инцидентов.
Обнаружение
Wiz обнаружила проблему в августе прошлого года после попытки атаки на цепочку поставок через расширение Amazon Q для VS Code. Злоумышленник воспользовался некорректно настроенным проектом CodeBuild, чтобы скомпрометировать репозиторий расширения в GitHub и внедрить вредоносный код в основную ветку. Этот код затем попал в релиз, который скачали пользователи. Хотя полезная нагрузка атакующего в итоге не сработала из-за опечатки, она все же выполнилась на машинах конечных пользователей, наглядно продемонстрировав риск, связанный с неправильной настройкой конвейеров CodeBuild.
Исследователи Wiz изучили ситуацию и выявили корень уязвимости — возможность обхода идентификатора угрозы из-за незаякоренных регулярных выражений, после чего уведомили AWS. По заявлению AWS, в течение 48 часов эта лазейка была закрыта.
Компания также предприняла дополнительные шаги по укреплению безопасности, включая внедрение дополнительных защитных мер для всех процессов сборки, содержащих токены GitHub или любые другие учетные данные в памяти. AWS сообщила, что провела аудит всех остальных общедоступных сред сборки, чтобы убедиться в отсутствии подобных проблем во всем открытом коде AWS.
Кроме того, были проанализированы логи всех публичных репозиториев сборки, а также связанные логи CloudTrail. «Было установлено, что ни один другой субъект не воспользовался проблемой незаякоренного регулярного выражения, продемонстрированной исследовательской группой Wiz. AWS пришла к выводу, что выявленная проблема не повлияла на конфиденциальность или целостность какой-либо среды клиента или сервиса AWS».
Келльман Мегу, технический директор канадской фирмы по управлению рисками Deepcove Cybersecurity, отметил, что для разработчиков, которые не делают свои среды CodeBuild общедоступными, это не стало бы большой проблемой. «Но», — добавил он, — «если люди не будут бдительны, я вижу, как это можно использовать. Это хитро».
Разработчикам не следует делать среды сборки общедоступными
Руководителям по информационной безопасности (CSO) следует проследить, чтобы разработчики не делали среды сборки общедоступными, считает Мегу. «Использование общедоступных сервисов, таких как GitHub, не подходит для корпоративного управления кодом и развертывания», — добавил он. — «Наличие частного GitLab/GitHub, сервиса или даже собственного сервера Git-репозиториев должно быть стандартом для бизнеса, что сделает такую атаку невозможной, если [угрожающие субъекты] изначально не увидят репозиторий. Репозиторием должен владеть бизнес; это не то, что можно просто позволить разработчикам настраивать по мере необходимости». По его словам, репозитории кода должны настраивать руководители ИТ-отделов или служб информационной безопасности. Разработчики «должны быть пользователями системы, а не ее конечными владельцами».
Wiz настоятельно рекомендует всем пользователям AWS CodeBuild внедрить следующие меры защиты, чтобы обезопасить свои проекты от возможного компрометирования:
- Предотвращение запуска привилегированных сборок по незапрошенным Pull Request, путем:
- включения нового шлюза сборки «Одобрение комментария в Pull Request»;
- в качестве альтернативы, использования раннеров, размещенных в CodeBuild, для управления триггерами сборки через рабочие процессы GitHub;
- если необходимо полагаться на фильтры веб-перехватчиков (webhook), убедитесь, что шаблоны их regex заякорены.
- Обеспечение безопасности соединения CodeBuild-GitHub путем:
- генерации уникального, гранулярного Персонального токена доступа (PAT) для каждого проекта CodeBuild;
- строгого ограничения разрешений PAT до минимально необходимого уровня.
- Рассмотрения возможности использования выделенной непривилегированной учетной записи GitHub для интеграции с CodeBuild.
Эта статья изначально была опубликована на InfoWorld.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Howard Solomon
