Los paquetes npm de AsyncAPI comprometidos generan malware de botnet de múltiples etapas – CYBERDEFENSA.MX
Se han observado cuatro paquetes npm comprometidos en el espacio de nombres @asyncapi distribuyendo un cargador de botnet de varias etapas, según los hallazgos de Seguridad buey, SafeDep, Enchufey PasoSeguridad.
Los paquetes afectados se enumeran a continuación:
- @asyncapi/generator-helpers@1.1.1
- @asyncapi/generator-components@0.7.1
- @asyncapi/generador@3.3.1
- @asyncapi/specs(v6.11.2, v6.11.2-alpha.1)
«Los paquetes comprometidos implementan una carga útil ofuscada de primera etapa que descarga una carga útil cifrada de segunda etapa, identificada como Miasma, desde IPFS», dijo Socket.
Los paquetes envenenados incluyen un implante de JavaScript oculto, y cada uno de ellos contiene un archivo fuente inyectado que se decodifica en el mismo descargador de segunda etapa. A diferencia de iteraciones anteriores que aprovechaban los ganchos de instalación para activar la ejecución de una carga útil de JavaScript, en este caso el código malicioso se ejecuta cuando Node.js carga el módulo infectado, después de lo cual lanza un nodo en segundo plano independiente que descarga y ejecuta el malware desde IPFS.
La carga útil de la siguiente etapa es un cargador de JavaScript cifrado llamado «sync.js», que se escribe en rutas específicas del sistema operativo y se ejecuta. La URL de descarga es «ipfs[.]io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.» El cargador contiene dos componentes:
- La carga útil final de JavaScript cifrada, que se decodifica en el marco de tareas de Miasma.
- Un gran blob cifrado utilizado por el marco de la cadena de generación del tiempo de ejecución.
El marco incluye 744 módulos y está construido como un marco de comando que admite seis canales de comunicación de comando y control (C2) independientes usando HTTP, Nostr Relay, IPFS, BitTorrent DHT, libp2p GossipSub P2P mesh y un contrato inteligente Ethereum.
Además de facilitar el robo de credenciales, el envenenamiento de herramientas de inteligencia artificial, el movimiento lateral de la LAN y la propagación similar a un gusano en los registros npm, PyPI y Cargo, Miasma presenta un mecanismo de persistencia propio, configurando claves de inicio automático systemd, crontab, macOS launchd y Windows Registro.
«Aunque el malware tiene algunas similitudes con las campañas Shai-Hulud y Miasma, y contiene la cadena Miasma varias veces dentro de su código, este malware no es el mismo, ni se atribuye a las campañas Miasma/Shai-Hulud/TeamPCP que hemos visto en el pasado», dijo Moshe Siman Tov Bustan de OX Security.
Además, incorpora un interruptor de hombre muerto que monitorea un token robado y activa un borrado de directorio si el token es revocado, evitando sistemas identificados como sandboxes o entornos virtuales, así como aquellos que tienen su idioma actual configurado en ruso o tienen instaladas herramientas de seguridad de CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium y Qualys.
«Su camino operativo más claro es C2 basado en REST: el implante apunta a un punto final HTTP, acepta tareas cifradas y publica los resultados de los comandos en la misma infraestructura. Alrededor de ese núcleo, la carga útil también brinda soporte para transporte de carga, cifrado de comandos, firma de nodos, actualizaciones de carga útil, administración de archivos, ejecución de shell y escritura de persistencia».
Según StepSecurity, se dice que el atacante obtuvo acceso push a los repositorios y utilizó el canal de lanzamiento legítimo de GitHub Actions del proyecto para publicar paquetes con certificaciones de procedencia OIDC válidas. El ataque a la cadena de suministro no implicó el robo de un token npm.
«Ambos ataques son compromisos de canalización de CI/CD, no tokens npm robados ni mantenedores maliciosos», dijo el investigador de seguridad Rohan Prabhu. «El atacante impulsó las confirmaciones bajo una identidad git de marcador de posición y dejó que el flujo de trabajo de lanzamiento real de cada repositorio hiciera la publicación a través de la integración de editor confiable GitHub OIDC de npm».
«Los paquetes resultantes llevan certificaciones de procedencia SLSA legítimas, lo que demuestra únicamente que el flujo de trabajo autorizado del proyecto los produjo, no que las confirmaciones desencadenantes fueron legítimas. La procedencia no protege contra una credencial push comprometida».
Desde entonces, las cinco versiones maliciosas no se han publicado en el registro npm. Se recomienda tratar cualquier punto final que haya importado o ejecutado una de las versiones del paquete afectado como potencialmente comprometido. Sin embargo, cabe señalar que la exposición depende de si el módulo infectado se cargó como parte de una compilación o de un flujo de trabajo de desarrollador.
«No hay ningún script de preinstalación/postinstalación/instalación en ninguno de los tres archivos package.json», dijo StepSecurity. «Este cuentagotas se activa cuando se requiere el módulo envenenado () durante el uso normal del generador: en el momento en que un trabajo de compilación o CI realmente llama a la biblioteca, no en el momento de la instalación de npm».