El paquete malicioso del SDK de Injective tiene como objetivo las claves privadas y las frases de recuperación

Una versión maliciosa de una herramienta de software utilizada por los desarrolladores de Injective fue diseñada para recopilar claves privadas de billetera y frases de recuperación, lo que generó preocupación por las aplicaciones que manejaban información sensible de billeteras a través de la versión afectada. Los hackers comprometieron un paquete de software utilizado por desarrolladores que crean billeteras y aplicaciones para la blockchain de Injective, añadiendo código capaz de recopilar secretamente credenciales de billeteras cripto.

La empresa de seguridad Socket encontró el código malicioso en la versión 1.20.21 de @injectivelabs/sdk-ts, un paquete que ayuda a las aplicaciones a conectarse con Injective y gestionar funciones relacionadas con la billetera. El paquete normalmente recibe unas 50.000 descargas a la semana, aunque esa cifra incluye todas las versiones y no representa el número de personas afectadas por el incidente.

Socket indicó que la versión comprometida se descargó unas 310 veces. Sin embargo, una descarga no significa automáticamente que una clave de billetera haya sido expuesta. El código peligroso habría necesitado ejecutarse mientras una aplicación manejaba una clave privada o una frase de recuperación. No se ha publicado ningún número confirmado de billeteras afectadas, y no hay evidencia pública de que se hayan robado fondos.

El incidente no implicó una violación de la blockchain de Injective en sí. En cambio, los atacantes se dirigieron a un componente de software de confianza utilizado por los desarrolladores, un método comúnmente descrito como un ataque a la cadena de suministro de software.

El código malicioso estaba oculto dentro de una herramienta de confianza

Los desarrolladores a menudo dependen de paquetes de software listos para usar en lugar de escribir cada parte de una aplicación desde cero. Estos paquetes pueden manejar tareas como conectarse a una blockchain, crear billeteras y firmar transacciones. En este caso, el código malicioso se colocó dentro de un paquete oficial de Injective y estaba diseñado para activarse cuando una aplicación procesaba información sensible de la billetera. Socket dijo que podía capturar una clave privada o una frase mnemotécnica de recuperación e intentar enviar los datos mientras disfrazaba la actividad como un informe técnico ordinario.

Una clave privada otorga a su titular el control sobre la billetera cripto asociada. Una frase de recuperación puede utilizarse para restaurar la misma billetera en otro dispositivo. A diferencia de una contraseña normal de cuenta, estas credenciales no pueden simplemente restablecerse después de ser expuestas.

Las compromisiones de claves privadas se han convertido en una de las formas más dañinas de ataque cripto porque los delincuentes pueden tomar el control directo de las billeteras sin necesidad de romper la blockchain subyacente. Una revisión de seguridad reciente encontró que los incidentes de claves privadas representaron aproximadamente el 40 % de las pérdidas registradas en el conjunto de datos que examinó. El incidente de Injective también muestra por qué los atacantes se dirigen cada vez más a software y plataformas en los que los usuarios ya confían. Un nombre de paquete familiar, una cuenta de desarrollador establecida o una aplicación reconocida pueden hacer que la actividad maliciosa parezca legítima y reducir la probabilidad de que los usuarios la cuestionen.

Socket dijo que los cambios no autorizados se enviaron a través de la cuenta de GitHub de un desarrollador con un historial establecido de contribuciones al proyecto Injective. El propietario genuino de la cuenta detectó posteriormente la actividad y revirtió los cambios. El informe disponible no identifica al atacante ni explica cómo se accedió a la cuenta.

Diecisiete paquetes relacionados aumentaron la posible exposición

El código robador de billeteras se encontraba en la versión 1.20.21 del paquete principal SDK de Injective. Sin embargo, otros 17 paquetes dentro de la colección npm de Injective se lanzaron con enlaces a la misma versión afectada. Esto significaba que algunos desarrolladores podrían haber recibido el software comprometido indirectamente. Una aplicación podría haber instalado un paquete de Injective, mientras que ese paquete incorporaba automáticamente el SDK afectado entre bastidores.

Por lo tanto, el incidente no debe describirse como 18 paquetes infectados por separado. La evidencia disponible muestra que el SDK principal contenía la funcionalidad maliciosa, mientras que 17 paquetes relacionados dependían directa o indirectamente de esa versión. Socket dijo que la versión afectada se marcó como obsoleta después de descubrirse la compromiso y se publicó una versión limpia. Sin embargo, en el momento del informe de Socket, la versión comprometida no se había eliminado completamente de npm, y el material de lanzamiento relacionado seguía disponible a través de GitHub.

Los informes también han diferido sobre la fecha exacta del incidente. La cronología publicada por Socket se refiere al 8 de junio, mientras que algunos informes secundarios han situado la actividad en julio. Dado que el mes no se ha resuelto de forma independiente, la fecha exacta debe atribuirse a la fuente en lugar de afirmarse como un hecho indiscutible.

Los desarrolladores y los usuarios de billeteras afectadas deben reemplazar las credenciales expuestas

Se ha aconsejado a los desarrolladores que utilizaron la versión 1.20.21, ya sea directamente o a través de otro paquete de Injective, que asuman que las credenciales de la billetera procesadas por el software afectado pueden haber sido expuestas.

Las acciones recomendadas incluyen:

• Comprobar los archivos del proyecto y los registros de instalación para la versión 1.20.21.
• Actualizar los paquetes afectados de Injective a una versión limpia verificada.
• Borrar las copias de paquetes almacenadas y recompilar las aplicaciones.
• Crear nuevas claves privadas y frases de recuperación.
• Transferir activos fuera de las billeteras que utilizaron credenciales manejadas por el software afectado.
• Revisar la actividad de la billetera para detectar transacciones no autorizadas.
• Revocar los permisos concedidos anteriormente por billeteras potencialmente expuestas.

Actualizar solo el paquete puede no proteger una billetera si sus credenciales ya fueron copiadas. Una vez que otra parte obtiene una clave privada o una frase de recuperación, la antigua billetera ya no debe considerarse segura. Los usuarios de billeteras también deben examinar los permisos que aprueban. En un caso separado, un atacante robó unos 92.000 dólares en Tether Gold después de que una víctima firmara una solicitud de permiso maliciosa, lo que demuestra que los delincuentes no siempre necesitan obtener una frase semilla directamente para apropiarse de los activos.

Aunque ese caso utilizó una técnica diferente, destaca el mismo problema más amplio: la seguridad cripto depende no solo de la blockchain, sino también del software, las aprobaciones y los servicios que rodean a una billetera. Actualmente no hay evidencia de que la blockchain de Injective haya sido hackeada, de que cada billetera de Injective haya estado en riesgo o de que se haya robado una cantidad confirmada de criptomonedas. El peligro conocido se limita a las aplicaciones que instalaron el paquete comprometido y procesaron credenciales de billetera a través de él.