Ledger rechazó las afirmaciones de que había sido hackeado después de que el equipo de seguridad de OneKey, Anzen, reprodujera una falla de reemplazo de transacciones contra una versión desactualizada de la aplicación Ethereum de Ledger.
Resumen
- OneKey reprodujo un ataque de sustitución de transacciones contra la versión 1.22.1 de la aplicación Ethereum de Ledger en pruebas de laboratorio.
- Ledger dice que la aplicación Ethereum 1.22.2 agregó salvaguardas antes de que OneKey describiera públicamente su intento de reproducción en línea.
- Un atacante necesitaba control sobre las comunicaciones entre el dispositivo y el host a través de malware, páginas web hostiles o software de billetera comprometido.
- La versión 26.6.1 del SDK seguro bloqueó comandos intercalados antes de que llegaran directamente a las aplicaciones individuales del dispositivo Ledger.
- Ledger no encontró evidencia de que la vulnerabilidad fuera explotada contra usuarios o causara pérdidas de criptomonedas en ningún lugar.
El fundador de OneKey, Yishi Wang, dijo el 27 de agosto que los investigadores completaron el ataque contra la aplicación Ethereum 1.22.1 en un laboratorio. Ledger confirmó la vulnerabilidad subyacente pero dijo que ya había parcheado la aplicación afectada antes de que OneKey publicara su demostración.
La falla de Ledger Ethereum rompió la garantía de pantalla confiable
La vulnerabilidad involucraba la comunicación entre un dispositivo Ledger y su host conectado. Las aplicaciones de Ledger reciben instrucciones llamadas comandos de Unidad de Datos de Protocolo de Aplicación, o APDU, desde software de billetera, páginas web u otras interfaces.
Una aplicación afectada podía aceptar un segundo comando APDU mientras el usuario revisaba una operación anterior en la pantalla del dispositivo. El nuevo comando podía sobrescribir los parámetros de firma almacenados en memoria compartida sin actualizar la información mostrada.
En ese escenario, el usuario podía revisar la transacción A y aprobarla mientras la aplicación generaba una firma que cubría la transacción B. El dispositivo no advertiría al usuario de que la información subyacente había cambiado.
Ledger clasificó el problema como una condición de carrera de tiempo de verificación a tiempo de uso. Su boletín dijo que la falla anulaba la protección de pantalla confiable que las billeteras de hardware usan para permitir a los clientes verificar montos, direcciones y acciones de contratos antes de firmar.
El problema no reveló frases semilla ni extrajo claves privadas del elemento seguro. En cambio, podía hacer que la clave protegida firmara parámetros diferentes de los mostrados al usuario.
La explotación requería una conexión comprometida
Un atacante necesitaba control de las comunicaciones entre la aplicación de Ledger y su host. Ledger enumeró malware, una aplicación de billetera comprometida o una página web hostil con acceso WebHID o WebUSB como posibles rutas.
El ataque no podía realizarse de forma remota contra un dispositivo desconectado. Un usuario también tenía que aprobar la transacción mientras el software malicioso manipulaba su contexto de firma pendiente.
Ledger dijo que el defecto se encontraba en el manejo de entrada y salida de su SDK seguro, no en el sistema operativo del dispositivo ni en el firmware. Las aplicaciones compiladas con versiones afectadas del SDK dependían de sus propias comprobaciones de estado para rechazar comandos que llegaran durante una revisión activa.
Esto significa que la exposición era específica de la aplicación. Una aplicación permanecía protegida si cada punto de entrada de comando asíncrono verificaba correctamente su estado, incluso cuando se construía con el SDK afectado.
Ledger disputa si la prueba cuenta como un hackeo
Wang describió el resultado de laboratorio diciendo: "hackeamos Ledger". También dijo que la compañía solucionó el problema en la aplicación Ethereum 1.22.3.
El director de tecnología de Ledger, Charles Guillemet, cuestionó esa descripción. Dijo que "reproducir un error ya parcheado no es 'hackear Ledger'" y caracterizó el trabajo de OneKey como un ejercicio de laboratorio contra una aplicación más antigua.
El historial de versiones respalda una línea de tiempo más precisa. La aplicación Ethereum 1.22.2, lanzada el 13 de agosto, fue la primera actualización de aplicación que contenía comprobaciones de estado diseñadas para detener la ruta documentada de sustitución de transacciones.
Ledger luego lanzó Secure SDK 26.6.1 el 21 de agosto. Esa actualización bloquea comandos intercalados antes de que el código de la aplicación los reciba. Las aplicaciones se reconstruyeron posteriormente utilizando el SDK corregido.
Ledger ahora recomienda la aplicación Ethereum 1.22.3 o posterior porque la versión más reciente contiene la protección SDK más amplia y aborda otra falla de visualización de transacciones. Por lo tanto, OneKey tenía razón en que 1.22.3 está protegida, pero la primera corrección a nivel de aplicación apareció en 1.22.2.
Como informó anteriormente crypto.news, Ledger ya había dicho que su vulnerabilidad de firma de Ethereum fue corregida antes de la divulgación pública.
Los usuarios deben actualizar las aplicaciones a través de Ledger Live
Ledger dijo que no encontró evidencia de que los atacantes explotaran LSB 023 contra los clientes. No se han vinculado públicamente pérdidas de criptomonedas a este problema específico.
Los usuarios deben abrir Ledger Live, instalar las últimas aplicaciones del dispositivo y verificar la versión de la aplicación Ethereum en la billetera de hardware. Actualizar solo el firmware no reemplaza las aplicaciones construidas con un SDK afectado.
Los desarrolladores de terceros también deben revisar su manejo de estado y reconstruir las aplicaciones con Secure SDK 26.6.1 o posterior. Ledger dijo que la debilidad se introdujo en agosto de 2025 y afectó las versiones del SDK hasta 26.6.0.
La divulgación sigue a otras correcciones de seguridad de billeteras de hardware. En cobertura relacionada, BitBox parcheó dos fallas que afectaban la instalación de firmware y el manejo de direcciones de Bitcoin, también sin informar explotación confirmada.
