No episodio anterior, Paquetes maliciosos de código aberto: o problema, discutimos por que os actores de ameazas eran tan entusiastas por publicar novos compoñentes maliciosos ou inxectar software malicioso nas últimas versións de compoñentes existentes: a infraestrutura de código aberto permite que calquera persoa, en calquera lugar, cree unha conta efémera nun rexistro de compoñentes (como NPM, PyPI, Docker Hub ou Visual Studio Marketplace) ou nunha plataforma de desenvolvemento colaborativo (como GitHub). Custo cero e moitas oportunidades para aproveitar o exceso de confianza que os equipos de software tradicionalmente teñen nos compoñentes de terceiros.
A asimetría entre a facilidade para os atacantes distribuír software malicioso empregando a infraestrutura dispoñible para o código aberto e a dificultade para as organizacións que desenvolven software (¿todo o mundo?) evitar infectarse con software malicioso (e distribuír software malicioso no software que distribúen para outros) levou a case alcanzar a marca do cuarto de millón de paquetes maliciosos o ano pasado.
Este é un problema de tal magnitude que ningunha organización por si soa pode resolvelo, e a comunidade está no proceso de reformular o proceso de código aberto en canto á confianza, os principios de seguridade por defecto e seguridade por deseño, e o ciclo de vida dos compoñentes. Analizaremos estas ideas no seguinte episodio. Protección contra paquetes maliciosos de código aberto: o que (non) funciona.
Lembra que estamos a falar de compoñentes de software que a maioría das veces corresponden a paquetes de software: compoñentes reutilizables empaquetados para que se poidan referenciar como unha dependencia nun manifesto de software e instalados cun xestor de paquetes ou unha ferramenta de compilación. Teña en conta que este caso podería ampliarse para incluír contidos públicos imaxes de contedores (usado por tempos de execución de contedores e plataformas de orquestración como Kubernetes) e extensións para ferramentas de software (para a creación, automatización e despregamento).
Aquí analizamos como isto táctica de ataque baseada en compoñentes maliciosos funciona, segundo exemplos pasados e o que vimos na nosa plataforma de alerta temperá de malware (MEW). Analizaremos os compoñentes maliciosos en diferentes dimensións:
(1) o xeito escollido para a distribución (rexistro empregado, nun compoñente novo ou existente, e a técnica empregada para infectar a versión publicada do compoñente), (2) como se activa ou desencadea o malware, (3) o comportamento malicioso, é dicir, que accións prexudiciais se observan e cal é a motivación do atacante, (4) que técnicas son comúns para a ofuscación, a ocultación para pasar desapercibido, o movemento lateral, a comunicación cos hosts de comando e control (C2), etc.; e (5) as técnicas para gañar suficiente popularidade e confianza para que as vítimas acaben instalando o compoñente.
O mecanismo de distribución escollido
Observamos unha “ruído de fondo"de paquetes maliciosos pouco sofisticados que empregan typosquatting para enganar desenvolvedores incautos cun erro tipográfico no nome do paquete para a súa dependencia. Moitos paquetes populares reciben unha enxurrada de paquetes con nomes similares e erros tipográficos, coa expectativa de que enganen a algúns desenvolvedores incautos.
Usan unha conta efémera, publican un grupo de paquetes typosquat, crean outro e publican outro grupo... Usando algo de automatización e enxeño poden conseguir certa sofisticación, pero normalmente son bastante triviais. Internamente chamámoslles "anchoasO obxectivo principal é o roubo de credenciais, pero ocasionalmente atopamos spyware que extrae código fonte ou datos confidenciais como información persoal identificable (PII), captura de portapapeis e outras dúbidas.
De súpeto, vemos compoñentes maliciosos máis sofisticados, os "tiburóns". Unha minoría está dirixida a grupos ou organizacións específicas, normalmente con drenadores de criptomoedas ou skimmers web que se activan condicionalmente, quizais seguindo o enfoque visto no incidente de fluxo de eventos de descifrar a carga útil do ataque só cando se fai referencia ao paquete desde un paquete de destino.
O mecanismo de distribución foi analizado no excelente e agora clásico artigo “Colección de coitelos de Backstabber: unha revisión dos ataques á cadea de subministración de software de código aberto", que é de lectura obrigatoria. Seguro que xa viches este fermoso gráfico antes:
Exploráronse todas as vías, incluíndo paquetes novos e existentes; afectar o código fonte, o sistema de compilación ou o propio compoñente empaquetado; usar credenciais roubadas ou enxeñaría social; secuestrar contas e repositorios abandonados ou envelenar os mantidos. Algúns ataques recibiron nomes (Typosquatting, Confusión de dependencia, Confusión manifesta, Repo-jacking. etc.) e xa foron discutidas noutro lugar.
E que pasa cos rexistros escollidos?
NPM segue a liderar o número total de paquetes maliciosos, pero observamos un pico a partir deste ano en PyPI. Python é un ecosistema popular para a ciencia de datos e a aprendizaxe automática. De feito, a densidade de software malicioso agora é maior en PyPI que en NPM.
Como se activa o malware
Os paquetes maliciosos actívanse durante a instalación en só 4 de cada 10 casos (nos últimos anos foi preto de 6 de cada 10). O resto executa comportamentos maliciosos en tempo de execución, con 1 de cada 100 activados durante a execución de probas. Os adversarios parecen saber que a execución incontrolada de scripts de instalación estaba desactivada en moitos lugares.
Que están a conseguir os malos?
Enumeraremos as categorías de comportamento malicioso, coas máis populares primeiro. Teña en conta que o impacto podería ser bastante diferente: a limpador é teimosamente destrutivo, pero non é común e só se observou nalgunhas ocasións, relacionadas con campañas de ciberguerra dirixidas ou hacktivismo brutal. As seguintes categorías son bastante comúns:
- InfoStealer / Escurridor de credenciaisDe lonxe, o máis frecuente, máis do 90 % dos ataques pouco sofisticados son simples ladróns que buscan principalmente credenciais como contrasinais, tokens de acceso, claves API e claves privadas (para SSH e similares). Probablemente sexa o máis sinxelo de escribir (xunto cos wipers?). Enumeran ficheiros/directorios coñecidos e outras fontes (por exemplo, claves de rexistro), empaquetan o contido e envían eses datos a un servidor C2. A idea é sinxela: «Publico un ladrón de credenciais de phishing para poder usalas máis tarde para lanzar un ataque dirixido».
A rede C2 observada adoita ser barata e sucia, como as canles de Telegram ou ferramentas de tunelización tipo ngrok (a miúdo en forma de proxies inversos expostos a través de IPs de saída de VPN). Hai centos (!) de posibilidades, con moitos proxectos de GitHub baixo o tema do roubo de contrasinaisAs especializacións como os rexistradores de teclas son pouco frecuentes para paquetes maliciosos e imaxes de contedores, pero son máis frecuentes en extensións de ferramentas, onde se espera a interacción do usuario.
- Contagotas / Descargador. O segundo en popularidade, normalmente o primeiro en ataques de varias etapas. Máis dun de cada tres compoñentes maliciosos teñen droppers (se a carga útil maliciosa vén incluída no paquete) ou downloaders (a carga útil descárgase desde un endpoint baixo o control do atacante). A carga útil adoita ser unha variante binaria de malware coñecida e execútase e ás veces persiste para instalar portas traseiras, spyware, criptodrainers e outros casos de uso. A carga útil descargada ou despregada inicia un ataque de segunda fase con toda a potencia proporcionada polos binarios de malware existentes. Os binarios poden distribuírse dentro do paquete, a miúdo disfrazados de imaxes ou tipos de ficheiro supostamente inocuos, para evitar a detección ao conectarse a sitios inesperados.
- Ladróns/Mineiros de criptomoedasOs adversarios con motivacións financeiras están dispostos a usar os teus activos na nube para executar criptomineros (ata detectan se se están a executar nunha máquina virtual na nube). Non lles importa o baixa taxa de beneficios de 1 dólar por cada 53 dólares que se lle cobren á vítima polo roubo da infraestrutura na nube. É posible que as vítimas non se decaten disto ata que reciben unha factura inesperada. Afortunadamente, isto vai e vén. Criptojacking ás veces aparecen campañas en paquetes maliciosos que logo desaparecen, facendo phishing para os usuarios da carteira ou finalmente dirixíndose ao provedor da carteira, como no caso de Ataque de Ledger.
Outros comportamentos, como despregar un porta para a execución remota de código abrindo unha shell inversa é menos frecuente agora que no pasado. Por exemplo, o 123rf_contributor_web o paquete (agora eliminado do rexistro) ábrese sen ningunha ofuscación, unha shell inversa copiada e pegada desde o Folla de referencia para a shell inversa:
Ademais de compoñentes lexítimos e maliciosos, observamos varios abusos, entre eles:
Paquetes de spam
Hai miles de paquetes pequenos, a maioría en NPM, sen software malicioso pero que prometen ganancias fáciles, enganos, ligazóns a ofertas de Viagra e todo iso. Uns poucos usuarios publican ese correo lixo e quitan moito ancho de banda do rexistro. Outro(s) actor(es) posiblemente de Indonesia intentou(n) sacar proveito... abusando do rango de té destinado a compensar os desenvolvedores de código aberto, mediante a creación de decenas de miles de paquetes NPM interrelacionados con repositorios ficticios de GitHub relacionados. Isto supón unha clara violación das condicións de uso.
Recompensas por erros e enganos na investigación de seguridade
Cando un paquete se describe a si mesmo como exfiltrador de datos para bos fins, como detectar fallos de seguridade para programas de recompensas por erros ou investigar certos aspectos do ecosistema. Vimos miles de paquetes nesta categoría, que obteñen identificación pero non datos demasiado sensibles a un enderezo Burp Collaborator desde PortSwigger (por exemplo, host no dominio oastify.com). Observamos a miúdo imitacións do Confusión de dependencia proba de concepto por Alex Birsan, como o aurora-webmail-pro paquete (eliminado do rexistro), que simplemente executa este código desagradable no script de preinstalación:
E tamén incluíu un “Esta é unha proba de concepto de ataque de confusión de dependencia simple"descrición da exención de responsabilidade na paquete.jsonIsto supón unha clara violación das condicións do servizo, mesmo sen intención maliciosa.
Boas novas? Aínda non vimos ataques de ransomware realizados a través de compoñentes maliciosos. Por razóns descoñecidas, os ciberdelincuentes parecen preferir mecanismos de entrega de descargas automáticas máis tradicionais, como o phishing por correo electrónico, baseados en RDP e os mecanismos de entrega de descargas automáticas.
Técnicas adicionais observadas
Empregáronse moitas técnicas para a persistencia, a evasión defensiva, a recollida de información, a comunicación cos anfitrións de comando e control e a exfiltración.
Persistencia nos compoñentes maliciosos obtense usando as características de persistencia nun malware binario de segunda etapa, pero ás veces o comportamento localízase no código do paquete, sendo as tarefas programadas e os cambios no rexistro de Windows o máis común.
Ofuscación é común, pero pouco sofisticado. A maioría dos paquetes de typosquatting (lembra o "anchoas"?) non empregan ofuscación en absoluto; moitos empregan cifrados triviais (codificación base64/hex ou cifrados de substitución como rot13) ou empregan ofuscadores de código dispoñibles e minificación, o que se reverte facilmente coas ferramentas axeitadas. Só os "tiburóns" fan ofuscación real e férrea, difícil de aplicar enxeñaría inversa.
A ofuscación pode ocultar o ataque, pero por que tería que ofuscarse o código dun compoñente de código aberto? Hai probas de que algo deba ocultarse á vista de todos? Atopamos moitos casos de paquetes non maliciosos que usan a ofuscación para protexer a propiedade intelectual, o que é contraditorio co "código aberto". A ofuscación pódese usar como proba de software malicioso, pero non é concluínte. Tamén é difícil de desofuscar.
Evasión dos controis de defensa adopta técnicas sinxelas. O código malicioso adoita estar protexido en intentar … coller bloques que ignoran calquera excepción, polo que a actividade anormal non se mostra nos rexistros. A verificación do ambiente (executándose nunha máquina virtual ou contedor) é rara, agás para software malicioso dirixido a unha organización ou ambiente en particular.
Enmascarar binarios en imaxes e ficheiros PDF (unha especie de esteganografía) foi outra técnica observada para evadir a detección.
Dado que os compoñentes maliciosos máis comúns son os ladróns de información, recollida de datos é esencial. Os segredos (contrasinais, tokens de acceso, claves API, claves criptográficas) escanéanse de forma rutineira en ficheiros de rexistro, variables de ambiente e mesmo no portapapeis (algo que se observa con troianos bancarios e ladróns de criptografía). A exfiltración de código fonte tamén é común, xa que a instalación do paquete adoita facerse nun nodo de desenvolvemento onde se poden clonar os repositorios git internos. Vimos paquetes enumerando directorios na procura de repositorios git. Buscar localizacións como .env, private.pem, settings.py, app.js ou application.properties é bastante común.
A exfiltración é outra acción amplamente empregada. Só unha minoría de paquetes maliciosos intentan ocultar o destino dos datos extraídos. As canles de Telegram e túneles semellantes aos ngrok úsanse a miúdo. E hai moitos dominios normalmente incluídos na lista branca que se usan para a exfiltración.
Outras técnicas, como a escalada de privilexios ou o movemento lateral, eran menos comúns.
Gañando popularidade e confianza
Imaxina un estafador tecnolóxico cun truco malicioso e asasino xa feito preguntándose: "Como fago para que esta merda sexa de confianza para eses idiotas desprevenidos?".
Iso tradúcese en como facer que a entrada para o compoñente malicioso mostre moitas estrelas/bifurcacións (por popularidade), ademais de versións/problemas e pull requests (para a actividade). A idea é gañar popularidade ficticia (estrelas) e dependentes, e unha aparencia convincente en canto á relevancia e o mantemento.
O rexistro non comproba se o contido dun proxecto de GitHub e o contido do paquete coinciden.Este é un problema ben coñecido na cadea de subministración de software. Os rexistros públicos son sumidoiros xigantes que tragan todo o que lles botan enriba. Podes vincular calquera repositorio.
Se o paquete malicioso abusa dun erro tipográfico popular, é doado: só tes que facer referencia ao repositorio de GitHub existente no manifesto de dependencias usado para crear o paquete e publicalo no rexistro. Para paquetes novos nun repositorio falso de GitHub, pode que necesites máis enxeño, quizais creando paquetes falsos. observación das estrelas/bifurcación Contas de GitHub mediante scripts.
E se o contido do teu paquete é razoablemente similar ao do repositorio, engade un par de cambios ben deseñados aquí e alá... Podes inxectar o teu malware nun paquete novo que se pareza a un popular que faga referencia ao repositorio existente e esperar a que haxa erros tipográficos. Se alguén se atreve a comparar o contido do arquivo tar do paquete co contido do repositorio de GitHub, as diferenzas nos puntos de inxección de malware poderían pasarse por alto facilmente. Xa vimos esta estratexia moitas veces antes.
Sería benvido un mecanismo para que un compoñente fixese unha declaración a proba de manipulacións sobre a procedencia, como se fabricou o paquete, de que fontes e por quen. Pero esa é outra historia.
O compoñente X é malware?
Existe unha base de datos (exhaustiva) de paquetes maliciosos? Non. As vulnerabilidades de código aberto teñen asignado un ID CVE, pero só uns poucos paquetes maliciosos (especialmente os que saen aos titulares) reciben un. O CWE para paquetes maliciosos é CWE-506 (código malicioso incrustado).
As ferramentas habituais de software malicioso (VirusTotal, MalwareBazaar, SOREL-20M…) non teñen disposicións específicas para os compoñentes maliciosos. Iso sería benvido!
Hai bases de datos de mostras de investigación e conxuntos de datos para análise (nós usamos algúns deles), pero as entradas só se actualizan cando se coñece o paquete malicioso, o que adoita ser demasiado tarde. Se estás interesado, o OpenSSF Paquetes maliciosos é un bo comezo.
Na seguinte publicación, falaremos de como saber se un paquete determinado é malicioso. Spoiler: si, hai xeitos de comprobar se hai compoñentes maliciosos ao comezo da xanela de exposición, antes de que o rexistro elimine un compoñente malicioso coñecido.
Outras lecturas
No seguinte episodio “Protección contra paquetes maliciosos de código aberto: o que (non) funciona" Falaremos do que se debe e do que non se debe facer para a seguridade de código aberto. A maioría dos profesionais conscientes da seguridade teñen intuicións sobre como xestionar esta ameaza, pero abundan os conceptos erróneos.
Revisaremos por que estas ideas son erróneas e como estes conceptos erróneos contribúen á popularidade deste mecanismo de ataque e ao risco abrumador que están a experimentar as organizacións. Despois, procederemos co que funciona e cal é o esforzo e os recursos implicados.
Ademais, imos publicar sobre a evolución dos paquetes maliciosos en termos da súa intención, mecanismo de inxección e técnicas de ataque.
Sexa atento!
