Атака Megalodon поразила 5 561 репозиторий GitHub за шесть часов
Атака на цепочку поставок CI/CD в GitHub под названием Megalodon установила новый рекорд автоматизированного крупномасштабного взлома репозиториев. За шесть часов злоумышленники отправили 5 718 вредоносных обновлений кода в 5 561 репозиторий GitHub, используя поддельные личности для внедрения файлов рабочих процессов, предназначенных для скрытого извлечения облачных учётных данных, SSH-ключей и секретов исходного кода. Масштаб и скорость кампании свидетельствуют о переходе к промышленным атакам на конвейеры, которые большинство команд не успевает обнаружить или отразить в режиме реального времени.
Как работала атака Megalodon: поддельные личности и автоматизированное внедрение рабочих процессов
Злоумышленники, стоящие за Megalodon, не прибегали к эксплойтам нулевого дня или сложным вредоносным программам, доставляемым на машины конечных пользователей. Вместо этого они воспользовались доверенной природой самой CI/CD-инфраструктуры GitHub. Создав поддельные личности участников, они отправляли pull-запросы или напрямую изменяли файлы конфигурации рабочих процессов — а именно YAML-файлы, которые GitHub Actions использует для определения автоматизированных конвейеров сборки и развёртывания.
Как только вредоносный файл рабочего процесса попадает в репозиторий, он выполняется автоматически при каждом запуске конвейера — как правило, при событиях push или слиянии pull-запросов. Это выполнение происходит внутри собственной среды раннера GitHub, которая зачастую имеет доступ к секретам репозитория, переменным среды и токенам облачных провайдеров. Рабочие процессы Megalodon использовали это окно доступа для передачи данных вовне — по всей видимости, на инфраструктуру под контролем злоумышленников — прежде чем любой из сопровождающих репозиторий имел повод проверить изменение.
Определяющей характеристикой кампании является её автоматизация. Выполнить почти 5 720 отдельных отправок кода в более чем 5 500 репозиториев за шесть часов невозможно вручную. Для этого требуется инструментарий с поддержкой скриптов, способный определять цели, проходить аутентификацию с поддельными личностями, формировать правдоподобные модификации рабочих процессов и отправлять их параллельно. Такой уровень автоматизации означает, что поверхность атаки расширялась быстрее, чем любая команда мониторинга могла отслеживать.
Какие учётные данные были похищены и почему это важно для разработчиков
Полезной нагрузкой каждого вредоносного рабочего процесса был сбор учётных данных. В качестве целей выступали учётные данные облачных провайдеров — чаще всего ключи доступа AWS, GCP и Azure, хранящиеся в GitHub Secrets или указанные в переменных среды рабочих процессов. В сферу интересов также входили SSH-приватные ключи, используемые для доступа к серверам или межсервисной аутентификации, а также любые секреты в открытом виде, встроенные в исходный код или файлы конфигурации.
Эти типы учётных данных несут каскадный риск. Похищенный ключ доступа AWS, привязанный к роли IAM с широкими правами, позволяет злоумышленнику за считанные минуты развернуть инфраструктуру, извлечь хранилища данных или перемещаться горизонтально в связанные сервисы. SSH-ключи могут обеспечить постоянный доступ к производственным серверам ещё долго после того, как исходное нарушение обнаружено, а репозиторий GitHub очищен. Ценность этих данных далеко выходит за пределы самих репозиториев.
Это не гипотетическая модель риска. В начале этого года подрядчик CISA раскрыл ключи AWS и пароли в открытом тексте в публичном репозитории GitHub, продемонстрировав, что некорректное управление учётными данными в средах разработки затрагивает даже организации с выделенными полномочиями в области безопасности. Megalodon просто промышленно масштабировал тот же путь эксплуатации, который индивидуальные человеческие ошибки уже неоднократно демонстрировали.
Также стоит отметить, что инструменты и конвейеры для кражи учётных данных сами являются целями. Недавняя атака на цепочку поставок Bitwarden CLI показала, что даже инструменты, которые разработчики используют для управления секретами, могут быть скомпрометированы на стороне поставщика, а значит, цепочка доверия выходит за рамки любого отдельного репозитория или конфигурации конвейера.
Эшелонированная защита для команд разработки: управление секретами, зашифрованные коммуникации и контроль доступа
Megalodon воспользовался несколькими уязвимостями, широко распространёнными как в открытых, так и в частных репозиториях. Устранение этих уязвимостей требует многоуровневого подхода, а не единственного средства контроля.
Во-первых, секреты никогда не должны храниться в открытом виде внутри файлов рабочих процессов, файлов конфигурации среды или исходного кода. Функция зашифрованных секретов GitHub обеспечивает базовый уровень, однако эти секреты также должны следовать принципу наименьших привилегий. Рабочий процесс, выполняющий развёртывание в тестовой среде, не нуждается в учётных данных производственной базы данных. Строгое ограничение области применения секретов сужает радиус поражения при компрометации рабочего процесса.
Во-вторых, правила защиты веток и обязательные рецензенты для изменений файлов рабочих процессов создают контрольную точку с участием человека, которую автоматизированные атаки должны обходить. Требование как минимум одного одобренного отзыва перед любым изменением файлов в .github/workflows/ может замедлить или заблокировать тип быстрого автоматизированного внедрения, на который полагался Megalodon.
В-третьих, привязка сторонних GitHub Actions к конкретным хешам коммитов (SHA), а не к плавающим тегам, предотвращает отдельный, но связанный вектор атаки, при котором скомпрометированные издатели действий незаметно обновляют тег так, чтобы он указывал на вредоносный код. Именно такой механизм использовался в нескольких недавних инцидентах с цепочкой поставок GitHub Actions.
Наконец, ведение журналов аудита и обнаружение аномалий в выполнении рабочих процессов позволяет выявлять неожиданные исходящие сетевые соединения или необычные шаблоны доступа к секретам. API журнала аудита GitHub и сторонние инструменты безопасности CI/CD помогут обнаружить эти сигналы.
Как прямо сейчас провести аудит репозиториев GitHub и конвейеров CI/CD
Если ваша организация поддерживает репозитории GitHub с активными конвейерами CI/CD, несколько немедленных шагов заслуживают приоритетного внимания.
Проверьте все файлы в директории .github/workflows/ на наличие недавно добавленных или изменённых записей, особенно добавленных участниками, которых вы не узнаёте. Проверьте историю коммитов именно для файлов рабочих процессов, а не только представление ветки по умолчанию.
Смените все секреты, которые были активны в период атаки или в отношении которых вы не можете с уверенностью подтвердить отсутствие утечки. Для облачных учётных данных проверьте журналы доступа на стороне провайдера на предмет необычных вызовов API в тот же период.
Проведите аудит того, какие участники репозитория и приложения имеют права на запись. Атаки с использованием поддельных личностей зависят от возможности отправки кода, поэтому ужесточение прав участников и включение обязательных проверок для изменений рабочих процессов устраняет ключевую точку входа.
Наконец, рассмотрите возможность внедрения специализированного инструмента сканирования секретов, запускаемого при каждом коммите, для перехвата учётных данных до их попадания в репозиторий. Несколько вариантов с открытым исходным кодом и коммерческих решений интегрируются непосредственно с GitHub.
Что это означает для вас
Кампания Megalodon наглядно демонстрирует, почему конвейеры CI/CD стали основной поверхностью атаки. Разработчики и команды безопасности, считающие безопасность конвейера второстепенной по отношению к безопасности приложений, оставляют широко открытый путь к своим наиболее чувствительным учётным данным.
Начните с аудита секретов на этой неделе. Проверьте, кто может изменять ваши файлы рабочих процессов, смените учётные данные, чистоту которых не можете подтвердить, и включите защиту веток для ветки по умолчанию, если вы ещё этого не сделали. Скорость атаки Megalodon означает, что к моменту срабатывания оповещения извлечение данных, возможно, уже завершено. Предотвращение и ограничение области доступа — единственные надёжные средства защиты.
