Гэта чацвёрты эпізод у серыя паведамленняў пра шкоднасныя кампаненты, дзе мы прадстаўляем Ксігені падыход да барацьбы з гэтай пагрозай, як частка нашага пакрыцця для Open Source Security.
Мы бачылі, што празмерны давер да кампанентаў з адкрытым зыходным кодам з нявызначаным паходжаннем выкарыстоўваецца зламыснікамі ўсіх відаў для выканання нечаканых паводзін на машынах распрацоўшчыкаў, CI/CD сістэмы або ўбудаваныя ў праграмнае забеспячэнне арганізацыі-ахвяры, каб яны перадаваліся кліентам арганізацыі. Мы разабралі ў эпізод №2 атакі з выкарыстаннем публічных рэестраў для распаўсюджвання шкоднасных праграм і тое, што мы даведаліся, назіраючы за тым, як дзейнічаюць зламыснікі, і ў папярэднім эпізод №3 былі разгледжаны меры кантролю, якія працуюць (і тыя, якія не працуюць) супраць гэтай пагрозы.
Цяпер самы час разгледзець наш падыход да праблемы. У гэтым эпізодзе мы прадстаўляем стратэгію, якой мы прытрымліваемся ў Xygeni для нашага... Папярэджанне аб шкоднасных праграмах (MEW) сістэма. Як гэтая шматступеньчатая сістэма працуе ў рэжыме рэальнага часу пры выпуску новай версіі пакета, як збіраюцца доказы з розных крыніц, як праводзіцца трыяж, якія крытэрыі класіфікацыі мы прытрымліваемся і чаму ўсё ж неабходны ручны аналіз для пацверджання характару кандыдата на шкоднасны пакет. Мы таксама растлумачым, як мы дапамагаем NPM, GitHub, PyPI і іншым ключавым інфраструктурам у экасістэмах з адкрытым зыходным кодам скараціць час знаходжання шкоднасных праграм.
,en pipeline
Ранняе папярэджанне аб шкоднасных праграмах Xygeni (MEW) пастаянна апрацоўвае кампаненты, альбо архівы пакетаў для бібліятэк і фрэймворкаў для падтрымоўваных праграмных экасістэм, такіх як JavaScript/Node або Python, вобразы кантэйнераў Docker / OCI, альбо пашырэнні і плагіны для інструментаў, такіх як IDE або CI/CD сістэмы. Такія кампаненты публікуюцца ў публічных рэестрах з рознымі ўзроўнямі праверкі карыстальнікаў.
Ніжэй прыведзены схематычны выгляд таго, як працуе сістэма:
,en першаадкрывальнік працэс атрымлівае інфармацыю аб публікацыйных падзеях. Падзея публікацыі — гэта стварэнне новай версіі новага або існуючага кампанента. Паколькі папулярныя рэестры не прадугледжваюць механізм публікацыі і падпіскі для зацікаўленых спажыўцоў, гэта часта робіцца шляхам апытання рэестра на наяўнасць нядаўніх падзей. Выдатны праект ад OSSF, стужкі пакетаўпадтрымка папулярныя рэестры, такія як PyPI або Maven Central, і забяспечваюць адзіны інтэрфейс на аснове стужак дадзеных. У MEW мы дадалі некаторыя спецыяльныя рэалізацыі, якія скарачаюць час чакання, напрыклад, з дапамогай копіі базы дадзеных CouchDB, якая выкарыстоўваецца NPM, і якая сінхранізавана з базай дадзеных публічнага рэестра.
У Xygeni ў нас ёсць інвентар[1] усіх кампанентаў (непасрэдна ці ўскосна), якія выкарыстоўваюцца праграмным забеспячэннем нашых кліентаў. Каардынаты кампанентаў кліентаў рэгулярна перадаюцца ў MEW для прыярытэзацыі аналізаў: кампаненты, якія выкарыстоўваюцца нашымі кліентамі, апрацоўваюцца раней. Прыярытэт таксама заснаваны на рэпутацыі выдаўца і крытычнасці кампанента, таму кампаненты, якія паступаюць ад выдаўцоў з нізкай рэпутацыяй, таксама маюць прыярытэт.
,en аналізатары затым выкарыстоўваць кампаненты, якія чакаюць апрацоўкі, у чарзе прыярытэтаў. Калі версія кампанента выбіраецца для аналізу, яе tarball спампоўваецца з рэестра. Звярніце ўвагу, што аналізуецца ўпакаваны бінарны кампанент: большасць кампанентаў з адкрытым зыходным кодам звычайна паступаюць з рэпазітара з адкрытым зыходным кодам, часта на github.com, які выкарыстоўваецца толькі для кантэксту, і шкоднаснае праграмнае забеспячэнне заўсёды шукаюцца ў tarball кампанента, таму што зламыснікі сістэматычна хлусяць пра крыніцы, якія, як яны сцвярджаюць, выкарыстоўваліся для стварэння tarball кампанента, які яны выпускаюць.
З пункту гледжання карыстальніка
Я чую, як вы думаеце: якую карысць я магу атрымаць, ведаючы пра шкоднасную версію пакета загадзя? У эпізодзе «Анатомія шкоднасных пакетаў: якія тэндэнцыі?» мы ўбачылі, што агульны час знаходжання знаходзіцца ў дыяпазоне дзён, у той час як першае паведамленне ад MEW кліентам, якія выкарыстоўваюць пацярпелы кампанент, знаходзіцца ў дыяпазоне хвілін. З дапамогай простай ахоўнай панэлі[2] Вы можаце заблакаваць зборку (ёсць два ўзроўні папярэджання: адзін цалкам аўтаматызаваны, калі рухавік робіць выснову аб наяўнасці патэнцыйнага шкоднаснага ПЗ, і пазнейшае апавяшчэнне, калі наша служба бяспекі пацвердзіць наяўнасць шкоднаснага ПЗ шляхам ручной праверкі). Чакаць, пакуль рэестр пацвердзіць наяўнасць шкоднаснага ПЗ і выдаліць яго з рэестра, звычайна позна з-за доўгага перыяду экспазіцыі.
Арганізацыя можа выкарыстоўваць ахоўныя панэлі, якія правяраюць наяўнасць кампанента з патэнцыйным шкоднасным праграмным забеспячэннем (на любым з двух узроўняў папярэджання), або праз API хутка даведацца, ці выкарыстоўвае якая-небудзь з прамых або ўскосных залежнасцей у праграмным праекце шкоднасны кампанент.
Як працуе MEW: падрабязнасці
Ядро: механізм выяўлення шкоднасных праграм
Аналізатар выкарыстоўвае розныя дэтэктары для выяўлення доказаў парушэнняў. Дэтэктары спалучаюць статычны аналіз, аналіз магчымасцей і аналіз кантэксту.[3], як апісана ў папярэднім пасце гэтай серыі.
У Xygeni ў нас ёсць каманда інжынераў з вялікім вопытам статычнага аналізу, і гэта галоўнае адрозненне ад іншых рашэнняў па барацьбе з шкоднаснымі праграмамі. Звярніце ўвагу, што для некаторых экасістэм упакаваны tarball змяшчае альбо зыходны код (напрыклад, код JavaScript або TypeScript для пакетаў NPM, зыходныя коды Python для пакетаў PyPI), альбо скампіляваны код, дастаткова блізкі да зыходнага кода для статычнага аналізу (напрыклад, байт-код у файлах JAR для Maven). Для іншых, такіх як вобразы кантэйнераў, звычайна выкарыстоўваюцца бінарныя выканальныя файлы, таму выкарыстоўваецца метад вываду магчымасцей, а таксама традыцыйнае выяўленне шкоднасных праграм на аснове правілаў YARA і сігнатур шкоднасных праграм.
Звярніце ўвагу, што простыя тэхналогіі, такія як рэгулярныя выразы або подпісы, не падыходзяць для выяўлення шкоднасных паводзін. Уявіце сабе выяўленне праграмы-загрузніка або загрузніка: нейкі код або двайковы файл знаходзіцца ў пакеце або загружаны з знешняга дамена, не звязанага з кампанентам (можа быць з вялікі спіс даменаў, набытых зламыснікам[4]Ці законны дамен, каб пазбегнуць выяўлення). Затым гэты код выконваецца з дапамогай адной з прызначаных для гэтага функцый. Код можна пераўтварыць, каб схаваць URL-адрас загрузкі або функцыю, якая выкарыстоўваецца для запуску загрузленага кода. Для яго выяўлення неабходны поўны аналіз патоку дадзеных, прычым у агульным выпадку гэта можна выявіць з выкарыстаннем поўнага механізму статычнага аналізу, альбо з дапамогай пясочніцы (калі ўмовы для запуску шкоднаснай паводзін сапраўды выкананы).
Супрацоўнікі пагражаюць злачынцам тым жа метадам, і для іх былі распрацаваны і ўкаранёны дэтэктары. Таксама існуюць некаторыя этапы папярэдняй апрацоўкі, напрыклад, для выдалення заблытанасці, што часта патрабуецца для выяўлення схаванай паводзін.
Даданне кантэксту
Некаторыя дэтэктары выкарыстоўваюць кантэкстную інфармацыю. Напрыклад, неадпаведнасць паміж версіяй у рэестры кампанентаў і тэгам/рэлізам у адпаведным рэпазітарыі GitHub з'яўляецца важкім доказам таго, што, магчыма, зламыснік атрымаў публікацыйныя ўліковыя дадзеныя для рэестра, але не для рэпазітарыя GitHub. Атакі, падобныя да той, што закранула пастаўшчыка крыпта-кашалькоў. гросбух можна было лёгка выявіць па гэтай неадпаведнасці.
A паказчык шкоднасці (MS) вылічваецца на падставе вынікаў працы дэтэктараў, зыходзячы з сілы атрыманых доказаў. Не ўсе высновы аднолькавыя, і парадак выканання мае значэнне.
Рэпутацыя карыстальнікаў і кампанентаў
Не ўсе распрацоўшчыкі праграмнага забеспячэння з адкрытым зыходным кодам аднолькавыя!
У рэпутацыйнага распрацоўшчыка могуць выкрасці ўліковы запіс NPM (гэта здараецца нават з людзьмі, якія добра ведаюць пра бяспеку), і з яго дапамогай можа быць апублікавана шкоднаснае праграмнае забеспячэнне. Відавочна, што рэпутацыя павінна рэзка ўпасці і аднавіцца да былой славы толькі пасля аднаўлення выкрадзенага ўліковага запісу, а распрацоўшчык выправіць абставіны, якія прывялі да захопу ўліковага запісу. Рэпутацыю цяжка зарабіць, але яе можна страціць імгненна.
У MEW мы ўкаранілі комплексную сістэму кіравання рэпутацыяй, каб узнагароджваць пазітыўныя паводзіны і караць падазроныя дзеянні. Гэтая сістэма пачынаецца з новых карыстальнікаў, якія займаюць нейтральную пазіцыю, і карэктуе іх рэпутацыю ў залежнасці ад іх бягучай дзейнасці.
Рэпутацыя карыстальніка паляпшаецца дзякуючы пазітыўным дзеянням, такім як падтрыманне актыўных акаўнтаў у сацыяльных сетках, уключэнне шматфактарнай аўтэнтыфікацыі, рэгулярны ўнёсак у праекты і падпісанне commitз праверанымі ключамі. І наадварот, рэпутацыя пагаршаецца з-за варожых дзеянняў, такіх як публікацыя шкоднасных праграм, выкарыстанне аднаразовых адрасоў электроннай пошты, адмова ад падпісання commitабо дэманстрацыя незвычайных заканамернасцей ва ўнёсках.
Галоўная мэта нашай сістэмы — забяспечыць бяспечнае і надзейнае асяроддзе. Яна дасягае гэтага шляхам дынамічнай карэкціроўкі рэпутацыі карыстальнікаў у залежнасці ад розных фактараў, адначасова паважаючы праблемы прыватнасці і абмежаванні розных рэестраў.
Для карыстальніка (пры магчымасці далучэння да рэестра і ўліковага запісу github) вылічваецца ўнутраны бал рэпутацыі, а таксама бал шкоднаснасці, які выкарыстоўваецца пры класіфікацыі аналізаванага кампанента, і для лепшай кваліфікацыі таго, хто знаходзіцца пад публікацыяй кампанента.
Былі знойдзены доказы шкоднасных паводзін. Ну і што? Працэс ручнога разгляду
Бягучы класіфікатар прысвойвае аналізаванай версіі кампанента адну з катэгорый «пацверджана шкоднасная», «верагодна шкоднасная», «высокарызыкоўная», «нізкая рызыка» або «не шкоднасная» на аснове парогавых значэнняў балаў, якія абагульняюць вынікі і рэпутацыю карыстальніка/кампанента. Класіфікацыя па катэгорыях «высокая рызыка» або «верагодна шкоднасная» запускае ручную праверку і першае апавяшчэнне. Катэгорыя «пацверджана шкоднасная» ўстанаўліваецца пасля ручной праверкі або калі доказы супадаюць з такімі ж доказамі папярэдняй версіі, якая была пацверджана шкоднаснай.
Калі ёсць дастаткова доказаў патэнцыйна шкоднасных паводзін, пацярпелым арганізацыям адпраўляецца першае папярэджанне (папярэджанне аб карантыне). Як ужо згадвалася раней, яно можа заблакаваць усталёўку або зборку праграмнага забеспячэння, якое залежыць ад кампанента, які знаходзіцца ў карантыне.
Гэта стварае праблемы ва ўнутраным сістэме MEW. dashboard каб аналітыкі бяспекі маглі пачаць працэс ручной праверкі кампанента. Каманда мае спецыялізаваныя інструменты (пясочніца, дэабфускатары, дыстрыбутары для даследавання шкоднасных праграм, інструменты для справаздачнасці аб шкоднасных праграмах) для хуткай ацэнкі характару версіі кампанента, якая даследуецца. Большая частка шкоднасных праграм («анчоўсы» або простыя шкоднасныя кампаненты) правяраецца.
Вынік агляду заключаецца ў адным з бяспечны, такім чынам, механізм аўтаматычнага аналізу выявіў ілжыва станоўчы вынік, які выкарыстоўваецца ў якасці зваротнай сувязі з класіфікатарам машыннага навучання для вывучэння заканамернасці; або пацверджана шкоднаснае, таму кампанент адказна раскрываецца як шкоднасны ў публічным рэестры пасля працэсу справаздачнасці. Другое паведамленне адпраўляецца пацярпелым арганізацыям, якія, у сваю чаргу, могуць зняць з каранціну кампанент або канчаткова заблакіраваць яго ў працэсе абнаўлення версіі або брандмаўэры кампанента, які выкарыстоўваецца ў іх унутраным рэестры.
Гэты параметр дазваляе нам штодня аналізаваць дзясяткі тысяч новых версій і вызначаць дзясяткі, якія, верагодна, з'яўляюцца шкоднаснымі, якія мы затым правяраем уручную. Памятаеце з папярэдняга эпізоду, што адзін з дзесяці тысяч — гэта ўзровень шкоднасных кампанентаў, якія мы зараз бачым у рэальным жыцці.
Справаздачнасць у Рэестр
Мы выявілі, што большасць публічных рэестраў, адной з асноўных асноваў інфраструктуры з адкрытым зыходным кодам, забяспечваюць даволі абмежаваныя механізмы для паведамленняў аб праблемах бяспекі, і ў прыватнасці аб шкоднасных кампанентах. Мы з усіх сіл імкнемся палепшыць асноўную арганізацыю працэсу паведамленняў. Звычайна мы атрымліваем максімум ліст з зваротнай сувяззю ад каманды бяспекі ў рэестры, які пацвярджае, што кампанент быў выдалены з рэестра.
Часам рэестр злоўжываюць, парушаючы ўмовы яго выкарыстання, але не выклікаючы шкоднасных паводзін у пастаўленым праграмным забеспячэнні. Пра гэта таксама паведамляецца ў рэестр, але арганізацыі не паведамляюцца, каб абмежаваць шум.
Будучая праца
У цяперашні час на плане знаходзіцца шмат паляпшэнняў. Перш за ўсё, публічны партал для стану кампанентаў АС, асабліва ў дачыненні да доказаў патэнцыйнай шкоднасці, у цяперашні час знаходзіцца ў стадыі распрацоўкі. Гэта невялікі ўнёсак у супольнасць праграмнага забеспячэння з адкрытым зыходным кодам. Сачыце за навінамі.
Яшчэ адна бягучая распрацоўка — гэта ўдасканаленне класіфікатар машыннага навучанняMEW будзе вучыцца на папярэдніх класіфікацыях. Вектар вынікаў з дэтэктараў рухавікоў, а таксама атрыманы бал шкоднаснасці і бал рэпутацыі як для кампанента, так і для выдаўца («Знойдзена доказ») выкарыстоўваецца ў якасці ўваходных дадзеных для сістэмы машыннага навучання, якая абнаўляе мадэль класіфікатара. Выхадная зменная — гэта проста тое, ці пацвердзіў рэестр, што кампанент быў шкоднасным. Гэта мае кодавую назву «Аракул» і дапаможа з больш дакладнай...cisкласіфікатар e, распрацаваны як надзейны (высокая паўнавартаснасць, г.зн. не прапускаць шкоднасныя кампаненты), але з меншай колькасцю ілжывых спрацоўванняў (не паведамляць пра бяспечныя кампаненты як шкоднасныя).
A паказчык крытычнасці будуць дададзеныя для крытэрыяў прыярытэтызацыі, акрамя прыналежнасці да набору залежнасцей кліентаў і нізкай рэпутацыі выдаўца. Зразумела, што праекты з большым уплывам і важнасцю варта разглядаць раней для аналізу. Мы не будзем тут вынаходзіць ровар і будзем прытрымлівацца Ацэнка крытычнасці праекта з адкрытым зыходным кодам.
Падтрымка дадатковых экасістэм знаходзіцца ў распрацоўцы. Шырока распаўсюджаныя тэхналогіі і інструменты, такія як убудовы PHP або Jenkins, знаходзяцца ў распрацоўцы.
Мы таксама вывучаем, ці можна палепшыць працэс ручной праверкі з дапамогай штучнага інтэлекту, каб спрасціць аналіз некалькіх больш складаных шкоднасных кампанентаў.
У наступнай і заключнай частцы гэтай серыі «Эксплуатацыя адкрытага зыходнага кода: чаго чакаць ад дрэнных хлопцаў«Мы засяродзімся на найноўшых спосабах, якія выкарыстоўваюць зламыснікі, каб зрабіць атакі больш схаванымі, цяжэй выяўляльнымі, больш мэтанакіраванымі на пэўныя галіны і больш прыбытковымі. Ці будуць атакі праграм-вымагальнікаў ажыццяўляцца з дапамогай гэтага сродку? Як зламыснікі выкарыстоўваюць інструменты штучнага інтэлекту для распаўсюджвання больш складаных шкоднасных праграм? Ці знаходзяцца пад пагрозай найбольш папулярныя праекты? Гэта зроблена для таго, каб чытачы атрымалі ўяўленне аб гэтай гонцы ўзбраенняў і аб тым, чаго чакаць у кароткатэрміновай (другая палова 2024 года) і сярэднетэрміновай (2025 год) перспектыве.
Мы скончым некалькімі думкамі пра тое, якія маленькія крокі можа зрабіць супольнасць, не змяняючы занадта шмат адкрытасці свету адкрытага зыходнага кода. Напрыклад, больш эфектыўны механізм паведамлення аб шкоднасных праграмах у публічныя рэестры і абмен доказамі патэнцыйна шкоднасных кампанентаў з рэестрамі і супольнасцю быў бы невялікім крокам у правільным кірунку да мэты закрыцця дзвярэй для зламыснікаў.
Шкоднаснае праграмнае забеспячэнне ў кампанентах з адкрытым зыходным кодам не павінна парушаць велізарныя перавагі, якія супольнасць адкрытага зыходнага кода прынесла нашаму грамадству.
- [1] Наш сканер выяўляе кампаненты з адкрытым зыходным кодам, на якія спасылаюцца аналізаваныя праграмныя праекты, таму вядомы поўны актуальны граф залежнасцей, прынамсі для праектаў, якія рэгулярна скануюцца. Аперацыйнае асяроддзе Xygeni прапануе API, які кліенты таксама могуць выкарыстоўваць падчас унясення ў белы спіс кампанента, які цікавіць, у тым ліку інфармацыю пра ўразлівасці і доказы шкоднаснага ўздзеяння.
- [2] Ахоўная паласа можа парушыць зборку, калі будзе выяўлена праблема бяспекі, якая адпавядае ўмове. Вынікі бяспекі, такія як крытычная і дасягальная ўразлівасць або выкарыстанне кампанента, які знаходзіцца ў карантыне, могуць лічыцца дастаткова сур'ёзнымі, каб парушыць зборку пацярпелага праграмнага забеспячэння.
- [3]Нашы аналітыкі бяспекі запускаюць кампанент або яго ўсталявальныя скрыпты ў пясочніцы пры неабходнасці. Аднак MEW не выконвае дынамічны аналіз, галоўным чынам таму, што шкоднасныя паводзіны не заўсёды з'яўляюцца мэтанакіраванымі атакамі, а таксама з-за логікі ўхілення, якую выкарыстоўваюць зламыснікі для абыходу дынамічнага аналізу.
- [4] Гэтая тэхніка атрымала назву «Алгарытмы генерацыі зарэгістраваных даменаў» або RDGA, і з'явіліся новыя зламыснікі, такія як т. зв. Рэвальвер Трус інвеставалі да 1 мільёна долараў у 500 тысяч даменаў, што паказвае, наколькі прыбытковая індустрыя кіберзлачыннасці.
