En l'episodi anterior, Paquets maliciosos de codi obert: el problema, vam discutir per què els actors d'amenaces eren tan entusiastes per publicar nous components maliciosos o injectar programari maliciós a les darreres versions dels components existents: la infraestructura de codi obert permet a qualsevol persona de qualsevol lloc crear un compte efímer en un registre de components (com ara NPM, PyPI, Docker Hub o Visual Studio Marketplace) o una plataforma de desenvolupament col·laboratiu (com ara GitHub). Cost zero i moltes oportunitats per aprofitar l'excés de confiança que els equips de programari tradicionalment tenen en components de tercers.
L'asimetria entre la facilitat amb què els atacants distribueixen programari maliciós utilitzant la infraestructura disponible per a codi obert i la dificultat amb què les organitzacions que desenvolupen programari (tothom?) eviten infectar-se amb programari maliciós (i introduir programari maliciós en el programari que distribueixen per a altres), va portar a gairebé assolir la xifra d'un quart de milió de paquets maliciosos l'any passat.
Aquest és un problema de tal magnitud que cap organització per si sola no el pot resoldre, i la comunitat està en procés de reformular el procés de codi obert pel que fa a la confiança, els principis de seguretat per defecte i seguretat per disseny, i el cicle de vida dels components. Analitzarem aquestes idees en el proper episodi. Protecció contra paquets maliciosos de codi obert: què funciona (o no funciona).
Recordeu que estem parlant de components de programari que la majoria de les vegades corresponen a paquets de programari: components reutilitzables empaquetats perquè es puguin referenciar com a dependència en un manifest de programari i instal·lats amb un gestor de paquets o una eina de compilació. Tingueu en compte que aquest cas es podria ampliar per incloure el públic imatges de contenidors (utilitzat per temps d'execució de contenidors i plataformes d'orquestració com Kubernetes), i extensions a eines de programari (per a la construcció, automatització i desplegament).
Aquí analitzem com això tàctica d'atac basada en components maliciosos funciona, segons exemples anteriors i el que hem vist a la nostra plataforma d'alerta precoç de programari maliciós (MEW). Analitzarem components maliciosos en diferents dimensions:
(1) la manera escollida per a la distribució (registre utilitzat, en un component nou o existent, i la tècnica utilitzada per infectar la versió del component publicada), (2) com s'activa o desencadena el programari maliciós, (3) el comportament maliciós, és a dir, quines accions nocives s'observen i quina és la motivació de l'atacant, (4) quines tècniques són comunes per a l'ofuscació, l'amagatall per passar desapercebut, el moviment lateral, la comunicació amb els hosts de comandament i control (C2), etc.; i (5) les tècniques per guanyar prou popularitat i confiança perquè les víctimes acabin instal·lant el component.
El mecanisme de distribució escollit
Observem un “soroll de fons"de paquets maliciosos poc sofisticats que utilitzen typosquatting per fer phishing a desenvolupadors desprevinguts amb una errada tipogràfica al nom del paquet per a la seva dependència. Molts paquets populars reben una allau de paquets amb noms similars i errades tipogràfiques, amb l'expectativa que faran phishing a alguns desenvolupadors desprevinguts.
Utilitzen un compte efímer, publiquen un grup de paquets typosquat, en creen un altre i en publiquen un altre... Amb una mica d'automatització i enginy poden aconseguir una certa sofisticació, però normalment són força trivials. Internament els anomenem "anxoves". El robatori de credencials és l'objectiu principal, però ocasionalment trobem programari espia que exfiltra codi font o dades sensibles com ara informació d'identificació personal (PII), captura de porta-retalls i altres dubtes.
De sobte veiem components maliciosos més sofisticats, els "taurons". Una minoria es dirigeix a grups o organitzacions específiques, normalment amb drenadors de criptomonedes o skimmers web que s'activen condicionalment, potser seguint l'enfocament vist a incident de flux d'esdeveniments de desxifrar la càrrega útil de l'atac només quan es fa referència al paquet des d'un paquet objectiu.
El mecanisme de distribució va ser analitzat en l'excel·lent i ara clàssic article, “Col·lecció de ganivets de Backstabber: una revisió dels atacs a la cadena de subministrament de programari de codi obert", que és de lectura obligada. Segur que ja heu vist aquest bonic gràfic abans:
Es van explorar totes les vies, incloent-hi paquets nous i existents; afectar el codi font, el sistema de compilació o el component empaquetat en si; utilitzar credencials robades o enginyeria social; segrestar comptes i repositoris abandonats o enverinar els mantinguts. Alguns atacs van rebre noms (typosquatting, Confusió de dependència, Confusió manifesta, Repo-jacking. etc.) i ja s'han comentat en altres llocs.
I què passa amb els registres escollits?
NPM continua liderant el nombre total de paquets maliciosos, però hem vist un pic a partir d'aquest any a PyPI. Python és un ecosistema popular per a la ciència de dades i l'aprenentatge automàtic. De fet, la densitat de programari maliciós ara és més alta a PyPI que a NPM.
Com s'activa el programari maliciós
Els paquets maliciosos només s'activen durant la instal·lació en 4 de cada 10 casos (en els darrers anys era a prop de 6 de cada 10). La resta executa un comportament maliciós en temps d'execució, amb 1 de cada 100 activat durant l'execució de proves. Els adversaris semblen saber que l'execució incontrolada de scripts d'instal·lació estava desactivada en molts llocs.
Què s'emporten els dolents?
Enumerarem les categories de comportament maliciós, amb les més populars primer. Tingueu en compte que l'impacte podria ser força diferent: a eixugaparabrises és tossudament destructiu, però no és comú i només s'ha vist en uns pocs casos, relacionats amb campanyes de ciberguerra dirigides o hacktivisme brutal. Les categories següents són força comunes:
- InfoStealer / Escurçador de credencialsAmb diferència, el més freqüent, més del 90% dels atacs no sofisticats són simples lladres que busquen principalment credencials com ara contrasenyes, tokens d'accés, claus API i claus privades (per a SSH i similars). Probablement és el més senzill d'escriure (juntament amb els wipers?). Enumeren fitxers/directoris coneguts i altres fonts (per exemple, claus de registre), empaqueten el contingut i envien aquestes dades a un servidor C2. La idea és senzilla: "Publico un lladre de credencials de phishing, per poder utilitzar les credencials més tard per llançar un atac dirigit".
Les xarxes C2 observades solen ser barates i brutes, com els canals de Telegram o eines de tunelització tipus Ngrok (sovint en forma de proxies inversos exposats a través d'IPs de sortida de VPN). Hi ha centenars (!) de possibilitats, amb molts projectes de GitHub sota el tema de robatori de contrasenyesLes especialitzacions com els keyloggers són rares per a paquets maliciosos i imatges de contenidors, però més freqüents en extensions d'eines, on s'espera la interacció de l'usuari.
- Descarregador / Descarregador. El segon en popularitat, normalment el primer en atacs de diverses etapes. Més d'un de cada tres components maliciosos tenen droppers (si la càrrega útil maliciosa s'inclou dins del paquet) o downloaders (la càrrega útil es descarrega des d'un endpoint sota el control de l'atacant). La càrrega útil sovint és una variant binària de programari maliciós coneguda, i s'executa i de vegades persisteix, per instal·lar backdoors, spyware, criptodrainers i altres casos d'ús. La càrrega útil descarregada o desplegada inicia un atac de segona fase amb tota la potència proporcionada pels binaris de programari maliciós existents. Els binaris es poden distribuir dins del paquet, sovint disfressats d'imatges o tipus de fitxer suposadament innocus, per evitar la detecció en connectar-se a llocs inesperats.
- Lladres / miners de criptomonedesEls adversaris amb motivacions financeres estan disposats a utilitzar els vostres actius al núvol per executar criptominers (fins i tot detecten si s'estan executant en una màquina virtual al núvol). No els importa el baixa ràtio de beneficis d'1 dòlar per cada 53 dòlars que es cobren a la víctima per la infraestructura de núvol robada. És possible que les víctimes no se n'adonin fins que rebin una factura inesperada. Afortunadament, això va i ve. Cryptojacking De vegades apareixen campanyes en paquets maliciosos que després desapareixen, fent phishing per als usuaris de la cartera o finalment dirigint-se al proveïdor de la cartera, com en el cas de Atac de Ledger.
Altres comportaments, com ara desplegar un porta del darrere per a l'execució remota de codi obrint una shell inversa és menys freqüent ara que en el passat. Per exemple, el 123rf_contributor_web el paquet (ara eliminat del registre) s'obre sense cap ofuscació, una shell inversa copiada i enganxada des del Full de trucs de la closca inversa:
A més de components legítims i maliciosos, hem observat diversos abusos, com ara:
Paquets de correu brossa
Hi ha milers de paquets petits, principalment a NPM, sense programari maliciós però que prometen guanys fàcils, subhastes, enllaços a ofertes de Viagra i tot això. Uns quants usuaris publiquen aquest correu brossa i prenen molt ample de banda del registre. Un altre actor o actors possiblement d'Indonèsia van intentar obtenir-ne beneficis... abusant del teRank destinat a compensar els desenvolupadors de codi obert, creant desenes de milers de paquets NPM interrelacionats amb repositoris de GitHub relacionats. Això és una clara violació de les condicions d'ús.
Recompenses per errors i enganys en la recerca de seguretat
Quan un paquet es descriu a si mateix com a exfiltrant dades per a bons propòsits, com ara detectar fallades de seguretat per a programes de recompenses d'errors o investigar certs aspectes de l'ecosistema. Hem vist milers de paquets en aquesta categoria, que obtenen identificació però no dades massa sensibles a una adreça de Burp Collaborator des de PortSwigger (per exemple, host al domini oastify.com). Sovint hem observat imitacions del Confusió de dependència prova de concepte per part d'Alex Birsan, com el aurora-webmail-pro paquet (eliminat del registre), que simplement executa aquest codi desagradable a l'script de preinstal·lació:
I també incloïa un “Aquesta és una prova de concepte d'atac de confusió de dependències simple."descripció de l'avís legal a la paquet.jsonAixò és una clara violació de les condicions del servei, fins i tot sense intenció maliciosa.
Bones notícies? No hem vist (encara) atacs de ransomware a través de components maliciosos. Per raons desconegudes, els ciberdelinqüents semblen preferir mecanismes de lliurament de descàrregues drive-by i phishing per correu electrònic més tradicionals, basats en RDP.
Tècniques addicionals observades
Es van utilitzar moltes tècniques per a la persistència, l'evasió defensiva, la recopilació d'informació, la comunicació amb els hosts de comandament i control i l'exfiltració.
Persistència en components maliciosos s'obté mitjançant les funcions de persistència d'un programari maliciós binari de segona fase, però de vegades el comportament es localitza al codi del paquet, i les tasques programades i els canvis al registre de Windows són els més comuns.
Ofuscació és comú, però poc sofisticat. La majoria de paquets de typosquatting (recordeu el "anxoves"?) no utilitzen gens d'ofuscació; molts utilitzen xifrats trivials (codificació base64/hex o xifrats de substitució com rot13) o utilitzen ofuscadors de codi disponibles i minificació, cosa que es pot revertir fàcilment amb les eines adequades. Només els "taurons" fan una ofuscació real i dura, difícil d'enginyar inversament.
L'ofuscació pot amagar l'atac, però per què caldria ofuscar el codi d'un component de codi obert? Hi ha proves que alguna cosa s'hagi d'amagar de la vista de tothom? Hem trobat molts casos de paquets no maliciosos que utilitzen l'ofuscació per protegir la propietat intel·lectual, cosa que és contradictòria amb el "codi obert". L'ofuscació es pot utilitzar com a prova de programari maliciós, però no és concloent. També és difícil de desofuscar.
evasió dels controls de defensa adopta tècniques senzilles. El codi maliciós sovint es protegeix en intentar … atrapar blocs que ignoren qualsevol excepció, de manera que l'activitat anormal no es mostra als registres. La verificació de l'entorn (que s'executa en una màquina virtual o contenidor) és rara, tret que es tracti de programari maliciós dirigit a una organització o entorn en particular.
Emmascarar binaris en imatges i fitxers PDF (una mena d'esteganografia) va ser una altra tècnica vista per evadir la detecció.
Com que els components maliciosos més comuns són els lladres d'informació, recopilació de dades és essencial. Els secrets (contrasenyes, tokens d'accés, claus API, claus criptogràfiques) s'escanegen rutinàriament als fitxers de registre, variables d'entorn i fins i tot al porta-retalls (com es veu amb troians bancaris i lladres de criptografia). L'exfiltració de codi font també és habitual, ja que la instal·lació del paquet sovint es fa en un node de desenvolupament on es poden clonar els repositoris git interns. Hem vist paquets que enumeren directoris a la recerca de repositoris git. Buscar ubicacions com .env, private.pem, settings.py, app.js o application.properties és força comú.
L'exfiltració és una altra acció molt utilitzada. Només una minoria de paquets maliciosos intenten ocultar la destinació de les dades extretes. Canals de Telegram i túnels semblants als ngroks s'utilitzen sovint. I n'hi ha molts dominis normalment a la llista blanca utilitzats per a l'exfiltració.
Altres tècniques, com l'escalada de privilegis o el moviment lateral, eren menys comunes.
Guanyant popularitat i confiança
Imagineu-vos un delinqüent tecnològic amb una cosa maliciosa i assassina ja feta preguntant-se: "Com puc fer que aquesta merda sigui fiable per a aquests imbècils desprevinguts?".
Això es tradueix en com fer que l'entrada per al component maliciós mostri moltes estrelles / forques (per popularitat), a més de versions / problemes i pull requests (per a l'activitat). La idea és obtenir una popularitat fictícia (estrelles) i dependents, i un aspecte convincent pel que fa a la rellevància i el manteniment.
El registre no comprova si el contingut d'un projecte de GitHub i el contingut del paquet coincideixen.Aquest és un problema ben conegut a la cadena de subministrament de programari. Els registres públics són clots gegants que s'empassen tot el que els hi llancen. Podeu enllaçar qualsevol repositori.
Si el paquet maliciós ocupa un error tipogràfic popular, és fàcil: només cal que feu referència al repositori de GitHub existent al manifest de dependències utilitzat per crear el paquet i publicar-lo al registre. Per a paquets nous en un repositori de GitHub fals, potser necessitareu més enginy, potser creant paquets falsos. observació d'estrelles/bifurcació Comptes de GitHub mitjançant scripts.
I si el contingut del vostre paquet és raonablement similar al del repositori, afegiu-hi un parell de canvis ben dissenyats aquí i allà... Podeu injectar el vostre programari maliciós en un paquet nou que s'assembli a un de popular que faci referència al repositori existent i esperar que hi hagi errors tipogràfics. Si algú s'atreveix a comparar el contingut del fitxer tar del paquet amb el contingut del repositori de GitHub, les diferències en els punts d'injecció de programari maliciós es podrien passar fàcilment per alt. Hem vist aquest enfocament moltes vegades abans.
Un mecanisme perquè un component fes una declaració a prova de manipulacions sobre la procedència, com es va construir el paquet, de quines fonts i per qui, seria benvingut. Però això és una altra història.
El component X és programari maliciós?
Hi ha una base de dades (completa) de paquets maliciosos? No. Les vulnerabilitats de codi obert tenen un ID CVE assignat, però només uns quants paquets maliciosos (especialment els que fan titulars) en tenen un. El CWE per a paquets maliciosos és CWE-506 (codi maliciós incrustat).
Les eines de programari maliciós habituals (VirusTotal, MalwareBazaar, SOREL-20M…) no tenen disposicions específiques per als components maliciosos. Això seria benvingut!
Hi ha bases de dades de mostres de recerca i conjunts de dades per a l'anàlisi (nosaltres en fem servir alguns), però les entrades només s'actualitzen quan es coneix el paquet maliciós, cosa que sovint és massa tard. Si us interessa, el OpenSSF Paquets maliciosos és un bon començament.
A la propera publicació, parlarem de com saber si un paquet determinat és maliciós. Spoiler: sí, hi ha maneres de comprovar si hi ha components maliciosos al principi de la finestra d'exposició, abans que el registre elimini un component maliciós conegut.
Altres lectures
En el següent episodi “Protecció contra paquets maliciosos de codi obert: què funciona (o no funciona)" Parlarem del que cal fer i del que no cal fer per a la seguretat de codi obert. La majoria de professionals conscients de la seguretat tenen intuïcions sobre com gestionar aquesta amenaça, però abunden les idees errònies.
Revisarem per què aquestes idees són errònies i com aquests conceptes erronis contribueixen a la popularitat d'aquest mecanisme d'atac i al risc aclaparador que experimenten les organitzacions. A continuació, procedirem amb què funciona i quin és l'esforç i els recursos implicats.
A més, publicarem sobre l'evolució dels paquets maliciosos pel que fa a la seva intenció, mecanisme d'injecció i tècniques d'atac.
Estiguin atents!
