Мегалодон проснулся в глубинах GitHub: 5561 репозиторий заражен вредоносными коммитами за 6 часов
NewsMakerКрупнейшая атака на цепочку поставок за последнее время.
GitHub снова используют для атак на цепочку поставки ПО. На этот раз злоумышленник за несколько часов добавил вредоносные коммиты в 5561 репозиторий. Кампания получила название Megalodon, а её цель проста: добраться до секретов, которые хранятся в конвейерах сборки и доставки, CI/CD .
Исследователи SafeDep обнаружили заражённые коммиты и опубликовали список пострадавших репозиториев. По масштабу атака обогнала недавнюю кампанию TeamPCP, где вредоносные изменения попали примерно в 3800 репозиториев GitHub. В Megalodon злоумышленник не обязательно захватывал npm-аккаунт или сразу публиковал вредоносный пакет. Он менял исходный код, а дальше рассчитывал, что владелец проекта примет коммит и запустит сборку.
После слияния такого коммита вредоносный код выполняется внутри CI/CD. Для атакующего это очень ценная среда: там часто лежат облачные ключи , токены GitHub, доступы к контейнерным реестрам, конфигурации Kubernetes и другие секреты, без которых проект не может собираться и разворачиваться.
Megalodon ищет секретные ключи AWS и токены Google Cloud. Код также обращается к метаданным AWS, Google Cloud Platform и Azure, чтобы получить учётные данные ролей экземпляров. Кроме того, вредоносная часть читает приватные SSH-ключи, конфигурации Docker и Kubernetes, токены Vault, данные Terraform и проверяет исходники по более чем 30 шаблонам для поиска секретов. Затем наружу уходят GitHub-токены, Bitbucket-токены и данные для доступа к облачным провайдерам.
Ведущий исследователь Ox Security Моше Симан Тов Бустан считает Megalodon признаком новой волны атак на разработчиков. По его словам, взлом GitHub опасен не только для открытого кода. Компании с приватными репозиториями тоже рискуют, потому что вредоносный коммит может попасть в сборку и украсть секреты до того, как кто-то заметит проблему.
Один из главных примеров связан с Tiledesk, открытой платформой для онлайн-чата и чатботов. SafeDep нашла Megalodon внутри легитимного npm-пакета Tiledesk. Заражёнными оказались версии с 2.18.6 от 19 мая до 2.18.12 от 21 мая. Последняя чистая версия, 2.18.5, вышла от того же сопровождающего. После этого он невольно опубликовал новые релизы уже из заражённого исходного кода.
Важная деталь: исследователи не считают, что атакующий взломал npm-аккаунт сопровождающего. По их данным, злоумышленник скомпрометировал GitHub-репозиторий, а maintainer собрал пакет из отравленного кода и отправил его в npm. Для пользователей обновление выглядело обычным релизом от доверенного автора.
Публикация вредоносных npm-пакетов раньше считалась одним из приёмов TeamPCP, но прямой связи с Megalodon исследователи не нашли. Бустан считает, что за новой кампанией, скорее всего, стоит другой атакующий, который копирует стиль TeamPCP, но не использует значительную часть её кода. Ox Security также не считает Megalodon участником конкурса атак на цепочку поставок, который TeamPCP объявила на BreachForums: в этой кампании нет публичного ключа шифрования, требовавшегося правилами конкурса для подтверждения авторства.
SafeDep связала вредоносные изменения с коммитом acac5a9. Автором указан build-bot, а в качестве почты использован адрес build-system[@]noreply.dev. Сообщение выглядело как обычная служебная правка: ci: add build optimization step. Имя автора и адрес имитировали автоматический CI-коммит, но к полям author и committer не был привязан реальный GitHub-аккаунт.
По версии исследователей, коммит отправили прямо в master без pull request и merge-коммита. Для этого могли использовать скомпрометированный персональный токен доступа или ключ развёртывания. Такой способ особенно опасен: изменение появляется в основной ветке, не проходит нормальное обсуждение и может быстро попасть в сборку.
Затем SafeDep нашла 2878 коммитов с адреса build-system[@]noreply.dev и ещё 2841 коммит со второго адреса, ci-bot@automated.dev . Все изменения появились 18 мая за 6 часов, с 11:36 до 17:48 UTC. Всего под удар попал 5561 репозиторий.
Среди заражённых проектов оказались 9 репозиториев Tiledesk: tiledesk-server, tiledesk-dashboard, tiledesk-telegram-connector, tiledesk-llm, tiledesk-docker-proxy, tiledesk-community-app, tiledesk-campaign-dashboard, tiledesk-helpcenter-template и tiledesk-ai. В списке также есть Black-Iron-Project с 8 скомпрометированными репозиториями, WISE-Community и сотни небольших проектов.
На фоне похожих атак npm аннулировал гранулярные токены доступа с правом записи, которые могли обходить двухфакторную аутентификацию. Такая мера помогает против захвата аккаунтов и вредоносных публикаций, но не закрывает сценарий Megalodon. Здесь проблема началась раньше: вредоносный код попал в GitHub-репозиторий, а не в финальный этап публикации пакета.
Megalodon показывает, что одной проверки зависимостей перед установкой уже мало. Командам нужно смотреть на весь путь кода: кто может писать в основную ветку, какие персональные токены и ключи развёртывания активны, какие секреты доступны CI/CD, куда сборочные задачи могут отправлять данные и какие изменения попадают в релиз без review. Если конвейер сборки получает облачные ключи без строгих ограничений, один вредоносный коммит может превратить обычное обновление в утечку инфраструктурных доступов.
GitHub снова используют для атак на цепочку поставки ПО. На этот раз злоумышленник за несколько часов добавил вредоносные коммиты в 5561 репозиторий. Кампания получила название Megalodon, а её цель проста: добраться до секретов, которые хранятся в конвейерах сборки и доставки, CI/CD .
Исследователи SafeDep обнаружили заражённые коммиты и опубликовали список пострадавших репозиториев. По масштабу атака обогнала недавнюю кампанию TeamPCP, где вредоносные изменения попали примерно в 3800 репозиториев GitHub. В Megalodon злоумышленник не обязательно захватывал npm-аккаунт или сразу публиковал вредоносный пакет. Он менял исходный код, а дальше рассчитывал, что владелец проекта примет коммит и запустит сборку.
После слияния такого коммита вредоносный код выполняется внутри CI/CD. Для атакующего это очень ценная среда: там часто лежат облачные ключи , токены GitHub, доступы к контейнерным реестрам, конфигурации Kubernetes и другие секреты, без которых проект не может собираться и разворачиваться.
Megalodon ищет секретные ключи AWS и токены Google Cloud. Код также обращается к метаданным AWS, Google Cloud Platform и Azure, чтобы получить учётные данные ролей экземпляров. Кроме того, вредоносная часть читает приватные SSH-ключи, конфигурации Docker и Kubernetes, токены Vault, данные Terraform и проверяет исходники по более чем 30 шаблонам для поиска секретов. Затем наружу уходят GitHub-токены, Bitbucket-токены и данные для доступа к облачным провайдерам.
Ведущий исследователь Ox Security Моше Симан Тов Бустан считает Megalodon признаком новой волны атак на разработчиков. По его словам, взлом GitHub опасен не только для открытого кода. Компании с приватными репозиториями тоже рискуют, потому что вредоносный коммит может попасть в сборку и украсть секреты до того, как кто-то заметит проблему.
Один из главных примеров связан с Tiledesk, открытой платформой для онлайн-чата и чатботов. SafeDep нашла Megalodon внутри легитимного npm-пакета Tiledesk. Заражёнными оказались версии с 2.18.6 от 19 мая до 2.18.12 от 21 мая. Последняя чистая версия, 2.18.5, вышла от того же сопровождающего. После этого он невольно опубликовал новые релизы уже из заражённого исходного кода.
Важная деталь: исследователи не считают, что атакующий взломал npm-аккаунт сопровождающего. По их данным, злоумышленник скомпрометировал GitHub-репозиторий, а maintainer собрал пакет из отравленного кода и отправил его в npm. Для пользователей обновление выглядело обычным релизом от доверенного автора.
Публикация вредоносных npm-пакетов раньше считалась одним из приёмов TeamPCP, но прямой связи с Megalodon исследователи не нашли. Бустан считает, что за новой кампанией, скорее всего, стоит другой атакующий, который копирует стиль TeamPCP, но не использует значительную часть её кода. Ox Security также не считает Megalodon участником конкурса атак на цепочку поставок, который TeamPCP объявила на BreachForums: в этой кампании нет публичного ключа шифрования, требовавшегося правилами конкурса для подтверждения авторства.
SafeDep связала вредоносные изменения с коммитом acac5a9. Автором указан build-bot, а в качестве почты использован адрес build-system[@]noreply.dev. Сообщение выглядело как обычная служебная правка: ci: add build optimization step. Имя автора и адрес имитировали автоматический CI-коммит, но к полям author и committer не был привязан реальный GitHub-аккаунт.
По версии исследователей, коммит отправили прямо в master без pull request и merge-коммита. Для этого могли использовать скомпрометированный персональный токен доступа или ключ развёртывания. Такой способ особенно опасен: изменение появляется в основной ветке, не проходит нормальное обсуждение и может быстро попасть в сборку.
Затем SafeDep нашла 2878 коммитов с адреса build-system[@]noreply.dev и ещё 2841 коммит со второго адреса, ci-bot@automated.dev . Все изменения появились 18 мая за 6 часов, с 11:36 до 17:48 UTC. Всего под удар попал 5561 репозиторий.
Среди заражённых проектов оказались 9 репозиториев Tiledesk: tiledesk-server, tiledesk-dashboard, tiledesk-telegram-connector, tiledesk-llm, tiledesk-docker-proxy, tiledesk-community-app, tiledesk-campaign-dashboard, tiledesk-helpcenter-template и tiledesk-ai. В списке также есть Black-Iron-Project с 8 скомпрометированными репозиториями, WISE-Community и сотни небольших проектов.
На фоне похожих атак npm аннулировал гранулярные токены доступа с правом записи, которые могли обходить двухфакторную аутентификацию. Такая мера помогает против захвата аккаунтов и вредоносных публикаций, но не закрывает сценарий Megalodon. Здесь проблема началась раньше: вредоносный код попал в GitHub-репозиторий, а не в финальный этап публикации пакета.
Megalodon показывает, что одной проверки зависимостей перед установкой уже мало. Командам нужно смотреть на весь путь кода: кто может писать в основную ветку, какие персональные токены и ключи развёртывания активны, какие секреты доступны CI/CD, куда сборочные задачи могут отправлять данные и какие изменения попадают в релиз без review. Если конвейер сборки получает облачные ключи без строгих ограничений, один вредоносный коммит может превратить обычное обновление в утечку инфраструктурных доступов.