Расчыненыя дэталі нападу на інфраструктуру, выкарыстоўваную пры распрацоўцы фрэймворка машыннага навучання PyTorch, якая дазволіла выняць ключы доступу, дастатковыя для месцавання адвольных дадзеных у рэпазітары з рэлізамі праекту ў GitHub і AWS, а таксама для падстаноўкі кода ў асноўную галінку рэпазітара і даданні. Падмена рэлізаў PyTorch магла выкарыстоўвацца для ажыццяўлення нападу на буйныя кампаніі, такія як Google, Meta, Boeing і Lockheed Martin, якія выкарыстоўваюць PyTorch у сваіх праектах. У рамках праграмы Bug Bounty кампанія Meta выплаціла даследнікам $16250 за інфармацыю аб праблеме.
Сутнасць нападу ў магчымасці выканання свайго кода на серверах бесперапыннай інтэграцыі, якія выконваюць перазборку і выкананне заданняў для тэставання новых змен, якія адпраўляюцца ў рэпазітар. Праблема закранае праекты, якія выкарыстоўваюць уласныя знешнія апрацоўшчыкі "Self-Hosted Runner" з GitHub Actions. У адрозненне ад традыцыйных GitHub Actions апрацоўшчыкі Self-Hosted выконваюцца не ў інфраструктуры GitHub, а на сваіх серверах або ў віртуальных машынах, якія падтрымліваюцца распрацоўшчыкамі.
Выкананне зборачных заданняў на сваіх серверах дазваляе арганізаваць запуск кода, які можа ажыццявіць сканаванне ўнутранай сеткі прадпрыемства, пошук у лакальнай ФС ключоў шыфравання і токенаў доступу, аналіз зменных асяроддзі з параметрамі звароту да вонкавых сховішчаў ці хмарным сэрвісам. Пры адсутнасці належнай ізаляцыі зборачнага асяроддзя знойдзеныя канфідэнцыйныя дадзеныя могуць быць адпраўленыя атакавалым па-за, напрыклад, праз зварот да вонкавых API. Для вызначэння прымянення праектамі "Self-Hosted Runner" можа выкарыстоўвацца інструментар Gato, які аналізуе агульнадаступныя workflow-файлы і логі запуску CI-заданняў.
У PyTorch і многіх іншых праектах, якія выкарыстоўваюць "Self-Hosted Runner", запуск зборачных заданняў дазволены толькі распрацоўшчыкам, змены якіх раней праходзілі рэцэнзаванне і ўключаліся ў кодавую базу праекта. Наяўнасць статусу «contributor» пры выкарыстанні ў рэпазітары налад па змаўчанні дае магчымасць запускаць апрацоўшчыкі GitHub Actions пры перадачы pull-запытаў і, адпаведна, выконваць свой код у любым асяроддзі GitHub Actions Runner, прывязаным да рэпазітара ці якая курыруе праект арганізацыі.
Прывязку да статусу «contributor» аказалася лёгка абыйсці – дастаткова папярэдне адправіць нязначную змену і дачакацца яго прыняцця ў кодавую базу, пасля чаго распрацоўшчык аўтаматычна атрымліваў статус актыўнага ўдзельніка, pull-запыты якога дазволена тэставаць у CI-інфраструктуры без асобнай праверкі. Для атрымання статусу актыўнага распрацоўніка падчас эксперыменту выкарыстоўваліся малаважныя касметычныя змены, злучаныя з ухіленнем памылак друку ў дакументацыі. Для атрымання доступу да рэпазітара і сховішча рэлізаў PyTorch падчас нападаў пры выкананні кода ў "Self-Hosted Runner" быў ажыццёўлены перахоп токена GitHub, які ўжываўся для доступу да рэпазітара са зборачных працэсаў, а таксама ключоў AWS, задзейнічаных для захавання вынікаў зборкі.
Праблема не спецыфічная для PyTorch і закранае многія іншыя буйныя праекты, якія выкарыстоўваюць налады па змаўчанні для "Self-Hosted Runner" у GitHub Actions. Напрыклад, згадана ажыццяўленне падобных нападаў для падстаноўкі бэкдора ў некаторыя буйныя кашалькі криптовалют і блокчейн-праекты з мільярднай капіталізацыяй, занясенні змен у рэлізы Microsoft Deepspeed і TensorFlow, кампраметацыі аднаго з прыкладанняў кампаніі CloudFlare, а таксама выкананні кода на кампутары ў сетцы Microsoft. Дэталі па дадзеных інцыдэнтах пакуль не раскрываюцца. У рамках дзейных праграм Bug Bounty даследнікі адправілі больш за 20 заявак для атрымання ўзнагарод на суму некалькі сотняў тысяч даляраў.
Крыніца: opennet.ru