Aquest és el primer episodi d'una sèrie d'articles sobre el tipus més prevalent d'atacs a la cadena de subministrament de programari: aquells que (ab)usen un registre públic de components de programari, destinats a projectes de codi obert per carregar artefactes que es podrien compartir amb altres usuaris. Quan els delinqüents publiquen programari maliciós allà, utilitzant el registre com a vehicle per a la distribució de programari maliciós, tenim un atac a la cadena de subministrament quan les organitzacions víctimes instal·len o executen el component de programari infectat.
Per simplificar la discussió, parlarem de paquets de programari:, components en forma empaquetada produïts per tercers. Això inclou no només els components utilitzats per gestors de paquets com ara NPM o Poetry, sinó també components del sistema operatiu incloent-hi biblioteques i binaris executables, imatges de contenidors, i màquines virtuals, o extensions d'eines per a eines de desenvolupament, compilació i desplegament. Hem vist paquets maliciosos a tot arreu. Als ciberdelinqüents no els importa: estan encantats amb les alternatives que ofereixen les infraestructures de programari modernes i utilitzen el registre i l'eina que millor s'adapten a la seva intenció. Per tant, recordeu que els paquets de programari són una abreviatura per a imatges de contenidors, paquets binaris, repositoris de codi obert i extensions o complements de tota mena (IDE, CI/CD sistemes, eines de construcció). Tots són atacats de manera rutinària.
La sèrie tindrà 5 episodis:
- Quin és el problema amb els paquets de codi obert? Aquest és el tema d'aquesta publicació. Per què els delinqüents de tota mena publiquen paquets maliciosos? Per què m'hauria de preocupar?
- Anatomia dels paquets maliciosos: quines són les tendències? En aquest episodi, ens centrem en l'amenaça que estem monitoritzant amb el nostre sistema MEW, dia rere dia. Amb un gran soroll de fons a causa d'un gran nombre de paquets maliciosos que utilitzen typosquatting o confusió de dependències, un percentatge menor d'atacs són molt més insidiosos i representen un risc més gran. Com ha canviat el comportament dels malfactors respecte al sistema operatiu en el passat recent? Quines són les xifres? Quines són les tàctiques, tècniques i procediments utilitzats, i les accions nocives observades?
- Protecció contra paquets maliciosos de codi obert: què funciona (o no funciona)La majoria de professionals amb coneixements de seguretat tenen idees sobre com gestionar aquesta amenaça. Hem sentit els responsables de seguretat dir sense dubtar-ho que SCA Les eines ja us indiquen quan una versió d'un paquet és programari maliciós. O que depenen de components de programari coneguts i altament revisats, on qualsevol programari maliciós es detectaria i s'eliminaria ràpidament. Que utilitzen versions menors/pegats obertes per obtenir automàticament correccions de vulnerabilitats, i que aquesta és la manera correcta i recomanada de reduir el risc en les dependències de codi obert, seguint el principi de "pegar aviat, pegar sovint". En aquest episodi, revisarem per què aquestes idees són errònies i com aquests conceptes erronis contribueixen a la popularitat d'aquest mecanisme d'atac i a un risc aclaparador que estan experimentant les organitzacions. Acabarem amb el que funciona i quin és l'esforç i els recursos implicats.
- Paquets maliciosos de codi obert: l'enfocament XygeniEn aquest episodi, presentem quina és l'estratègia que seguim a Xygeni per al nostre sistema d'alerta primerenca de programari maliciós (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? Com els comentaris dels nostres equips interns i de registre ajuden el sistema a aprendre de l'evidència anterior recopilada per reduir al mínim els falsos positius. I explicarem com estem ajudant NPM, GitHub, PyPI i altres infraestructures clau en els ecosistemes de codi obert a reduir el temps de permanència..
- Explotació del codi obert: què esperar dels dolentsLa sèrie acaba centrant-se en les accions més noves que els adversaris estan adoptant per fer que els atacs siguin més furtius, més difícils de detectar, més dirigits a indústries específiques i per obtenir més beneficis d'aquesta classe d'atacs. Es realitzaran els atacs de ransomware utilitzant aquest vehicle? Com aprofiten els delinqüents les eines d'IA per lliurar paquets maliciosos més sofisticats? Els projectes més populars estan en perill? Això és per donar als lectors una idea sobre aquesta cursa armamentística i què esperar a curt termini (segona meitat del 2024) i a mitjà termini (2025). Aprendrem com atacs com el recent Porta del darrere XZ-Utils, o l'atac de viure fora de la terra a electron-builder al març de 2024 mostren que hem de mantenir-nos alerta sobre com evolucionen els adversaris.
Obrim l'escenari amb el primer episodi: Què passa amb els paquets de codi obert maliciosos?
Quin és el problema amb els paquets de codi obert?
En els darrers anys, delinqüents de tota mena han utilitzat registres de programari de codi obert per a dur a terme comportaments maliciosos. Aquestes activitats són tan antigues com el programari de codi obert, però la seva freqüència ha augmentat exponencialment en els darrers tres anys.
Publicació de components maliciosos en registres públics (atacs basats en dependències) és una guerra de guerrilles asimètrica que els actors d'amenaces utilitzen per distribuir programari maliciós, aprofitant la confiança que les organitzacions dipositen en components de codi obert procedents de desenvolupadors desconeguts (recordeu el dependència xkcd còmic?). Com que confieu en els paquets i no us importa revisar manualment el contingut del paquet i les seves dependències, aquests atacs són extraordinàriament efectius. I l'asimetria es produeix perquè es poden automatitzar en gran mesura i els delinqüents no necessiten interactuar directament amb la víctima. Simplement carreguen el paquet al registre públic i el deixen anar.
Paquets maliciosos es va multiplicar per 6 el 2022, i va continuar creixent per un factor de 2.5 el 2023. L'any passat es van veure la friolera de 245,000 paquets maliciosos, una xifra que duplica amb escreix el nombre total dels anys anteriors combinats. Això és un creixement exponencial! Des de centenars d'eliminacions de paquets com a programari maliciós confirmat durant el 2021 i milers durant el 2022, vam veure molt més "soroll" de fons durant el 2023, amb un ritme similar per a aquest any. I amagat en aquest fons causat per ciberdelinqüents poc sofisticats que seguien el "camí de menor resistència", una minoria d'atacs d'alt perfil van arribar als titulars fins i tot en els mitjans de comunicació generals.
Per què és aquest un problema d'aquesta magnitud? Hi ha un excés de confiança a tota la cadena. El programari de codi obert es distribueix amb el seu codi font i es publica sota una llicència determinada. Sí, qualsevol pot inspeccionar el codi font; però, qui ho fa en general? Qui, després d'inspeccionar que el programari no té programari maliciós, crea el programari a partir dels codis font? Qui, abans de passar el component empaquetat (també conegut com a paquet) aigües avall del gestor de paquets o de l'eina de compilació, s'assegura que el paquet no estigui ple de programari maliciós i que correspongui al suposat codi font del qual hauria de provenir?
Per què la infraestructura permet atacs tan fàcils?
Registres de paquets són oberts, sovint requereixen una verificació mínima de la identitat de l'editor. "Tothom és benvingut a publicar el seu programari aquí!" El llistó per als atacants és baix: utilitzen adreces de correu electrònic d'un sol ús i comptes de GitHubgithub d'un sol ús per crear centenars de paquets maliciosos en campanyes curtes, semblants a les de suplantació d'identitat. Només per als atacs dirigits es necessita una major sofisticació: fins i tot vam veure la creació d'un repositori de codi font de GitHub creïble amb moltes estrelles i commitde múltiples col·laboradors falsos i altres mètriques de popularitat i manteniment. Obtenint observadors d'estrelles i reputació a partir de contribucions falses no és difícil d'automatitzar. Vam veure abusos en infraestructures de programari obert de tota mena, no només programari maliciós, com ara incident del protocol del te.
Els gestors de paquets van ser dissenyats per a la facilitat d'ús i no per a la seguretat.Poden executar scripts previs i posteriors a la instal·lació (de vegades cal compilar codi natiu per a una biblioteca). A més, Gestors de paquets instal·len paquets des de diverses fonts i, de vegades, el valor per defecte és utilitzar registres públics. No van comprovar si hi havia una discrepància entre les metadades de la sol·licitud de publicació i les metadades del paquet en si.
Les dependències estan imbricades i formen un graf. En certs ecosistemes com Node (JavaScript), les dependències de granularitat petita s'acumulen en centenars o milers. Una cosa és tenir un control estricte sobre les dependències directes declarades pels meus projectes de programari, però dependències transitives són més difícils de controlar. El codi obert seguia el principi de "els amics dels meus amics són els meus amics". La germanor és la norma al salvatge Orient! Els actors amenaçadors ho saben i amaguen profundament el comportament maliciós en dependències obscures que sovint són desconegudes. Aquest va ser el cas amb flux d'esdeveniments incident dirigit a Cartera de copagament.
Així és com ha funcionat el programari de codi obert des dels seus inicis. No canviarà gaire. Alguns registres de paquets exigeixen, com a màxim, autenticació de dos factors, i sovint només per als paquets més populars. Alguns registres proporcionen àmbits, un espai de noms propietat d'una organització verificada, però tràgicament altres no ho admeten (PyPI) o ho fan opcional (NPM). És interessant observar que fins i tot un esquema de cribratge senzill (basat en el control del DNS o del repositori/organització de GitHub que coincideix amb l'ID del grup) i fent Signatures PGP obligatòries per a tots els artefactes excepte les sumes de verificació elimina la major part del "soroll", els paquets maliciosos tipus typosquatting i limita gran part de confusió de dependènciesEls atacs sofisticats són possibles però molt més difícils, amb només uns quants com el com.github.codingandcoding:maven-compiler-plugin conegut per Maven Central. I no tots els registres de Maven segueixen les mateixes pràctiques!
Els controls de seguretat dels gestors de paquets poden sobrecarregar, però no impedeixen els atacs de dependència. El problema amb l'autenticació multifactor és que, per a l'automatització, es generen credencials derivades com ara tokens d'accés o claus APIapi per als comptes que s'utilitzaran en crides APIapi fetes des de scripts d'automatització, sense que l'usuari interactiu de suport proporcioni un segon factor. L'MFA és bo per protegir els comptes d'usuari de les filtracions de contrasenyes, però els tokens d'accés o les claus APIapi generats s'han de protegir mentre estan actius, o el seu propietari serà suplantat pels adversaris. Una gran part de les campanyes de la cadena de subministrament basades en paquets comencen amb una clau/token filtrat. Només cal recordar incidents com llibre major, 3CX, i molts més, on les credencials no interactives es van exfiltrar per primera vegada en una intrusió preliminar per llançar l'atac a la cadena de subministrament.
La resposta donada a aquesta amenaça no va ser prou contundent. En el tercer episodi, ens centrarem en què va funcionar i què va fracassar estrepitosament. La indústria ha de treballar col·lectivament en standards, processos, formació i eines per mitigar els riscos per a les cadenes de subministrament globals. Aquest no és un problema que una sola organització pugui resoldre per si sola.
Per acabar aquesta secció, el malentès crucial: estem parlant de maliciós paquets, no vulnerable unes. Les vulnerabilitats provenen d'errors de disseny o de codificació, introduïts accidentalment, sense mala intenció. Les vulnerabilitats poden ser explotades, però moltes no ho són. Els paquets maliciosos sempre són intencionats i hi ha una explotabilitat del 100% si s'executen. No hi ha cap risc comparable! Per tant És paradoxal veure quants esforços es dediquen a detectar i mitigar vulnerabilitats, i la manca de mesures equivalents per a components maliciosos..
«Ens prenem la seguretat seriosament»
Imaginem l'habitual Corporació AcmeAcme, un proveïdor important de WileCoyote.com, té la major part del seu programari procedent de tercers, amb més del 80% de projectes de codi obert. Produeixen programari per a ús intern, però també proporcionen programari per als seus socis, proveïdors i clients/usuaris finals. Acme té programari escrit en Go, JavaScript, Java, C# i Python, i executa la major part del seu programari al núvol, sota clústers de Kubernetes. Acme crea les seves imatges personalitzades a partir d'imatges base extretes de Docker Hub i altres registres. I també comparteixen algunes biblioteques, paquets i imatges de contenidors en registres públics.
Acme es pren seriosament la seguretat. Són força conscients del problema de open source security, i el risc que comporta. Tots els desenvolupadors, administradors de sistemes i enginyers de DevOpsdevops utilitzen aquestes petites i simpàtiques claus criptogràfiques com a autenticació de segon factor. Tot commitEls repositoris de codi estan signats, la protecció de branques està habilitada amb revisions de codi obligatòries, CI/CD secrets bloquejats i emmagatzemats en una volta secreta, i amb un registre intern que reflecteix parcialment registres externs on només s'emmagatzemen els components permesos de la llista blanca. Cal que el programari creat per Acme prengui dependències de tercers d'aquest registre.
Probablement la majoria d'organitzacions encaixen en aquest perfil. Benvolgut lector, la teva sens dubte encaixa si ja ets aquí, oi?
Aleshores, un dia desafortunat, un important desenvolupador frontend a Acme va córrer instal·lació de npm acme-cute-lib, oblidant que @acme/cute-lib era la dependència amb àmbit correcte. L'error exacte no és important, moltes coses poden sortir malament fins i tot quan s'assumeix un control perfecte del cicle de vida del programari. El nostre desenvolupador no sabia que un grup APT estava atacant Acme i va publicar un component maliciós amb aquest nom, d'una manera astuta, de manera que el comportament maliciós només s'activa quan el programari s'instal·la als ordinadors Acme. El paquet no es va detectar durant setmanes després de la seva publicació.
S'executa un script d'instal·lació que busca credencials (hi havia molts tokens d'accés interessants al portàtil del nostre desenvolupador), permetent l'accés als repositoris de programari interns i al repositori intern esmentat anteriorment, que per descomptat només és accessible mitjançant VPN. El codi maliciós va aconseguir utilitzar la connexió VPN existent i publicar un component maliciós de segona etapa al registre intern, afectant una biblioteca d'utilitats comuna compartida per la majoria del programari lliurat per Acme.
Setmanes després, altres organitzacions que utilitzaven les eines publicades d'Acme van començar a veure trànsit estrany a les seves xarxes, amb trànsit que utilitzava el protocol d'Acme però dirigit a hosts que s'assemblaven al domini Acme. El trànsit estava xifrat, però les eines de monitorització del sistema van trobar accés a fitxers inesperats i l'execució de processos que semblen ordres del sistema però que acaben executant executables descarregats.
La resta és història: Acme va negar inicialment que aquest comportament els fos imputable i que totes les mesures de seguretat estiguessin implementades. Només després que els mitjans de ciberseguretat comencessin a preguntar per què la font del comportament detectat provenia dels components d'Acme, i l'anàlisi de seguretat publiqués com de plens estaven aquests components de programari maliciós furtiu, Acme va haver de reconèixer l'incident i va trucar a una empresa de resposta a incidents. Una campanya de màrqueting negativa que va minar la confiança guanyada amb esforç en un segon.Acme estava a una instal·lació npm de disaster«era un titular comú. Després van seguir el mateix llegendari els plets i els contractes cancel·lats.
Veieu semblances amb incidents passats coneguts? Acme va patir un incident de la cadena de subministrament en dues fases, utilitzant una barreja de confusió de dependències/typosquatting atacs que utilitzaven una estació de treball de desenvolupador com a punt de partida per infectar components que acabaven en programari utilitzat per tercers. Com es podria prevenir o mitigar això?
Per què els paquets enverinats són tan populars
Aquest incident hipotètic demostra que, fins i tot amb un enfocament raonable de la seguretat de codi obert, les organitzacions necessiten mesures específiques per evitar ser víctimes de programari maliciós en components de codi obert. Esquemàticament, l'actor de l'amenaça pot:
- Crea un paquet nou (seguint les conegudes vies de typosquatting o confusió de dependències, aquest és el camí més transitat pels delinqüents en volum);
- Intenta infectar-ne un d'existent, ja sigui injectant-lo al codi font, intentant disfressar-lo com a contribuent mitjançant pull request, o utilitzant l'enginyeria social per convertir-se en mantenidor (com va fer "Jao Tan" a XZ Backdoor o ctrl dreta9 L'usuari de GitHub va fer en el flux d'esdeveniments incident a la tardor del 2018), o obtenint credencials de repositori de codi obert i fent-se passar pel mantenidor;
- Injectar programari maliciós durant la compilació del paquet, ja sigui executant un script de compilació maliciós., o interferint amb les descàrregues de paquets amb intercepcions man-in-the-middle (afortunadament, ara TLS sempre és necessari a la majoria de registres).
- Injecteu el component empaquetat directament al registre, normalment capturant les credencials del registre (l'alternativa preferida per a molts atacs sofisticats com el d'Acme, on l'estació de treball compromesa en la primera etapa tenia el testimoni d'accés intern al registre, per exemple, en l'habitual .NS or ~/.m2/settings.xml: els malfactors saben on buscar secrets). També es van explotar vulnerabilitats als registres.
Enverinar registres amb programari maliciós és la base dels atacs de dependències. Res de nou sota el sol: la seva prevalença ha explotat, però les mateixes tècniques funcionen ara que fa cinc anys.
El paquet maliciós pot operar durant la instal·lació, durant la compilació del programari o en temps d'execució. I el comportament va des de l'exfiltració d'informació, per exemple, l'extracció de secrets per a un intent de segona fase, fins a l'extracció de codi font i la descartació de programari maliciós addicional. En el proper episodi, analitzarem els paquets maliciosos i com es publiquen.
Altres lectures
El següent episodi Anatomia dels paquets maliciosos: quines són les tendències? ens centrarem en casos reals que estem monitoritzant amb el nostre sistema d'alerta primerenca de programari maliciós, dia rere dia. Revisarem quins tipus de programari maliciós s'han detectat i quines tàctiques, tècniques i procediments són els preferits. Examinarem l'ofuscació i com intenten amagar-se dels possibles revisors, les tècniques d'evasió per evitar la detecció i com estan evolucionant amb la telemetria i el moviment lateral. Estigueu atents!
referències
- Col·lecció de ganivets de Backstabber: una revisió dels atacs a la cadena de subministrament de programari de codi obertM. Ohm et al., maig de 2020.
- Protecció contra programari maliciós de codi obertLlibre blanc de Xygeni.
- Software Supply Chain Security Retrospectiva: Donant forma a un 2024 més segurInforme de Xygeni.
