Un posible desastre de la cadena de suministro de NPM se evitó en un tiempo récord después de que los atacantes se hicieron cargo de las credenciales de un desarrollador verificado. El 8 de septiembre, Josh Junon, un desarrollador con más de 1800 contribuciones de Github en el último año, confirmó en Bluesky su cuenta de NPM se vio comprometida. Junon había sido alertado por otros usuarios de que su cuenta había comenzado a publicar paquetes con puertas traseras en todos los paquetes populares en los que estaba involucrado el desarrollador. El desarrollador, comúnmente conocido como ‘Qix’, dijo que recibió un correo electrónico para restablecer su autenticación de dos factores (2FA) que parecía «muy legítima», pero que era maliciosa. Agregó que solo involucraba su cuenta de NPM y que estaba en contacto con NPM para resolver el problema. Paquetes de NPM comprometidos La cuenta de NPM ‘Qix’ comprometida publicó versiones maliciosas publicadas para docenas de paquetes Junon. Descargas) Error-EX (aproximadamente 47 millones de descargas semanales) Simple-swizzle aproximadamente 26 millones de descargas semanales) HA-ANSI (aproximadamente 12 millones de descargas semanales) La carga útil implantada en los paquetes maliciosos es una cortina criptográfica que roba fondos al intercambiar las direcciones de las billeteras en las solicitudes de redes de redes y directamente las transacciones cripto. La cadena de ataque de criptográfico explicó que este sofisticado malware se dirige a los usuarios de criptomonedas a través de dos vectores de ataque principales. Primero, verifica si hay una extensión de billetera (como Metamask) presente. Si no es así, lanza un ataque pasivo de intercambio de direcciones, interceptando todo el tráfico web secuestrando las funciones de Fetch y XMLHTTPREQUEST del navegador. El malware luego reemplaza las direcciones de criptografía legítimas con las controladas por los atacantes, utilizando el algoritmo de distancia de Levenshtein para elegir la dirección más visualmente similar, lo que hace que el intercambio sea casi indetectable a simple vista. Si se detecta una billetera, el malware aumenta al secuestro de transacciones activas. Intercepe las transacciones salientes (por ejemplo, ETH_SENDTRANSACTION) y modifica la dirección del destinatario en la memoria antes de que el usuario lo firme. La víctima ve una pantalla de confirmación de aspecto legítimo, pero si no verifican la dirección cuidadosamente, sus fondos se envían directamente al atacante. La cadena de ataque es sigilosa y automatizada, explotando tanto la percepción humana (a través de la falsificación de las direcciones) como las vulnerabilidades técnicas (a través de la manipulación de la API de la billetera). Al comprometer un paquete NPM confiable, el malware se propaga en silencio, infectando sitios web y robando fondos sin aumentar las sospechas inmediatas. Una de las direcciones de Ethereum primarias utilizadas en el ataque es 0xFC4A4858BAFEF54D1B1D7697BFB5C52F4C1666976. Las personas pueden ver su actividad en vivo en el sitio web de Ethereum-scanning Etherscan a Traxksome de los fondos robados. También se ha creado un listado de Github Gist. Todas las billeteras afectadas. Una crisis evitada que debería «celebrarse» cuatro horas después de que Junon confirmó el compromiso, compartió un mensaje de NPM diciendo que se habían eliminado todas las versiones de paquetes afectados. Si bien muchas personas comenzaron a llamar a este hack como el «mayor ataque de la cadena de suministro en la historia» en las redes sociales, muchas voces han desafiado esta narrativa. Josh Bressers, vicepresidente de Security At Anchore, dijo en LinkedIn: «Esto es lo que nadie parece estar hablando. Todo esto duró solo unas pocas horas. Es sorprendente cuán rápido puede responder el código abierto a cosas como esta. Todos trabajan juntos. La información se puede compartir. La cantidad de personas que ahora trabajan en esto no es solo más grande que su equipo de seguridad, es más grande que su compañía». Katie Paxton-Fear, una hacker ética que recientemente comenzó a trabajar como defensora de la seguridad del personal en Semgrep, publicó un video sobre LinkedIn enfatizando que se ha evitado una crisis importante. «Obviamente, cualquier violación de seguridad es mala, pero esta no es la principal violación de seguridad que las personas están haciendo que sea», dijo. Destacó que la pérdida total estimada solo ascendió a $ 20, gracias principalmente a la respuesta rápida de la comunidad de código abierto. «El malware se notó y la gente comenzó a hablar de ello en Github a solo los 15 minutos de los paquetes maliciosos en vivo. Algunos de los paquetes fueron retirados por los mantenedores solo una hora después del compromiso, y el resto de ellos por NPM en dos horas», explicó. Según Arda Büyükkaya, un analista senior de inteligencia de amenazas cibernéticas en ECLECTICIQ, la dirección de cripto de atacante muestra $ 66.52. Sin embargo, Paxton-Fear argumentó que este incidente es «una victoria que muestra que el modelo de código abierto funciona y que debería celebrarse». En otra publicación de LinkedIn, Melissa Biscoping, la directora de la investigación de seguridad de punto final en Tanium, fue más allá: «Si está en pánico sobre ese asunto de NPM, no lo hace. Existe una posibilidad prácticamente 0 de posibilidades de que se vea afectado por esto, y no debe quemar a sus equipos al elegir cada esquina de su infraestructura para la evidencia de estos paquetes comprometidos». Descargado y enviado a su software en esa ventana de tiempo son muy, muy pequeñas, casi 0. De todas las cosas que creo que deberías hacer que tu equipo se agote tarde, esta no es una de ellas «. Sin embargo, cómo mitigar esta amenaza, aquellos que aún piensan que pueden verse afectados pueden tomar medidas inmediatas para bloquear las dependencias vulnerables. Según Jan-David Stärk, ingeniero de software y líder del equipo en Hansalog, para versiones seguras a prueba de fuerza en un proyecto completo, los desarrolladores pueden usar anulaciones en su paquete.json, agregando lo siguiente a las versiones confiables de los paquetes comprometidos: {«nombre»: «su proyecto», «Versión»: «1.0.0», «anulada»:: «» CHALK «:» 5..3.0 «. «7.1.0», «Color-Convert»: «2.0.1», «Nombre de color»: «1.1.4», «IS-Core-Module»: «2.13.1», «Error-EX»: «1.3.2», «Has-Ansi»: «5.0.1»}} luego, los desarrolladores deberían limpiar su proyecto al deletear Node_Modules y Package-Lock.json, luego, Instal Archivo de bloqueo. Esto asegurará que no queden versiones maliciosas en su árbol de dependencia.