Атака «Мегалодон» на GitHub: як зловмисники отруїли понад 5500 репозиторіїв за шість годин

Операція тривала приблизно між 11:36 та 17:48 UTC, що свідчить про високоавтоматизовану систему, розраховану на компрометацію великої кількості репозиторіїв до того, як власники помітять зміни.

Як зловмисникам вдалося так швидко внести тисячі комітів

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

Підроблені CI-боти та одноразові акаунти

Атакуючі створили одноразові акаунти GitHub з випадковими іменами користувачів та підробленими ідентифікаторами автоматизації, такими як:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Ці ідентифікатори створювали враження, що коміти надходять від звичайних систем автоматизації, а не від людини-зловмисника.

Підроблені метадані комітів

Дані про авторство комітів та повідомлення були ретельно сфабриковані, щоб виглядати легітимно — часто як звичайні оновлення робочих процесів або налаштувань CI. Це допомагало комітам зливатися зі звичайною діяльністю з розробки та затримувало підозри.

Використання слабкого захисту гілок

Кампанія була спрямована на репозиторії, де правила захисту гілок були слабкими або взагалі відсутні. Без обов'язкових перевірок pull-запитів або обмежень на те, хто може змінювати робочі процеси, атакуючі могли напряму надсилати зміни до робочих файлів у основну гілку репозиторію.

Отруєні робочі процеси GitHub Actions

Кожен шкідливий коміт вставляв файл робочого процесу GitHub Actions, який містив корисне навантаження у форматі Base64 на мові Bash. Коли конвеєр CI виконувався, цей скрипт запускався у середовищі виконання GitHub Actions і починав збір облікових даних.

Така конструкція означала, що атака часто залишалася прихованою до наступного запуску CI, який активував шкідливий робочий процес.

Що намагалися викрасти зловмисники

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

Серед зафіксованих цілей:

• Змінні середовища CI/CD
• Облікові дані хмарних провайдерів (AWS, Google Cloud, Azure)
• Приватні ключі SSH
• Токени API та секрети застосунків
• Токени OIDC GitHub Actions
• Інші конфігураційні секрети, доступні в середовищі виконання CI

Шкідливе програмне забезпечення збирало змінні середовища, інформацію про систему та секрети, доступні робочій машині CI, а потім ексфільтрувало їх на сервер управління (C2).

Оскільки конвеєри CI часто містять облікові дані для розгортання, компрометація середовища збірки може відкрити шлях до хмарної інфраструктури, реєстрів пакетів і робочих середовищ.

Чому крадіжка токенів OIDC особливо небезпечна

Однією з головних цілей навантаження «Мегалодона» були токени OIDC GitHub Actions.

Сучасні конвеєри CI/CD часто використовують федерацію OpenID Connect (OIDC) для автентифікації в хмарних провайдерів без зберігання довгострокових облікових даних. Замість цього робочий процес запитує короткочасний ідентифікаційний токен, який хмарні провайдери обмінюють на тимчасові облікові дані доступу.

Цей підхід підвищує безпеку, усуваючи потребу в статичних API-ключах або облікових даних сервісних акаунтів. Однак він створює новий ризик: якщо зловмисник може викрасти токен під час виконання конвеєра, він може тимчасово видавати себе за ідентичність CI-завдання.

Оскільки хмарні системи ідентифікації довіряють таким токенам, викрадений токен потенційно можна обміняти на тимчасовий доступ до хмари з тими ж дозволами, що й у конвеєра розгортання.

Це означає, що скомпрометований робочий процес CI може призвести до:

• доступу до хмарної інфраструктури
• захоплення конвеєра розгортання
• викрадення секретів з хмарних сервісів

Хоча токени OIDC швидко закінчуються, дозволи, прив'язані до них, можуть зробити короткочасний доступ надзвичайно цінним для зловмисників.

Чому ця атака мала значення

Кампанія «Мегалодон» ілюструє зсув в атаках на ланцюг постачання: від зміни коду застосунків до компрометації інфраструктури автоматизації.

Націлюючись на робочі процеси CI замість вихідного коду, атакуючі можуть:

• автоматично викрадати облікові дані під час виконання конвеєрів
• отримувати доступ до систем розгортання та хмарних середовищ
• залишатися прихованими всередині звичайних змін автоматизації

Оскільки тисячі репозиторіїв покладаються на конвеєри CI з потужними обліковими даними, одна модифікація робочого процесу може викрити секрети в багатьох пов'язаних системах.

Чи пов'язаний «Мегалодон» з витоком через розширення VS Code у GitHub?

Приблизно в той же час GitHub розкрив окремий інцидент безпеки, пов'язаний з отруєним розширенням Visual Studio Code, встановленим на пристрої співробітника. Шкідливе розширення дозволило атакуючим отримати доступ приблизно до 3800 внутрішніх репозиторіїв GitHub до того, як компрометацію було локалізовано.

Цей виток був пов'язаний зі скомпрометованим середовищем розробника та включав викрадення облікових даних через троянізоване розширення, поширене через маркетплейс VS Code.

Деякі звіти з безпеки відзначають схожість у часі та тактиках між цим інцидентом та іншими атаками на ланцюг постачання, що націлюються на інструменти розробки. Однак публічні докази не підтвердили, що внутрішній витік GitHub безпосередньо уможливив кампанію «Мегалодон».

Наразі ці два інциденти найкраще розуміти як окремі, але одночасні події в сфері безпеки ланцюга постачання, які вплинули на екосистему розробників.

Головний урок для безпеки CI/CD

«Мегалодон» демонструє, як швидко автоматизація може масштабувати атаку на ланцюг постачання на тисячі репозиторіїв. Поєднуючи підроблених ботів, автоматизовані коміти та отруєні робочі процеси CI, атакуючі перетворили звичайну інфраструктуру збірки на систему збору облікових даних.

Інцидент підкреслив кілька захисних пріоритетів для команд розробників:

• суворі правила захисту гілок
• обов'язкові перевірки змін у робочих процесах
• мінімальні дозволи для завдань CI
• ретельний моніторинг акаунтів автоматизації та оновлень робочих процесів

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