Aquest és el quart episodi de la sèrie de publicacions sobre components maliciosos, on presentem el Xígeni enfocament per gestionar aquesta amenaça, com a part de la nostra cobertura per a Open Source Security.
Vam veure que l'excés de confiança en components de codi obert d'origen incert és aprofitat per malfactors de tota mena per generar un comportament inesperat que s'executarà en màquines de desenvolupadors, CI/CD sistemes o integrats al programari de l'organització víctima, de manera que es transmet als clients de l'organització. Vam disseccionar en episodi #2 els atacs que utilitzen registres públics per distribuir programari maliciós i el que hem après després d'observar com operen els malfactors, i en l'anterior episodi #3 es van examinar els controls que funcionen (i els que fallen) contra aquesta amenaça.
Ara és el moment d'analitzar el nostre enfocament del problema. En aquest episodi, presentem quina és l'estratègia que seguim a Xygeni per al nostre Alerta precoç de programari maliciós Sistema (MEW). Com funciona aquest sistema multietapa en temps real quan es publica una nova versió del paquet, com es captura l'evidència de diferents fonts, com es fa el triatge, quins criteris de classificació seguim i per què encara cal alguna anàlisi manual per confirmar la naturalesa d'un candidat a paquet maliciós. També explicarem com estem ajudant NPM, GitHub, PyPI i altres infraestructures clau en els ecosistemes de codi obert a reduir el temps de permanència del programari maliciós.
L' pipeline
Xygeni Malware Early Warning (MEW) processa components contínuament, ja siguin fitxers tar de paquets per a biblioteques i marcs de treball per a ecosistemes de programació compatibles com ara JavaScript/Node o Python, imatges de contenidors Docker/OCI o extensions i complements per a eines com ara IDE o... CI/CD sistemes. Aquests components es publiquen en registres públics amb diferents nivells de verificació d'usuaris.
A continuació es mostra un esquema de com funciona el sistema:
L' descobridor El procés rep el flux dels esdeveniments de publicació. Un esdeveniment de publicació és la creació d'una nova versió d'un component nou o existent. Com que els registres populars no proporcionen un mecanisme de publicació i subscripció per als consumidors interessats, això sovint es fa consultant el registre per a esdeveniments recents. Un projecte excel·lent de l'OSSF, fonts de paquets, suport registres populars com PyPI o Maven Central, i proporcionen una interfície unificada basada en canals. A MEW hem afegit algunes implementacions específiques que redueixen el temps d'espera, per exemple amb una rèplica de la base de dades CouchDB utilitzada per NPM que està sincronitzada amb la base de dades del registre públic.
A Xygeni, tenim un inventari[1] de tots els components (directament o indirectament) utilitzats pel programari dels nostres clients. Les coordenades dels components dels clients s'introdueixen regularment a MEW per prioritzar les anàlisis: els components utilitzats pels nostres clients es processen abans. La prioritat també es basa en la reputació de l'editor i la importància del component, de manera que els components procedents d'editors amb baixa reputació també es prioritzen.
L' analitzadors després consumeixen els components pendents de la cua de prioritat. Quan es selecciona una versió de component per a l'anàlisi, el seu fitxer tar es descarrega del registre. Tingueu en compte que s'analitza el component binari empaquetat: la majoria dels components de codi obert solen provenir d'un repositori de codi obert, sovint a github.com, que s'utilitza només per al context, i el programari maliciós sempre es busca al fitxer tar del component perquè els actors amenaçadors menteixen sistemàticament sobre les fonts que afirmen haver utilitzat per construir el fitxer tar del component que publiquen.
Des de la perspectiva de l'usuari
Et sento pensar: Com puc beneficiar-me de conèixer una versió de paquet maliciosa aviat? A l'episodi "Anatomia dels paquets maliciosos: quines són les tendències?" vam veure que el temps de permanència total és de l'ordre de dies, mentre que la primera notificació de MEW als clients que utilitzen el component afectat és de l'ordre de minuts. Amb una simple barrera de seguretat[2] Podeu bloquejar la compilació (hi ha dos nivells d'alerta, un completament automatitzat quan el motor conclou que hi ha programari maliciós potencial i una notificació posterior quan el nostre equip de seguretat confirma mitjançant una inspecció manual la presència de programari maliciós). Esperar fins que el registre confirmi el programari maliciós i l'elimini del registre sol ser massa tard a causa de la llarga finestra d'exposició.
L'organització pot utilitzar una barrera de seguretat que comprovi si hi ha un component amb potencial programari maliciós (en qualsevol dels dos nivells d'alerta) o, mitjançant una API, saber ràpidament si alguna de les dependències directes o indirectes d'un projecte de programari utilitza un component maliciós.
Com funciona MEW: detalls interns
El nucli: motor de detecció de programari maliciós
L'analitzador utilitza diferents detectors per capturar proves de irregularitats. Els detectors combinen anàlisi estàtica, anàlisi de capacitats i anàlisi de context.[3], tal com s'ha descrit a l'entrada anterior d'aquesta sèrie.
A Xygeni, tenim un equip d'enginyeria amb una llarga experiència en anàlisi estàtica, i aquesta és la principal diferència amb altres solucions antimalware. Cal tenir en compte que per a alguns ecosistemes, el tarball empaquetat conté codi font (per exemple, codi JavaScript o TypeScript per a paquets NPM, fonts Python per a paquets PyPI) o codi compilat prou proper al codi font per a l'anàlisi estàtica (per exemple, bytecode en fitxers JAR per a Maven). Per a d'altres, com ara imatges de contenidors, els executables binaris són habituals, de manera que la inferència de capacitats és la tècnica utilitzada, juntament amb la detecció convencional de programari maliciós basada en regles YARA i signatures de programari maliciós.
Tingueu en compte que les tecnologies simples com les expressions regulars o les signatures no són adequades per detectar comportaments maliciosos. Imagineu-vos detectar un dropper o un downloader: algun codi o binari es troba al paquet o es descarrega des d'un domini extern, no relacionat amb el component (podria ser un d'un llarga llista de dominis comprats per l'actor de l'amenaça[4], O 1 domini legítim per evitar la detecció). Aquest codi s'executa mitjançant una de les funcions per a això. El codi es pot transformar per ocultar l'URL de descàrrega o la funció utilitzada per executar el codi descarregat. Cal una anàlisi completa del flux de dades per detectar-lo, utilitzant tota la maquinària de l'anàlisi estàtica o una execució en un espai de proves (si realment es compleixen les condicions perquè s'executi un comportament maliciós) podria detectar-ho en el cas general.
Els actors amenaçadors segueixen les mateixes tècniques i es van dissenyar i implementar detectors per a ells. També hi ha alguns passos de processament previ, per exemple per eliminar l'ofuscació, sovint necessaris per descobrir el comportament ocult.
Afegir context
Alguns detectors utilitzen informació de context. Per exemple, una discrepància entre la versió del registre del component i l'etiqueta/llançament del repositori de GitHub associat constitueix una prova sòlida que potser un actor malintencionat va obtenir credencials de publicació per al registre però no per al repositori de GitHub. Atacs com el que afecta el proveïdor de moneders criptogràfics llibre major es podria detectar fàcilment per aquesta discrepància.
A puntuació de malícia (MS) es calcula a partir dels resultats de l'execució dels detectors, basant-se en la solidesa de les proves capturades. No tots els resultats són iguals, i l'ordre d'execució és rellevant.
Reputació d'usuaris i components
No tots els desenvolupadors de codi obert són iguals!
Un desenvolupador de bona reputació pot tenir el seu compte NPM segrestat (això passa fins i tot amb persones conscients de la seguretat) i publicar programari maliciós utilitzant aquest compte. Òbviament, la reputació hauria de caure bruscament i només recuperar-se a la glòria passada quan es recuperi el compte segrestat i el desenvolupador corregeixi les condicions que van conduir a la presa de control del compte. La reputació és difícil de guanyar, però es pot perdre en un instant.
A MEW, hem implementat un sistema integral de gestió de la reputació per recompensar el comportament positiu i penalitzar les activitats sospitoses. Aquest sistema comença amb els nous usuaris en una postura neutral i ajusta la seva reputació en funció de les seves activitats contínues.
La reputació d'un usuari millora mitjançant accions positives com ara mantenir comptes actius a les xarxes socials, habilitar l'autenticació multifactor, contribuir regularment a projectes i signar. commits amb claus verificables. Per contra, la reputació es deteriora a causa d'accions hostils com ara la publicació de programari maliciós, l'ús d'adreces de correu electrònic d'un sol ús o la no signatura commits, o que presenten patrons inusuals en les contribucions.
L'objectiu principal del nostre sistema és garantir un entorn segur i de confiança. Ho aconsegueix ajustant dinàmicament la reputació dels usuaris en funció de diversos factors, respectant alhora les preocupacions sobre la privadesa i les limitacions dels diferents registres.
Es calcula una puntuació de reputació interna per a l'usuari (unint-se al registre i al compte de GitHub quan sigui possible), juntament amb la puntuació de malícia utilitzada durant la classificació del component en anàlisi i per qualificar millor qui es troba sota la publicació del component.
Es van trobar proves de comportament maliciós. I què? El procés de revisió manual
El classificador actual estableix la versió del component analitzat en una de les categories "confirmat maliciós", "probablement maliciós", "alt risc", "baix risc" o "no maliciós" basant-se en els llindars de les puntuacions que condensen els resultats i la reputació de l'usuari/component. Una classificació en categories "alt risc" o "probablement maliciós" activa la revisió manual i la primera notificació. La categoria "confirmat maliciós" s'estableix després de la revisió manual o quan l'evidència coincideix amb la mateixa evidència d'una versió anterior que es va confirmar com a maliciós.
Quan hi ha prou proves d'un possible comportament maliciós, s'emet una primera alerta (alerta de quarantena) a les organitzacions afectades. Com s'ha esmentat anteriorment, això pot bloquejar la instal·lació o la compilació de programari que depèn del component en quarantena.
Això crea un problema intern al MEW. dashboard així els analistes de seguretat poden iniciar el procés de revisió manual del component. L'equip disposa d'eines especialitzades (sandbox, desofuscadors, distribució per a la investigació de programari maliciós, eines d'informes de programari maliciós) per avaluar ràpidament la naturalesa de la versió del component que s'està investigant. La major part del programari maliciós ("les anxoves" o components maliciosos no sofisticats) es revisa.
El resultat de la revisió conclou en qualsevol dels dos casos segur, de manera que el motor d'anàlisi automàtic ha trobat un fals positiu que s'utilitza com a retroalimentació al classificador d'aprenentatge automàtic per aprendre el patró; o confirmat maliciós, de manera que el component es revela responsablement com a maliciós al registre públic, després del procés d'informe. S'envia una segona notificació a les organitzacions afectades, que al seu torn poden treure el component de la quarantena o bloquejar-lo definitivament del procés d'actualització de versió o del tallafocs de components utilitzat al registre intern.
Aquesta configuració ens permet analitzar desenes de milers de versions noves diàriament i identificar les desenes que probablement són malicioses, que després revisem manualment. Recordeu de l'episodi anterior que una de cada deu mil és la taxa de components maliciosos que veiem actualment.
Informe al Registre
Hem descobert que la majoria de registres públics, un dels pilars de la infraestructura de codi obert, proporcionen mecanismes força limitats per informar de problemes de seguretat, i en particular de components maliciosos. Estem lluitant per millorar l'organització subjacent del procés d'informació. Normalment rebem com a màxim un correu electrònic de comentaris de l'equip de seguretat del registre confirmant que el component s'ha eliminat del registre.
De vegades, el registre s'abusa, incomplint els seus termes d'ús, però sense causar un comportament maliciós en el programari lliurat. Això també es notifica al registre, però no es notifica a les organitzacions per limitar el soroll.
Treballs futurs
Actualment hi ha moltes millores a la full de ruta. En primer lloc, una portal públic per a l'estat dels components del sistema operatiu, en particular en relació amb les proves trobades de possible malícia, està actualment en desenvolupament. Això pretén ser una modesta contribució a la comunitat de codi obert. Estigueu atents.
Un altre desenvolupament continu és una millora classificador d'aprenentatge automàtic. MEW aprendrà de classificacions anteriors. El vector de troballes dels detectors del motor, a més de la puntuació de malícia i la puntuació de reputació derivades tant del component com de l'editor ("l'evidència trobada") s'utilitza com a entrada per a un sistema d'aprenentatge automàtic que actualitza el model classificador. La variable de sortida és simplement si el registre ha confirmat si el component era maliciós. Això rep el nom en clau "l'Oracle" i ajudarà amb una previsió més precisa.cisqualificador electrònic, dissenyat per ser sòlid (alta recuperació, és a dir, no passar per alt components maliciosos) però amb menys falsos positius (no informar de components segurs com a maliciosos).
A puntuació de criticalitat s'afegirà per als criteris de priorització, a més de pertànyer al conjunt de dependències dels clients i la baixa reputació de l'editor. És clar que els projectes amb més influència i importància s'haurien de considerar abans per a l'anàlisi. No reinventarem la roda aquí i seguirem les Puntuació de criticalitat de projectes de codi obert.
S'està desenvolupant el suport per a altres ecosistemes. Tecnologies i eines generalitzades com ara complements de PHP o Jenkins estan a la full de ruta.
També estem explorant si el procés de revisió manual es podria complementar amb la IA per optimitzar l'anàlisi dels pocs components maliciosos més sofisticats.
En la següent i última entrega d'aquesta sèrie, “Explotació del codi obert: què esperar dels dolents", ens centrarem en les últimes maneres que els adversaris estan prenent per fer que els atacs siguin més furtius, més difícils de detectar, més dirigits a indústries específiques i més rendibles. Es faran servir aquest vehicle per als atacs de ransomware? Com aprofiten els delinqüents les eines d'IA per llançar programari maliciós més sofisticat? Els projectes més populars estan en risc? Això és per donar als lectors una idea d'aquesta cursa armamentística i què esperar a curt termini (segona meitat del 2024) i a mitjà termini (2025).
Conclourem amb algunes reflexions sobre els petits passos que la comunitat podria fer sense canviar massa l'obertura del món del codi obert. Per exemple, un mecanisme més eficient per informar de programari maliciós als registres públics i compartir proves de components potencialment maliciosos amb els registres i la comunitat seria un petit pas en la direcció correcta cap a l'objectiu de tancar les portes als actors amenaçadors.
El programari maliciós en components de codi obert no hauria de pertorbar els enormes beneficis que la comunitat de codi obert ha aportat a la nostra societat.
- [1] El nostre escàner detecta components de codi obert als quals fan referència els projectes de programari analitzats, de manera que es coneix el gràfic de dependències complet i actualitzat, almenys per als projectes que s'escanegen regularment. L'OSS de Xygeni exposa una API que els clients també poden utilitzar durant l'inclusió a la llista blanca d'un component d'interès, inclosa informació sobre vulnerabilitats i proves malicioses.
- [2] Una barrera de seguretat pot interrompre la compilació si es detecta una condició que coincideixi amb problemes de seguretat. Les troballes de seguretat com ara una vulnerabilitat crítica i accessible o l'ús d'un component en quarantena es podrien considerar prou greus com per interrompre la compilació del programari afectat.
- [3]Els nostres analistes de seguretat executen el component o els seus scripts d'instal·lació en un entorn de proves quan cal. Tanmateix, MEW no realitza anàlisis dinàmiques, principalment perquè el comportament maliciós no sempre es realitza en atacs dirigits i a causa de la lògica d'evasió que els actors d'amenaces utilitzen per evadir l'anàlisi dinàmica.
- [4] Aquesta tècnica va rebre el nom d'Algoritmes de Generació de Dominis Registrats o RDGA, i nous actors d'amenaces com els anomenats Revòlver Conill va invertir fins a 1 milió de dòlars en 500 dominis, cosa que demostra la rendibilitat de la indústria de la ciberdelinqüència.
