Acesta este primul episod dintr-o serie de articole despre cel mai răspândit tip de atacuri asupra lanțului de aprovizionare software: cele care (abuzează) de un registru public de componente software, destinate... proiecte open-source pentru a încărca artefacte care ar putea fi partajate cu alți utilizatori. Atunci când infractorii publică software rău intenționat acolo, folosind registrul ca vehicul pentru distribuirea de programe malware, avem un atac în lanțul de aprovizionare atunci când organizațiile victime instalează sau rulează componenta software infectată.
Pentru a simplifica discuția, vom vorbi despre pachete software:, componente într-o formă ambalată produse de terți. Aceasta include nu numai componente utilizate de manageri de pachete precum NPM sau Poetry, ci și componentele sistemului de operare inclusiv biblioteci și binare executabile, imagini cu containere, și mașini virtuale sau extensii de instrumente pentru instrumente de dezvoltare, construire și implementare. Am văzut pachete rău intenționate peste tot. Infractorii cibernetici nu se deranjează: sunt încântați de alternativele oferite de infrastructurile software moderne și utilizează registrul și instrumentul care se potrivesc cel mai bine intenției lor. Așadar, vă rugăm să rețineți că pachetele software sunt o prescurtare pentru imagini de containere, pachete binare, depozite open-source și extensii sau pluginuri de tot felul (IDE-uri, CI/CD sisteme, instrumente de construire). Toate sunt atacate în mod curent.
Serialul va avea 5 episoade:
- Care este problema cu pachetele open source? Aceasta este tema acestei postări. De ce publică infractorii de tot felul pachete rău intenționate? De ce ar trebui să-mi fac griji?
- Anatomia pachetelor rău intenționate: Care sunt tendințele? În acest episod, ne concentrăm asupra amenințării pe care o monitorizăm cu sistemul nostru MEW, zi de zi. Cu un zgomot de fundal puternic datorat unui număr mare de pachete malițioase care utilizează typosquatting sau confuzie de dependențe, un procent mai mic de atacuri sunt mult mai insidioase și prezintă un risc mai mare. Cum s-a schimbat comportamentul actorilor rău intenționați în ceea ce privește sistemul de operare în trecutul recent? Care sunt cifrele? Care sunt tacticile, tehnicile și procedurile utilizate și acțiunile dăunătoare observate?
- Protecția împotriva pachetelor open source rău intenționate: Ce funcționează (sau nu funcționează)Majoritatea profesioniștilor conștienți de securitate au idei despre cum să gestioneze această amenințare. Am auzit manageri de securitate spunând fără ezitare că SCA Instrumentele vă spun deja când o versiune a unui pachet este malware. Sau că depind de componente software bine-cunoscute și evaluate cu atenție, unde orice malware ar fi detectat și eliminat prompt. Ele spun că utilizează versiuni minore/patch-uri deschise pentru a obține automat remedieri de vulnerabilități, iar aceasta este modalitatea corectă și recomandată de a reduce riscul dependențelor open source, urmând principiul „aplicați patch-uri devreme, aplicați patch-uri des”. În acest episod, 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 un risc copleșitor cu care se confruntă organizațiile. Vom încheia cu ce funcționează și care este efortul și resursele implicate.
- Pachete rău intenționate cu sursă deschisă: Abordarea XygeniÎn acest episod, prezentăm strategia pe care o urmăm la Xygeni pentru sistemul nostru de avertizare timpurie împotriva programelor malware (MEW). Cum funcționează acest sistem multi-etapă în timp real atunci când este publicată o nouă versiune de pachet, cum sunt colectate dovezi din diferite surse, cum se face triajul, ce criterii de clasificare urmăm și de ce este nevoie de analize manuale pentru a confirma natura unui candidat la pachet malițios? Cum ajută feedback-ul de la echipele noastre interne și de registru sistemul să învețe din dovezile anterioare colectate pentru a reduce la minimum falsurile pozitive. Și vom explica cum ajutăm NPM, GitHub, PyPI și alte infrastructuri cheie din ecosistemele open-source să reducă timpul de așteptare..
- Exploatarea Open Source: La ce să te aștepți de la răufăcătoriSeria se încheie concentrându-se pe cele mai noi acțiuni pe care adversarii le adoptă pentru a face atacurile mai discrete, mai greu de detectat, mai direcționate către anumite industrii și pentru a extrage mai multe beneficii din această clasă de atacuri. Vor fi lansate atacurile ransomware folosind acest vehicul? Cum utilizează răufăcătorii instrumentele AI pentru a livra pachete rău intenționate mai sofisticate? Sunt proiectele populare de top în pericol? Acest lucru este menit să ofere cititorilor o idee despre această cursă a înarmărilor și la ce să se aștepte pe termen scurt (a doua jumătate a anului 2024) și pe termen mediu (2025). Vom afla cum atacuri precum cel recent... XZ-Utils Backdoor, sau atacul asupra celor care trăiesc de pe urma pământului constructor de electroni În martie-martie 2024 arată că ar trebui să fim vigilenți în ceea ce privește evoluția adversarilor.
Să începem cu primul episod: Ce se întâmplă cu pachetele open source rău intenționate?
Care este problema cu pachetele open source?
În ultimii ani, infractori de tot felul au folosit registre de software open-source pentru a transmite comportamente rău intenționate. Aceste activități sunt la fel de vechi ca și open source-ul, dar frecvența lor a explodat în ultimii trei ani.
Publicarea componentelor rău intenționate în registre publice (atacuri bazate pe dependențe) este un război de gherilă asimetric pe care actorii de amenințare îl folosesc pentru a distribui programe malware, valorificând încrederea pe care organizațiile o au în componentele open-source provenite de la dezvoltatori necunoscuți (amintiți-vă de dependență xkcd comic?). Deoarece aveți încredere în pachete și nu vă deranjează să revizuiți manual conținutul pachetului și dependențele acestuia, aceste atacuri sunt extraordinar de eficiente. Iar asimetria apare deoarece pot fi în mare parte automatizate, iar răufăcătorii nu trebuie să interacționeze direct cu victima. Pur și simplu încarcă pachetul în registrul public și îl lasă să plece.
Pachete rău intenționate a crescut de 6 ori în 2022...și a continuat să crească de 2.5 ori în 2023. Anul trecut, au fost observate un număr uimitor de 245,000 de pachete rău intenționate, o cifră care mai mult decât dublează numărul total din anii precedenți combinați. Aceasta este o creștere exponențială! De la sute de pachete eliminate ca malware confirmat în 2021 și mii în 2022, am văzut mult mai mult „zgomot” de fundal în 2023, cu un ritm similar pentru acest an. Și ascuns în acest fundal cauzat de infractori cibernetici nesofisticați care au urmat „calea celei mai mici rezistențe”, o minoritate de atacuri de mare anvergură au ajuns în titluri chiar și în mass-media generală.
De ce este aceasta o problemă de o asemenea amploare? Există o exces de încredere pe tot parcursul lanțului. Software-ul open-source este distribuit cu codul său sursă și lansat sub o anumită licență. Da, oricine poate inspecta codul sursă; dar, în general, cine o face? Cine, după ce inspectează că software-ul nu conține programe malware, construiește software-ul din surse? Cine, înainte de a transmite componenta pachetului (cunoscută și sub numele de pachet) în aval față de managerul de pachete sau instrumentul de compilare, se asigură că pachetul nu este plin de programe malware și corespunde cu presupusul cod sursă din care ar trebui să provină?
De ce permite infrastructura atacuri atât de ușoare?
Registre de pachete sunt deschise, necesitând adesea o verificare minimă a identității editorului. „Oricine este binevenit să-și publice software-ul aici!” Ștacheta pentru atacatori este scăzută: aceștia folosesc adrese de e-mail de unică folosință și conturi GitHubgithub de unică folosință pentru a crea sute de pachete rău intenționate în campanii scurte, de tip phishing. Doar că pentru cele vizate este necesară o sofisticare mai mare: Am văzut chiar și crearea unui depozit sursă GitHub credibil cu multe stele și commitde la mai mulți contribuitori falși și alte valori de măsurare a popularității și întreținerii. Obținerea observatorii de stele și reputația din contribuții false nu este dificil de automatizat. Am văzut abuzuri asupra infrastructurilor software deschise de tot felul, nu doar malware, cum ar fi incidentul protocolului ceaiului.
Managerii de pachete au fost proiectați pentru ușurință în utilizare și nu pentru securitate.Pot rula scripturi pre- și post-instalare (uneori este necesară compilarea codului nativ pentru o bibliotecă). De asemenea, Managerii de pachete instalează pachete din mai multe surse, iar uneori implicit este utilizarea registrelor publice. Nu au verificat dacă există o nepotrivire între metadatele din cererea de publicare și metadatele din pachetul în sine.
Dependențele sunt imbricate și formează un graf. În anumite ecosisteme precum Node (JavaScript), dependențele cu granulație mică se acumulează în sute sau mii. Un lucru este să am un control strict asupra dependențelor directe declarate de proiectele mele software, dar dependențe tranzitive sunt mai greu de controlat. Open source-ul a urmat principiul „prietenii prietenilor mei sunt prietenii mei”. Frăția este norma în Orientul Îndepărtat sălbatic! Actorii amenințători știu acest lucru și ascund profund comportamentul rău intenționat în dependențe obscure, adesea necunoscute. Acesta a fost cazul cu flux de evenimente incident care vizează Portofel Copay.
Așa a funcționat software-ul open source încă de la început. Nu se va schimba prea mult. Unele registre de pachete solicită în cel mai bun caz autentificare cu doi factori și adesea doar pentru cele mai populare pachete. Unele registre oferă domenii de aplicare, un spațiu de nume deținut de o organizație verificată, dar tragic altele nu îl acceptă (PyPI) sau îl fac opțional (NPM). Este interesant de observat că chiar și o schemă simplă de screening (bazat pe controlul DNS sau al repozitoriului/organizației GitHub care corespunde ID-ului grupului) și făcând Semnăturile PGP sunt obligatorii pentru toate artefactele, cu excepția sumelor de control, elimină cea mai mare parte a „zgomotului”, a pachetelor malițioase de tip typosquatting și limitează o mare parte din confuzie de dependențăAtacurile sofisticate sunt posibile, dar mult mai dificile, existând doar câteva precum com.github.codingandcoding:maven-compiler-plugin cunoscut pentru Maven Central. Și nu toate registrele Maven urmează aceleași practici!
Controalele de securitate asupra managerilor de pachete pot suprasolicita, dar nu împiedică atacurile de dependență. Problema cu autentificarea multi-factor este că, pentru automatizare, se generează acreditări derivate, cum ar fi token-uri de acces sau chei APIapi, pentru conturile care vor fi utilizate în apelurile APIapi efectuate din scripturi de automatizare, fără ca utilizatorul interactiv să ofere un al doilea factor. Autentificarea multi-factor este utilă pentru protejarea conturilor de utilizatori de scurgerile de parole, dar token-urile de acces sau cheile APIapi generate trebuie protejate cât timp sunt active, altfel proprietarul lor va fi impersonat de adversari. O mare parte din campaniile lanțului de aprovizionare bazate pe pachete încep cu o cheie/un token scurs. Rețineți doar incidente precum... carte mare, 3CX...și multe altele, unde acreditările neinteractive au fost mai întâi exfiltrate într-o intruziune preliminară pentru lansarea unui atac asupra lanțului de aprovizionare.
Răspunsul dat la această amenințare nu a fost suficient de robust. În al treilea episod, ne vom concentra asupra a ceea ce a funcționat și a ceea ce a eșuat lamentabil. Industria trebuie să lucreze colectiv la standards, procese, educație și instrumente pentru a atenua riscurile la adresa lanțurilor de aprovizionare globale. Aceasta nu este o problemă pe care o singură organizație o poate rezolva singură.
Pentru a încheia această secțiune, neînțelegerea crucială: vorbim despre rău pachete, nu vulnerabil Vulnerabilitățile provin din erori de proiectare sau de codare, introduse accidental, fără intenție rea. Vulnerabilitățile pot fi exploatate, dar multe nu sunt. Pachetele rău intenționate sunt întotdeauna intenționate și există o exploatabilitate de 100% dacă sunt executate. Nu există un risc comparabil! Prin urmare Este paradoxal să vedem câte eforturi se depun pentru detectarea și atenuarea vulnerabilităților și lipsa unor măsuri echivalente pentru componentele rău intenționate..
„Luăm securitatea în serios”
Să ne imaginăm obișnuitul Corporația AcmeAcme, un furnizor important pentru WileCoyote.com, are cea mai mare parte a software-ului său provenind de la terți, peste 80% din proiecte open-source. Acme produce software pentru uz intern, dar oferă software și pentru partenerii, furnizorii și clienții/utilizatorii finali. Acme are software scris în Go, JavaScript, Java, C# și Python și rulează cea mai mare parte a software-ului său în cloud, în clustere Kubernetes. Acme își construiește imaginile personalizate din imagini de bază preluate din Docker Hub și alte registre. De asemenea, partajează câteva biblioteci, pachete și imagini de containere în registre publice.
Acme ia securitatea în serios. Sunt destul de conștienți de problema open source securityși riscul pe care îl prezintă. Toți dezvoltatorii, administratorii de sistem și inginerii DevOpsdevops folosesc acele chei criptografice drăguțe și mici ca autentificare de factor secundar. Toți commitDepozitele de cod sunt semnate, protecția ramurilor este activată cu revizuiri obligatorii ale codului, CI/CD secrete blocate, stocate într-un seif secret și cu un registru intern care oglindește parțial registrele externe unde sunt stocate doar componentele permise, incluse pe lista albă. Este necesar ca software-ul construit de Acme să preia dependențe de la terți din acest registru.
Probabil că majoritatea organizațiilor se încadrează în acest profil. Dragă cititorule, a ta cu siguranță se potrivește dacă ești deja aici, nu-i așa?
Apoi, într-o zi nefericită, un important dezvoltator frontend la Acme a alergat npm instalează acme-cute-lib, uitând că @acme/cute-lib era dependența cu scopul corect. Greșeala exactă nu este importantă, multe lucruri pot merge prost chiar și atunci când se presupune un control perfect asupra ciclului de viață al software-ului. Dezvoltatorul nostru nu știa că un grup APT viza Acme și a publicat o componentă rău intenționată sub acel nume, într-un mod viclean, astfel încât comportamentul rău intenționat se activează numai atunci când software-ul este instalat pe computerele Acme. Pachetul nu a fost detectat timp de săptămâni de la publicarea sa.
Se execută un script de instalare care caută acreditări (în laptopul dezvoltatorului nostru existau multe token-uri de acces utilă), permițând accesul la depozitele interne de software și la depozitul intern menționat anterior, care, bineînțeles, este accesibil doar prin VPN. Codul malițios a reușit să utilizeze conexiunea VPN existentă și să publice o componentă malițioasă de stadiul doi în registrul intern, afectând o bibliotecă comună de utilitare partajată de majoritatea software-ului livrat de Acme.
Săptămâni mai târziu, alte organizații care utilizau instrumentele publicate de Acme au început să observe trafic ciudat în rețelele lor, trafic care folosea protocolul Acme, dar era direcționat către gazde asemănătoare domeniului Acme. Traficul era criptat, dar instrumentele de monitorizare a sistemului au descoperit acces la fișiere neașteptate și executarea unor procese care arătau ca niște comenzi de sistem, dar care ajungeau să ruleze fișiere executabile descărcate.
Restul e istorie: Acme a negat inițial că un astfel de comportament le era imputabil și că toate măsurile de securitate erau implementate. Abia după ce presa de securitate cibernetică a început să întrebe de ce sursa comportamentului detectat provenea din componentele Acme, iar analizele de securitate au publicat cât de pline erau acele componente de malware ascuns, Acme a trebuit să recunoască incidentul și să apeleze la o firmă de intervenție în caz de incident. O campanie de marketing negativă care a subminat într-o secundă încrederea câștigată cu greu.Acme era la o instalare npm distanță de disaster„”, era un titlu des întâlnit. Apoi au urmat procese și contracte anulate.
Vedeți asemănări cu incidente trecute cunoscute? Acme a fost implicată într-un incident în lanțul de aprovizionare în două faze, utilizând un amestec de confuzie de dependență/typosquatting atacuri care au folosit o stație de lucru a unui dezvoltator ca punct de reper pentru infectarea componentelor care au ajuns în software utilizat de terți. Cum ar putea fi prevenit sau atenuat acest lucru?
De ce sunt atât de populare pachetele otrăvite
Acest incident ipotetic arată că, chiar și cu o abordare rezonabilă a securității open-source, organizațiile au nevoie de măsuri specifice pentru a evita să cadă pradă programelor malware în componentele open-source. Schematic, actorul amenințător poate:
- Creați un pachet nou (urmând binecunoscutele căi de typosquatting sau confuzie de dependențe, aceasta este calea cea mai frecventată de răufăcători în volum);
- Încercați să infectați unul existent, fie injectându-l în codul sursă, fie încercând să-l deghizați ca un contribuitor prin pull requestsau folosind ingineria socială pentru a deveni responsabil (așa cum a făcut „Jao Tan” în XZ Backdoor sau dreapta9ctrl Utilizatorul GitHub a făcut în flux de evenimente incident din toamna anului 2018), sau prin obținerea acreditărilor de repozitoriu open source și prin uzurparea identității administratorului;
- Injectați malware în timpul compilării pachetului, fie prin rularea unui script de compilare rău intenționatsau interferând cu descărcările de pachete cu interceptări de tip man-in-the-middle (din fericire, TLS este acum întotdeauna necesar în majoritatea registrelor).
- Injectați componenta inclusă direct în registru, de obicei prin capturarea acreditărilor de registru (alternativa preferată pentru multe atacuri sofisticate, cum ar fi cel al Acme, unde stația de lucru compromisă în prima etapă avea token-ul de acces intern la registru, de exemplu, în modul obișnuit). .și V or ~/.m2/settings.xml(actorii rău intenționați știu unde să caute secrete). Vulnerabilitățile din registre au fost, de asemenea, exploatate.
Otrăvirea registrelor cu programe malware stă la baza atacurilor de dependență. Nimic nou sub soare: prevalența sa a explodat, dar aceleași tehnici funcționează acum ca acum cinci ani.
Sursa: Colecția de cuțite Backstabber's.
Pachetul malițios poate opera la instalare, în timpul construirii software-ului sau în timpul execuției. Iar comportamentul variază de la exfiltrarea informațiilor, de exemplu, extragerea secretelor pentru o a doua încercare, până la extragerea codului sursă și eliminarea de programe malware suplimentare. În episodul următor, vom analiza pachetele malițioase și modul în care acestea sunt publicate.
Lecturi suplimentare
Următorul episod Anatomia pachetelor rău intenționate: Care sunt tendințele? Ne vom concentra pe cazuri reale pe care le monitorizăm zi de zi cu ajutorul sistemului nostru de avertizare timpurie împotriva programelor malware. Vom analiza tipurile de programe malware observate și tacticile, tehnicile și procedurile preferate. Vom examina ofuscarea și modul în care acestea încearcă să se ascundă de potențialii recenzori, tehnicile de evitare a detectării și cum evoluează acestea odată cu telemetria și mișcarea laterală. Vă rugăm să rămâneți pe fază!
Referinte
- Colecția de cuțite Backstabber's Knife: O trecere în revistă a atacurilor asupra lanțului de aprovizionare cu software open sourceM. Ohm și colab., mai 2020.
- Protecție anti-malware cu sursă deschisăDocument informativ de la Xygeni.
- Software Supply Chain Security Retrospectivă: Modelând un 2024 mai sigurRaport de la Xygeni.
