Artículos anteriores en esta serie analizaron categorías de ataques contra el propio elemento seguro: inyección de fallos, análisis invasivo del chip y técnicas de canal lateral. Estas son amenazas reales, pero pertenecen a un nivel de ataque que requiere recursos significativos, equipos especializados y un objetivo individualizado. La mayoría de los usuarios nunca se enfrentará a ellas.
Los ataques a la cadena de suministro son diferentes. No requieren laboratorio ni acceso físico al dispositivo. No necesitan vulnerar el elemento seguro en absoluto, ya que operan en las capas de código que se encuentran por encima del chip. Un solo ataque exitoso a la cadena de suministro puede afectar a miles o millones de usuarios al mismo tiempo. La economía de estos ataques los hace mucho más atractivos para un rango más amplio de atacantes que cualquier técnica a nivel de hardware.
Este artículo examina el riesgo de la cadena de suministro en el contexto del software, utilizando dos incidentes documentados que involucraron a uno de los fabricantes de billeteras de hardware más utilizados del mundo.
Qué significa realmente un ataque a la cadena de suministro
En lugar de atacar directamente al usuario final, los atacantes explotan una relación de confianza como vector para un ataque a la cadena de suministro. Esto implica comprometer algo en lo que el usuario final confía, como una biblioteca de software, un mecanismo de actualización de firmware o un canal de distribución.
En las billeteras de hardware, los vectores de cadena de suministro más relevantes son:
Firmware del dispositivo enviado por aire: Actualizaciones que el fabricante distribuye a todos los dispositivos, de forma automática o con aprobación del usuario.
Bibliotecas de aplicaciones complementarias: Código que se incluye como parte del software de escritorio o móvil de la billetera.
Bibliotecas JavaScript de terceros: Código del que dependen los servicios conectados a la web del fabricante, obtenido de registros públicos de paquetes como NPM.
Distribución y logística: Intercepción física de dispositivos antes de que lleguen al usuario final.
Lo que hace peligrosos a estos vectores es su escala. El atacante invierte una vez y obtiene beneficios de todos los que interactúan con el componente comprometido antes de que se detecte y solucione.
El elemento seguro no brinda protección contra ninguno de estos vectores porque estos ataques nunca requieren vulnerar el chip. Operan aguas arriba de él. La clave sigue almacenada de forma segura dentro del elemento seguro mientras todo lo que lo rodea es manipulado.
Ataque a la cadena de suministro: Connect Kit (diciembre de 2023)
El 14 de diciembre de 2023, un ataque a la cadena de suministro contra el Connect Kit de Ledger, una biblioteca JavaScript utilizada por aplicaciones descentralizadas para interactuar con billeteras de hardware Ledger, resultó en el robo de entre US$ 484,000 y US$ 600,000 en activos. El ataque duró aproximadamente cinco horas, con el drenaje activo de fondos concentrado en una ventana de cerca de dos horas. Docenas de protocolos DeFi importantes se vieron afectados simultáneamente.
La mecánica de cómo ocurrió esto revela mucho sobre dónde falla realmente la seguridad de las billeteras de hardware en la práctica.
Cómo se ejecutó el ataque
Connect Kit de Ledger es una biblioteca JavaScript de código abierto publicada en NPM, el registro de Node Package Manager, el canal estándar de distribución de código JavaScript. Cientos de aplicaciones descentralizadas la integraron para permitir que sus usuarios conectaran billeteras de hardware Ledger a sus interfaces.
De manera crucial, Ledger distribuyó la biblioteca no solo mediante el mecanismo estándar de versionado fijo de NPM, sino también a través de un cargador CDN (Content Delivery Network), lo que provocaba que las aplicaciones dependientes obtuvieran automáticamente la última versión de la biblioteca en tiempo de ejecución en lugar de usar una versión fija y controlada.
Esto significaba que, en cuanto aparecía una nueva versión en NPM, toda aplicación que utilizara el cargador CDN la ejecutaría de inmediato, sin revisión, sin actualización manual y sin margen de seguridad.
El atacante obtuvo acceso a las credenciales de publicación de NPM de un ex empleado de Ledger a través de un ataque de phishing. El acceso del ex empleado a los sistemas internos de Ledger había sido revocado correctamente durante el proceso de salida, pero su clave API de NPM no fue revocada.
Las claves API evitan los requisitos de autenticación de dos factores de NPM, lo que significa que el atacante solo necesitaba la clave, sin ninguna autenticación secundaria.
Con acceso de publicación obtenido, el atacante subió tres versiones maliciosas de Connect Kit (1.1.5, 1.1.6 y 1.1.7) que contenían el malware Angel Drainer, un software que drenaba billeteras al crear solicitudes de aprobación de transacciones maliciosas que, al ser firmadas por el usuario, transferían los activos a la billetera del atacante.
Cuando el cargador CDN obtenía automáticamente la última versión, las dApps afectadas comenzaron a servir código malicioso a sus usuarios en cuestión de minutos tras la publicación, sin que los desarrolladores de esas aplicaciones tuvieran que hacer nada.
Ledger respondió rápidamente, desplegando una versión corregida en 40 minutos tras la alerta interna y coordinando con Tether para congelar los fondos robados. El punto de este análisis es que el vector de ataque existía y fue explotado.
Firmware actualizable como riesgo de cadena de suministro
La controversia de Ledger Recover (mayo de 2023) puso en evidencia un riesgo de cadena de suministro inherente a cualquier billetera de hardware con firmware actualizable. El servicio opcional de respaldo de frase semilla de Ledger, que cifraba y transmitía fragmentos de la frase semilla a tres custodios a través del firmware, no fue un ataque, pero demostró que existía una capacidad preocupante.
Una actualización de firmware, firmada y enviada por el fabricante, podría instruir al elemento seguro para manejar y transmitir material semilla. Como analizamos en nuestro desglose de Ledger Recover, el arranque seguro solo protege contra firmware de terceros; no limita lo que el fabricante implementa. Ese canal de actualización es un vector de cadena de suministro.
Si la infraestructura de firma del fabricante se viera comprometida, o si una actualización obligada por el gobierno introdujera cambios silenciosos, los usuarios no tendrían forma de detectarlo con anticipación.
¿Qué ocurre en un dispositivo con firmware actualizable?
Cuando confías en una billetera de hardware con actualizaciones de firmware controladas por el fabricante, estás confiando en:
Las intenciones del fabricante: que la empresa no implementará firmware que comprometa la seguridad del usuario, ahora ni en el futuro, sin importar presiones comerciales, regulatorias o cambios de propiedad.
La infraestructura de claves de firma del fabricante: que las claves privadas utilizadas para firmar el firmware están debidamente protegidas y nunca han sido comprometidas. Una clave de firma robada permitiría a un atacante distribuir firmware autenticado por el fabricante a todos los dispositivos.
Toda la cadena de distribución de actualizaciones: cada canal de distribución involucrado en llevar el firmware desde el desarrollo hasta el dispositivo.
Los procesos internos del fabricante: controles de acceso de empleados, procedimientos de salida, requisitos de revisión de código y sistemas de compilación seguros.
El entorno regulatorio: los fabricantes están sujetos a las leyes de su jurisdicción. Un gobierno con autoridad sobre un fabricante puede, en principio, obligar la entrega de firmware que sirva a intereses estatales.
Nada de esto significa que el firmware actualizable sea indefendible como arquitectura. Significa que la defensa se distribuye en una superficie de confianza más amplia y compleja de lo que la mayoría de los usuarios considera.
La alternativa: firmware inmutable
Algunas billeteras de hardware, como Tangem, utilizan firmware que se graba en el dispositivo durante su fabricación y no puede ser actualizado por nadie después de salir de la fábrica. Este enfoque implica una decisión de seguridad fundamentalmente diferente.
Las ventajas son bastante directas: se elimina la superficie de ataque de la cadena de suministro del firmware. No hay mecanismo de actualización que comprometer, ni clave de firma que robar, ni canal de distribución que envenenar. El firmware que se instaló en la fabricación es el que ejecutará el dispositivo durante toda su vida útil.
El fabricante no tiene control sobre el comportamiento del dispositivo después de su despliegue, lo que significa que tampoco tiene un canal por el que pueda, voluntaria o forzadamente, modificar lo que hace el dispositivo.
Una auditoría independiente de firmware por empresas como Kudelski Security, Riscure y SlowMist puede confirmar que el firmware es confiable y verdaderamente inmutable. Los usuarios de dispositivos inmutables deben confiar en la calidad de la auditoría inicial y podrían necesitar reemplazar el hardware ante cambios importantes de protocolo.
Reflexiones finales
Un ataque a la cadena de suministro no requiere equipamiento de laboratorio, análisis de canal lateral ni acceso físico al dispositivo.
Estos ataques pueden escalar de forma natural y eficiente a todos los usuarios de cada producto afectado simultáneamente. Los atacantes operan en capas que la mayoría de los usuarios nunca inspecciona, mediante mecanismos que suelen ser invisibles o que se asumen confiables.
Verifica siempre la autenticidad de la billetera en la primera configuración, compra directamente al fabricante o a distribuidores verificados y desconfía de cualquier aplicación que te pida aprobar algo que no reconoces.
