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