Acesta este al patrulea episod din serii de posturi despre componentele rău intenționate, unde prezentăm Xygeni abordare pentru gestionarea acestei amenințări, ca parte a acoperirii noastre pentru Open Source Security.
Am observat că excesul de încredere în componentele open source de sursă incertă este valorificat de răufăcători de tot felul pentru a genera comportamente neașteptate care să fie rulate fie pe mașinile dezvoltatorilor, fie CI/CD sisteme sau încorporate în software-ul organizației victime, astfel încât să fie transmise clienților organizației. Am analizat în detaliu episodul #2 atacurile care utilizează registre publice pentru a distribui programe malware și ce am învățat după ce am observat cum operează actorii rău intenționați și în studiile anterioare episodul #3 Au fost examinate controalele care funcționează (și cele care eșuează) împotriva acestei amenințări.
Acum este momentul să analizăm abordarea noastră la problemă. În acest episod, prezentăm strategia pe care o urmăm la Xygeni pentru... Avertizare timpurie privind programele malware Sistemul (MEW). Cum funcționează acest sistem multi-etapă în timp real atunci când este lansată 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 o analiză manuală pentru a confirma natura unui candidat la pachet malițios. De asemenea, vom explica cum ajutăm NPM, GitHub, PyPI și alte infrastructuri cheie din ecosistemele open-source să reducă timpul de prezență a programelor malware.
pipeline
Xygeni Malware Early Warning (MEW) procesează continuu componente, fie fișiere tar pentru biblioteci și framework-uri pentru ecosisteme de programare acceptate, cum ar fi JavaScript/Node sau Python, imagini de containere Docker/OCI, fie extensii și plugin-uri pentru instrumente precum IDE-uri sau CI/CD sisteme. Astfel de componente sunt publicate în registre publice cu diferite niveluri de verificare a utilizatorilor.
Următoarea este o reprezentare schematică a modului în care funcționează sistemul:
descoperitor Procesul primește fluxul evenimentelor de publicare. Un eveniment de publicare este crearea unei versiuni noi a unei componente noi sau existente. Deoarece registrele populare nu oferă un mecanism de tip „pub-sub” pentru consumatorii interesați, acest lucru se face adesea prin interogarea registrului pentru evenimente recente. Un proiect excelent din partea OSSF, fluxuri de pachete, sprijin registre populare precum PyPI sau Maven Central și oferă o interfață unificată bazată pe fluxuri de date. În MEW am adăugat câteva implementări specifice care reduc timpul de așteptare, de exemplu cu o replică a bazei de date CouchDB utilizată de NPM, care este sincronizată cu baza de date a registrelor publice.
În Xygeni, avem un inventar[1] a tuturor componentelor (directe sau indirecte) utilizate de software-ul clienților noștri. Coordonatele componentelor clienților sunt transmise în mod regulat către MEW pentru prioritizarea analizelor: componentele utilizate de clienții noștri sunt procesate mai devreme. Prioritatea se bazează și pe reputația editorului și pe importanța componentei, astfel încât componentele provenite de la editori cu o reputație scăzută sunt, de asemenea, prioritizate.
analizoare apoi consumă componentele în așteptare din coada de prioritate. Când o versiune de componentă este selectată pentru analiză, fișierul tarball al acesteia este descărcat din registru. Rețineți că este analizată componenta binară, ambalată: Majoritatea componentelor open source provin de obicei dintr-un depozit open source, adesea pe github.com, care este utilizat doar pentru context, iar malware-ul este întotdeauna căutat în fișierul tarball al componentelor, deoarece actorii amenințători mint sistematic despre sursele pe care pretind că le-au folosit pentru a construi fișierul tarball al componentelor pe care îl lansează.
Din perspectiva utilizatorului
Te aud gândindu-te: Cum pot beneficia de faptul că știu din timp despre o versiune de pachet rău intenționată? În episod „Anatomia pachetelor rău intenționate: Care sunt tendințele?” Am observat că timpul total de așteptare este de câteva zile, în timp ce prima notificare de la MEW către clienții care utilizează componenta afectată este de câteva minute. Cu o simplă barieră de protecție[2] Puteți bloca compilarea (există două niveluri de alertă, unul complet automatizat atunci când motorul concluzionează că există un potențial malware și o notificare ulterioară atunci când echipa noastră de securitate confirmă prin inspecție manuală prezența malware-ului). Așteptarea până când registrul confirmă malware-ul și îl elimină din registru este de obicei prea târzie din cauza ferestrei lungi de expunere.
Organizația poate utiliza un sistem de protecție care verifică dacă există o componentă cu potențial malware (în oricare dintre cele două niveluri de alertă) sau, prin intermediul API-ului, poate afla rapid dacă vreuna dintre dependențele directe sau indirecte dintr-un proiect software utilizează o componentă rău intenționată.
Cum funcționează MEW: Detalii din interior
Nucleul: Motor de detectare a programelor malware
Analizatorul folosește detectori diferiți pentru a capta dovezi ale abaterilor. Detectorii combină analiza statică, analiza capacităților și analiza contextului.[3], așa cum este descris în postarea anterioară a acestei serii.
La Xygeni, avem o echipă de ingineri cu o vastă experiență în analiza statică, iar aceasta este principala diferență față de alte soluții anti-malware. Rețineți că pentru unele ecosisteme, arhiva tarball conține fie cod sursă (de exemplu, cod JavaScript sau TypeScript pentru pachetele NPM, surse Python pentru pachetele PyPI), fie cod compilat suficient de apropiat de codul sursă pentru analiza statică (de exemplu, bytecode în fișierele JAR pentru Maven). Pentru altele, cum ar fi imaginile containerelor, executabilele binare sunt comune, așa că inferența capabilităților este tehnica utilizată, împreună cu detectarea convențională a programelor malware bazată pe reguli YARA și semnături malware.
Rețineți că tehnologiile simple, precum expresiile regulate sau semnăturile, nu sunt potrivite pentru detectarea comportamentului rău intenționat. Imaginați-vă că detectați un dropper sau un downloader: Un anumit cod sau un fișier binar se află în pachet sau este descărcat dintr-un domeniu extern, fără legătură cu componenta (ar putea fi unul dintr-un o listă lungă de domenii achiziționate de actorul amenințător[4], Sau un domeniu legitim pentru a evita detectarea). Codul respectiv este apoi executat folosind una dintre funcțiile aferente. Codul poate fi transformat pentru a ascunde adresa URL de descărcare sau funcția utilizată pentru rularea codului descărcat. Este necesară o analiză completă a fluxului de date pentru a-l detecta, utilizând întregul mecanism de analiză statică sau o execuție în sandbox (dacă sunt îndeplinite condițiile pentru rularea unui comportament rău intenționat) ar putea detecta acest lucru în cazul general.
Actorii amenințători urmează aceleași tehnici, iar detectoare pentru aceștia au fost proiectate și implementate. Există, de asemenea, câțiva pași de preprocesare, de exemplu pentru eliminarea ofuscării, adesea necesari pentru a descoperi comportamentul ascuns.
Adăugarea contextului
Unele detectoare folosesc informații contextuale. De exemplu, o nepotrivire între versiunea din registrul componentelor și eticheta/lansarea din depozitul GitHub asociat constituie o dovadă puternică că, probabil, un actor rău intenționat a obținut acreditări de publicare pentru registru, dar nu și pentru depozitul GitHub. Atacurile precum cel care afectează furnizorul de portofele cripto carte mare ar putea fi ușor detectată prin această neconcordanță.
A scor de răutate (MS) se calculează pe baza rezultatelor executării detectoarelor, pe baza tăriei dovezilor captate. Nu toate rezultatele sunt la fel, iar ordinea execuției este relevantă.
Reputația utilizatorilor și a componentelor
Nu toți dezvoltatorii open-source sunt creați egali!
Un dezvoltator reputat poate avea contul NPM deturnat (acest lucru se întâmplă chiar și persoanelor preocupate de securitate), iar malware-ul publicat folosind acel cont. Evident, reputația ar trebui să scadă brusc și să-și revină la gloria trecută doar atunci când contul deturnat este recuperat și dezvoltatorul remediază condițiile care au dus la preluarea contului. Reputația este greu de câștigat, dar poate fi pierdută instantaneu.
La MEW, am implementat un sistem cuprinzător de gestionare a reputației pentru a recompensa comportamentul pozitiv și a penaliza activitățile suspecte. Acest sistem începe cu utilizatorii noi într-o poziție neutră și le ajustează reputația în funcție de activitățile lor continue.
Reputația unui utilizator se îmbunătățește prin acțiuni pozitive, cum ar fi menținerea conturilor active pe rețelele sociale, activarea autentificării multi-factor, contribuția regulată la proiecte și semnarea conturilor. commitcu chei verificabile. În schimb, reputația se deteriorează din cauza acțiunilor ostile precum publicarea de programe malware, utilizarea adreselor de e-mail de unică folosință, nesemnarea commitsau prezentând tipare neobișnuite în contribuții.
Scopul principal al sistemului nostru este de a asigura un mediu sigur și de încredere. Acesta realizează acest lucru prin ajustarea dinamică a reputației utilizatorilor în funcție de diverși factori, respectând în același timp preocupările legate de confidențialitate și limitările diferitelor registre.
Un scor intern de reputație este calculat pentru utilizator (prin adăugarea la registru și la contul GitHub atunci când este posibil), împreună cu scorul de răuvoință utilizat în timpul clasificării componentei analizate și pentru o mai bună calificare a persoanelor care fac parte din publicarea componentei.
Au fost găsite dovezi privind comportamentul rău intenționat. Și ce dacă? Procesul de revizuire manuală
Clasificatorul actual setează versiunea componentei analizate într-una din categoriile „confirmată ca fiind rău intenționată”, „probabil rău intenționată”, „risc ridicat”, „risc scăzut” sau „non-rău intenționată”, pe baza pragurilor scorurilor care condensează constatările și a reputației utilizatorului/componentei. O clasificare în categoriile „risc ridicat” sau „probabil rău intenționată” declanșează revizuirea manuală și prima notificare. Categoria „confirmată ca fiind rău intenționată” este setată după revizuirea manuală sau atunci când dovezile corespund cu aceleași dovezi pentru o versiune anterioară care a fost confirmată ca fiind rău intenționată.
Când există suficiente dovezi pentru un potențial comportament rău intenționat, o primă alertă (alertă de carantină) este emisă organizațiilor afectate. Așa cum am menționat anterior, aceasta poate bloca instalarea sau construirea de software care depinde de componenta aflată în carantină.
Asta creează o problemă în sistemul intern MEW. dashboard astfel încât analiștii de securitate pot începe procesul de revizuire manuală pentru componentă. Echipa dispune de instrumente specializate (sandbox, deobfuscatori, distribuție pentru cercetarea programelor malware, instrumente de raportare a programelor malware) pentru evaluarea rapidă a naturii versiunii componentei investigate. Majoritatea programelor malware („anșoa” sau componentele rău intenționate nesofisticate) sunt revizuite.
Rezultatul revizuirii se încheie fie în sigur, deci motorul de analiză automată a găsit un rezultat fals pozitiv care este folosit ca feedback către clasificatorul de învățare automată pentru a învăța modelul; sau confirmat ca fiind rău intenționat, astfel încât componenta este dezvăluită în mod responsabil ca fiind rău intenționată registrului public, în urma procesului de raportare. O a doua notificare este trimisă organizațiilor afectate, care la rândul lor pot să scoată componenta din carantină sau să o blocheze definitiv din procesul de actualizare a versiunii sau din firewall-ul componentei utilizat în registrul lor intern.
Această setare ne permite să analizăm zilnic zeci de mii de versiuni noi și să identificăm zecile care sunt probabil rău intenționate, pe care apoi le examinăm manual. Rețineți din episodul anterior că una la zece mii este rata componentelor rău intenționate pe care o vedem în prezent.
Raportarea către Registru
Am constatat că majoritatea registrelor publice, una dintre coloanele vertebrale ale infrastructurii open source, oferă mecanisme destul de limitate pentru raportarea problemelor de securitate și, în special, a componentelor rău intenționate. Ne străduim să îmbunătățim organizarea de bază a procesului de raportare. De obicei, primim cel mult un e-mail de feedback de la echipa de securitate din registru, care confirmă că componenta a fost eliminată din registru.
Uneori, registrul este utilizat în mod abuziv, încălcându-i termenii de utilizare, dar fără a cauza comportamente rău intenționate în software-ul livrat. Acest lucru este raportat și registrului, dar nu este notificat organizațiilor pentru a limita zgomotul.
Muncă viitoare
Multe îmbunătățiri sunt în prezent pe foaia de parcurs. În primul rând, o portal public pentru starea componentelor sistemului de operare, în special în ceea ce privește dovezile găsite pentru o potențială răuvoință, este în prezent în curs de dezvoltare. Aceasta este concepută ca o contribuție modestă la comunitatea open-source. Rămâneți pe fază.
O altă dezvoltare continuă este o îmbunătățire clasificator de învățare automatăMEW va învăța din clasificările anterioare. Vectorul constatărilor de la detectoarele motorului, plus scorul de răuvoință și scorul de reputație derivate atât pentru componentă, cât și pentru editor („dovezile găsite”) sunt utilizate ca date de intrare într-un sistem de învățare automată care actualizează modelul clasificatorului. Variabila de ieșire este pur și simplu dacă registrul a confirmat dacă componenta a fost rău intenționată. Aceasta poartă numele de cod „Oracolul” și va ajuta la o pregătire mai avansată.cisCalificator e, conceput să fie solid (rată de amintire ridicată, adică să nu rateze componente malițioase), dar cu mai puține rezultate fals pozitive (să nu raporteze componentele sigure ca malițioase).
A scor de criticitate vor fi adăugate pentru criterii de prioritizare, pe lângă apartenența la setul de dependențe ale clienților și reputația scăzută a editorului. Este clar că proiectele cu mai multă influență și importanță ar trebui luate în considerare mai devreme pentru analiză. Nu vom reinventa roata aici și vom urma Scorul de criticitate al proiectului open source.
Suport pentru ecosisteme suplimentare este în curs de dezvoltare. Tehnologii și instrumente răspândite pe scară largă, precum plugin-urile PHP sau Jenkins, sunt în plan.
De asemenea, explorăm dacă procesul de revizuire manuală ar putea fi ajutat cu ajutorul inteligenței artificiale pentru a simplifica analiza câtorva componente rău intenționate mai sofisticate.
În următoarea și ultima parte a acestei serii, „Exploatarea Open Source: La ce să te aștepți de la răufăcători„”, ne vom concentra asupra celor mai recente metode pe care adversarii le adoptă pentru a face atacurile mai discrete, mai greu de detectat, mai direcționate către industrii specifice și mai profitabile. Vor fi lansate atacurile ransomware folosind acest vehicul? Cum utilizează răufăcătorii instrumentele de inteligență artificială pentru a livra programe malware 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 încheia cu câteva reflecții despre pașii mici pe care comunitatea i-ar putea face fără a schimba prea mult deschiderea lumii open-source. De exemplu, un mecanism mai eficient pentru raportarea programelor malware către registrele publice și partajarea dovezilor componentelor potențial malițioase cu registrele și comunitatea ar fi un mic pas în direcția corectă către obiectivul de a închide ușile actorilor amenințători.
Programele malware din componentele open-source nu ar trebui să perturbe beneficiile enorme pe care comunitatea open-source le-a adus societății noastre.
- [1] Scanerul nostru detectează componente open-source la care fac referire proiectele software analizate, astfel încât graficul complet actualizat al dependențelor este cunoscut, cel puțin pentru proiectele scanate în mod regulat. Xygeni OSS expune o API pe care clienții o pot utiliza și în timpul includerii pe lista albă a unei componente de interes, inclusiv informații despre vulnerabilități și dovezi malițioase.
- [2] O barieră de siguranță poate întrerupe compilarea dacă se detectează o condiție care corespunde unor probleme de securitate. Constatările de securitate, cum ar fi o vulnerabilitate critică și accesibilă sau utilizarea unei componente în carantină, ar putea fi considerate suficient de grave pentru a întrerupe compilarea pentru software-ul afectat.
- [3]Analiștii noștri de securitate rulează componenta sau scripturile sale de instalare într-un mediu sandbox atunci când este necesar. Cu toate acestea, MEW nu efectuează analize dinamice, în principal pentru că comportamentul rău intenționat nu este întotdeauna implementat în atacurile direcționate și din cauza logicii de evitare pe care actorii amenințători o folosesc pentru a evita analiza dinamică.
- [4] Această tehnică a primit numele de Algoritmi de Generare a Domeniilor Înregistrate sau RDGA, iar noi actori amenințători, precum așa-numiții Revolver Rabbit a investit până la 1 milion de dolari în 500 de domenii, demonstrând cât de profitabilă este industria criminalității cibernetice.
