Disputas de Ledger sobre el reclamo de 'hackeo' de OneKey por un bug reproducido en la aplicación de ethereum

Ledger rechaza las acusaciones de “hacking” tras que OneKey reprodujera una vulnerabilidad de reemplazo de transacción en la antigua aplicación de Ethereum Ledger ha respondido tras el equipo de seguridad Anzen de OneKey afirmar que había “hackeado Ledger” al reproducir una falla de reemplazo de transacción en una aplicación desactualizada de Ethereum. Ledger reconoce que la vulnerabilidad era real, pero ya había sido corregida antes de la demostración pública de OneKey. ¿Qué sucedió? - El 27 de agosto, el fundador de OneKey, Yishi Wang, publicó un tweet indicando que su equipo había reproducido con éxito un ataque de reemplazo de transacción contra la aplicación de Ethereum de Ledger versión 1.22.1 en un entorno de laboratorio. Describió el problema como una condición de carrera entre la visualización de la transacción y el búfer subyacente de transacciones. - Ledger reconoció la vulnerabilidad subyacente, pero enfatizó que la empresa había aplicado un parche antes de que OneKey publicara la demostración. El CTO de Ledger, Charles Guillemet, dijo: “Reproducir una falla ya parcheada no es ‘hackear Ledger’”, calificando el trabajo de OneKey como un ejercicio de laboratorio contra una aplicación antigua. ¿Cómo funcionaba la falla (en términos sencillos)? - Las aplicaciones de Ledger reciben instrucciones llamadas APDU (comandos Application Protocol Data Unit) desde software de monedero, páginas web u otras interfaces anfitrionas. - En las versiones afectadas, se podía aceptar un segundo APDU mientras el usuario aún revisaba una transacción en la pantalla del dispositivo. Ese segundo comando podía sobrescribir los parámetros de firma en memoria compartida sin cambiar lo que se mostraba en el dispositivo. - Resultado: un usuario podría revisar y aprobar la transacción A en el dispositivo, mientras que la clave segura firmaba en realidad la transacción B — y el dispositivo no advertía al usuario que los datos subyacentes de firma habían cambiado. - Ledger clasificó esto como una condición de carrera tipo time-of-check to time-of-use (TOCTOU) que anulaba las protecciones de visualización confiable en las que confían los monederos hardware para que los usuarios verifiquen cantidades, direcciones y acciones de contratos. ¿Qué estaba y qué no estaba en riesgo? - La falla no exponía frases semilla ni extraía claves privadas del elemento seguro. En cambio, podía hacer que una clave protegida firmara entradas distintas a las mostradas al usuario. - Un atacante requería control del canal de comunicación entre la aplicación de Ledger y su anfitrión —por ejemplo, malware en el anfitrión, una aplicación de monedero comprometida o una página web hostil con acceso WebHID/WebUSB. El ataque no podía ejecutarse remotamente contra un dispositivo desconectado. - Un exploit exitoso también requería que el usuario aprobara una transacción mientras el software malicioso manipulaba el contexto de firma pendiente. Dónde residía la falla y cómo se corrigió - Ledger indica que el defecto estaba en el manejo de entrada/salida en su Secure SDK, no en el sistema operativo o firmware del dispositivo. Las aplicaciones construidas con versiones afectadas del SDK dependían de sus propias verificaciones de estado para rechazar comandos intercalados. - Debido a esto, la exposición era específica de la aplicación: una aplicación seguía siendo segura si todos los puntos de entrada asincrónicos verificaban correctamente el estado, incluso cuando se construía con el SDK afectado. - Cronología de las correcciones: - 13 de agosto: La aplicación de Ethereum 1.22.2 añadió verificaciones de estado a nivel de aplicación que detienen la ruta documentada de sustitución de transacciones. - 21 de agosto: Ledger lanzó Secure SDK 26.6.1, que bloquea comandos intercalados antes de que el código de la aplicación los reciba. Las aplicaciones se reconstruyeron posteriormente con el SDK corregido. - Ledger recomienda ahora la aplicación de Ethereum 1.22.3 o posterior, ya que incluye la protección más amplia del SDK y corrige una falla adicional en la visualización de transacciones. OneKey tenía razón al afirmar que 1.22.3 está protegida, pero la primera mitigación a nivel de aplicación llegó en 1.22.2. Recomendaciones prácticas para usuarios y desarrolladores - Ledger no tiene evidencia de que atacantes hayan explotado esta vulnerabilidad (identificada como LSB-023) ni se han reportado pérdidas cripto vinculadas públicamente a esta vulnerabilidad específica. - Los usuarios deben abrir Ledger Live, instalar las últimas aplicaciones del dispositivo y verificar la versión de la aplicación de Ethereum en su monedero hardware. Instalar una actualización de firmware por sí sola no reemplaza las aplicaciones construidas con un SDK afectado — también se deben actualizar las aplicaciones. - Los desarrolladores de aplicaciones de terceros deben revisar su manejo del estado y reconstruir sus aplicaciones con Secure SDK 26.6.1 o posterior. Ledger indica que la debilidad se introdujo en agosto de 2025 y afectó versiones del SDK hasta la 26.6.0. Contexto más amplio - Esta divulgación sigue a una serie de correcciones en monederos hardware; por ejemplo, BitBox recientemente parcheó dos vulnerabilidades relacionadas con la instalación del firmware y el manejo de direcciones Bitcoin, también sin evidencia de explotación confirmada. Conclusión El problema técnico demostrado por OneKey fue real pero limitado en alcance: requería un anfitrión comprometido y aprobación del usuario, y Ledger afirma que solucionó el problema antes de que la demostración fuera pública. Los usuarios deben actualizar sus aplicaciones mediante Ledger Live y los desarrolladores deben reconstruir sus aplicaciones con el SDK corregido para cerrar la ventana de exposición.