Атака Megalodon вразила 5 561 репозиторій GitHub за шість годин
Атака на ланцюг постачання CI/CD на GitHub під назвою Megalodon встановила новий орієнтир для автоматизованого масштабного компрометування репозиторіїв. За шість годин зловмисники надіслали 5 718 шкідливих оновлень коду до 5 561 репозиторію GitHub, використовуючи підроблені ідентифікатори для впровадження файлів робочих процесів, призначених для непомітного викрадення хмарних облікових даних, SSH-ключів і секретів вихідного коду. Надзвичайна швидкість і масштаб кампанії свідчать про зміщення в бік індустріалізованих атак на конвеєри, які випереджають можливості більшості команд щодо виявлення та реагування в реальному часі.
Як працювала атака Megalodon: підроблені ідентифікатори та автоматизоване впровадження робочих процесів
Зловмисники, які стоять за Megalodon, не покладалися на експлойти нульового дня або складне шкідливе програмне забезпечення, яке доставляється на машини кінцевих користувачів. Натомість вони використали довірену природу власної інфраструктури CI/CD GitHub. Створивши підроблені ідентифікатори учасників, вони надсилали запити на злиття або безпосередньо змінювали файли конфігурації робочих процесів — зокрема YAML-файли, які GitHub Actions використовує для визначення автоматизованих конвеєрів збірки та розгортання.
Щойно шкідливий файл робочого процесу потрапляє до репозиторію, він виконується автоматично щоразу, коли запускається конвеєр — зазвичай при подіях push або злитті запитів на злиття. Це виконання відбувається всередині власного середовища виконавця GitHub, яке часто має доступ до секретів репозиторію, змінних середовища та токенів, прив'язаних до хмарних провайдерів. Робочі процеси Megalodon використовували це вікно доступу для вивантаження даних назовні — імовірно, до інфраструктури під контролем зловмисників — ще до того, як будь-який супровідник репозиторію мав підстави переглянути зміну.
Визначальною характеристикою кампанії є її автоматизація. Виконання майже 5 720 окремих надсилань коду більш ніж до 5 500 репозиторіїв за шість годин — це не ручна робота. Вона потребує скриптового інструментарію, здатного визначати цілі, автентифікуватися з підробленими ідентифікаторами, створювати правдоподібні модифікації робочих процесів і надсилати їх паралельно. Такий рівень автоматизації означає, що поверхня атаки розширювалася швидше, ніж будь-яка команда моніторингу людей могла відстежити.
Які облікові дані були викрадені і чому це важливо для розробників
Корисне навантаження кожного шкідливого робочого процесу полягало у збиранні облікових даних. Серед цілей — облікові дані хмарних провайдерів, найчастіше ключі доступу AWS, GCP та Azure, що зберігаються як GitHub Secrets або посилаються всередині змінних середовища робочого процесу. Приватні SSH-ключі, що використовуються для доступу до серверів або міжсервісної автентифікації, також були в зоні ризику, як і будь-які відкриті секрети, вбудовані у вихідний код або конфігураційні файли.
Ці типи облікових даних несуть каскадні ризики. Викрадений ключ доступу AWS, прив'язаний до ролі IAM із широкими правами, може дозволити зловмиснику за лічені хвилини розгортати інфраструктуру, вивантажувати сховища даних або здійснювати горизонтальне переміщення до пов'язаних сервісів. SSH-ключі можуть забезпечувати постійний доступ до виробничих серверів ще довго після того, як первісне порушення виявлено та репозиторій GitHub очищено. Цінність цих даних виходить далеко за межі самих репозиторіїв.
Це не гіпотетична схема ризику. На початку цього року підрядник CISA розкрив ключі AWS і паролі у відкритому репозиторії GitHub, продемонструвавши, що неналежне управління обліковими даними у середовищах розробки зачіпає навіть організації з виділеними мандатами безпеки. Megalodon просто індустріалізував той самий шлях експлуатації, який індивідуальні людські помилки вже неодноразово демонстрували.
Варто також зазначити, що самі інструменти та конвеєри крадіжки облікових даних є цілями. Нещодавня атака на ланцюг постачання Bitwarden CLI показала, що навіть інструменти, які розробники використовують для управління секретами, можуть бути скомпрометовані вище за ланцюгом, тобто ланцюг довіри виходить за межі будь-якого окремого репозиторію або конфігурації конвеєра.
Глибокий захист для команд розробників: управління секретами, зашифровані комунікації та контроль доступу
Megalodon використав кілька слабких місць, які є поширеними як у відкритих, так і в приватних репозиторіях. Для їх усунення потрібен багаторівневий підхід, а не єдиний контроль.
По-перше, секрети ніколи не слід зберігати у відкритому вигляді всередині файлів робочих процесів, файлів конфігурації середовища або вихідного коду. Функція зашифрованих Secrets у 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 означає, що до моменту спрацювання сповіщення вивантаження даних може вже завершитися. Запобігання та обмеження доступу — єдиний надійний захист.
