Un paquete npm que robó las claves privadas
Un paquete npm con unos 50.000 descargas semanales envió durante un breve periodo las claves privadas de sus usuarios. El SDK oficial de Injective contenía una función disfrazada de telemetría que capturaba las claves de la billetera y los mnemónicos. Lo descubrió el servicio de seguridad Socket. El caso muestra cómo una única dependencia manipulada puede envenenar todo un proceso de compilación.
Lo más importante en resumen
- Un paquete, muchos afectados. El comprometido @injectivelabs/sdk-ts capturó claves privadas y mnemónicos, distribuyéndose a través de 17 paquetes dependientes.
- Disfrazado como telemetría. La función maliciosa codificaba los datos en base64 y los enviaba silenciosamente a un punto final oculto.
- Mucho más allá de las criptomonedas. Cualquier compilación que obtenga dependencias sin verificar conlleva el mismo riesgo. El bloqueo de versiones, la verificación de firmas y la rotación rápida son la respuesta.
Relacionado: Un controlador firmado deja ciego a la protección del extremo · Cuando los atacantes son más rápidos que el parche
Qué escondía el SDK de Injective
¿Qué es un ataque a la cadena de suministro? Un ataque a la cadena de suministro no apunta directamente a una empresa, sino a un componente que utilizan muchas empresas. Si se manipula una dependencia pública, el código malicioso fluye hacia cualquiera que instale el paquete a través del método de instalación habitual.
En el caso actual, afectó a la biblioteca TypeScript @injectivelabs/sdk-ts, una herramienta para aplicaciones relacionadas con la blockchain de Injective. Una versión manipulada incluía una función que se hacía pasar por telemetría. En realidad, capturaba credenciales de acceso. La llamada para derivar una billetera a partir de un mnemónico registraba la frase completa, y la llamada desde una clave privada registraba su material.
Los datos capturados se codificaban en base64 y se enviaban silenciosamente mediante una solicitud de red a un punto final oculto. Para el desarrollador, el proceso permanecía invisible. El paquete cuenta con unas 50.000 descargas semanales. La versión manipulada se distribuyó además a través de otros 17 paquetes de Injective. Quien incluyera uno de ellos resultaba afectado, sin haber instalado nunca directamente la biblioteca principal.
Cómo entró la puerta trasera en el código
La vía de entrada pasó por el propio proyecto oficial. La función maliciosa llegó al repositorio de GitHub a través de commits realizados desde una cuenta con una larga historia de contribuciones. Este tipo de cuentas no generan sospechas. Precisamente eso hace tan efectivo el secuestro de un colaborador establecido.
Lo llamativo fue el antecedente. Ya semanas antes del lanzamiento apareció en el repositorio una rama de prueba con el nombre explícito de una comprobación de puerta trasera. Estas huellas son evidentes retrospectivamente, pero fáciles de pasar por alto en el día a día de un proyecto de código abierto activo.
Por qué afecta a cada compilación
El incidente lleva una etiqueta de criptomonedas, pero el patrón es universal. Cada aplicación moderna extrae docenas o incluso cientos de paquetes externos, a menudo a través de múltiples niveles. Basta con un único eslabón comprometido. Entonces, el código malicioso se ejecuta con los permisos de la compilación.
Especialmente delicadas son las dependencias transitivas. Un equipo incluye conscientemente un paquete y hereda así toda su cadena, que nunca ha verificado. Quien almacene credenciales, tokens o claves en un entorno de desarrollo con dependencias no verificadas está entregando exactamente lo que busca este tipo de ataque.
Qué deben hacer ahora los desarrolladores y los equipos de seguridad
La primera pregunta es: ¿Se está ejecutando una versión afectada en su propia infraestructura? Sin un inventario fiable de dependencias, la respuesta se convierte en un juego de adivinanzas. Solo después se activan las palancas técnicas.
Verificación inmediata
- ✓Rastrear la versión del SDK afectada en todos los proyectos, incluyendo integraciones directas y transitivas, y luego actualizar a la versión corregida.
- ✓Tratar todas las claves y mnemónicos que pasaron por una versión afectada como comprometidas, rotarlas y mover los saldos.
- ✓Fijar las dependencias mediante archivos Lock y asumir las actualizaciones de forma consciente en lugar de automática.
- ✓Verificar los certificados de origen (provenance de npm) y las firmas de paquetes, así como mantener una lista de materiales de software (SBOM).
- ✓No almacenar secretos duraderos en entornos de compilación con dependencias no verificadas y restringir rigurosamente los permisos en el sistema CI/CD.
Las herramientas de análisis de dependencias reducen el tiempo de reacción porque detectan un paquete manipulado antes de que se despliegue ampliamente. Sin embargo, la verdadera palanca sigue siendo organizativa: quien no conoce su cadena de suministro, no puede protegerla.
Un caso de prueba para la cadena de suministro
Injective declaró haber resuelto el incidente en menos de una hora y no haber dañado a ningún usuario. Esta valoración proviene del propio proveedor. Independientemente de ello, la lección permanece: la rápida respuesta de un proyecto no exime a los usuarios de asegurar su propia cadena.
Para las empresas con obligaciones derivadas de NIS2 o DORA, el riesgo de la cadena de suministro ya no es un tema abstracto. Ambos marcos normativos exigen que las organizaciones controlen los riesgos de sus proveedores y componentes. Un paquete manipulado en su propia compilación es precisamente el caso para el que se redactaron estas disposiciones.
Preguntas frecuentes
Cada pregunta está cerrada. Un toque desbloquea la respuesta.
¿Qué es un ataque a la cadena de suministro?
Un ataque a la cadena de suministro manipula un componente que muchos objetivos utilizan en común, como una dependencia de software pública. El código malicioso fluye entonces a través de la ruta de instalación normal hacia todos los que integran el paquete.
¿Estoy afectado si nunca instalé directamente el SDK?
Es posible. La versión manipulada se distribuyó a través de 17 paquetes adicionales. Quien incluía uno de ellos heredaba la dependencia de forma transitiva, sin haber descargado nunca la biblioteca real directamente.
¿Basta con actualizar a la versión corregida?
Como primer paso sí, como único no. Las claves y mnemonics que pasaron por una versión afectada se consideran comprometidas. Deben rotarse, y los saldos deberían moverse.
¿Cómo llegó el código malicioso a un proyecto oficial?
Mediante commits de una cuenta con un largo historial de contribuciones en el repositorio oficial. Un colaborador establecido no despierta sospechas, lo que hace que la toma de control de dicha cuenta sea especialmente efectiva.
¿Qué protege más eficazmente contra estos ataques?
Un inventario de dependencias conocido, archivos de bloqueo fijos, pruebas de origen verificadas y firmas, así como permisos estrictos en la compilación. Además, no tener secretos duraderos en entornos con dependencias no verificadas.
Recomendaciones de lectura de la redacción
RecomendaciónRobo de tokens OAuth: cómo los atacantes burlan el MFARecomendaciónCómo se desarrolla un ataque de ransomwareRecomendaciónLo que realmente diferencia a EDR y XDR
