Ledger y Ethereum: qué reveló la prueba de OneKey y qué actualizaciones corrigen las fallas

La prueba de OneKey fue real, pero también estuvo limitada: su equipo de seguridad Anzen reprodujo en un laboratorio una vulnerabilidad de sustitución de transacciones en la app de Ethereum 1.22.1 de Ledger. Ledger sostiene que el problema ya había sido corregido en la versión 1.22.2, antes de que la demostración se hiciera pública, y que no encontró pruebas de ataques contra sus usuarios. 31731

El episodio deja, sin embargo, una lección más amplia. La seguridad de una cartera de hardware no depende únicamente de mantener las claves privadas aisladas. También depende de que el dispositivo muestre fielmente la operación que finalmente firma.

Qué reprodujo OneKey

La vulnerabilidad, identificada por Ledger como LSB-023, estaba relacionada con la intercalación de comandos mientras el usuario revisaba una transacción en la pantalla. Un equipo conectado podía enviar un nuevo comando APDU mientras el anterior todavía esperaba la respuesta del usuario. Como los parámetros de firma permanecían en un estado compartido durante esa revisión, podían modificarse después de mostrarse en el dispositivo y antes de generar la firma. 3

En términos sencillos, la pantalla podía mostrar la transacción A mientras el dispositivo terminaba firmando la transacción B. OneKey reprodujo ese comportamiento utilizando la versión antigua 1.22.1 en un entorno de laboratorio. Esto demuestra que el software antiguo era explotable bajo las condiciones necesarias, pero no que los sistemas de producción de Ledger o sus usuarios hubieran sido comprometidos. 172332

Ledger afirma que había identificado la vulnerabilidad mediante su propio proceso de seguridad y que incorporó medidas de protección en la app de Ethereum 1.22.2. La información publicada también señala que el problema subyacente fue corregido en Secure SDK 26.6.1. 172124

¿Hackearon a alguien?

La posición de Ledger fue tajante: «Ningún usuario de Ledger fue hackeado». La información disponible no describe pérdidas conocidas vinculadas a la reproducción de OneKey, pero esa afirmación debe entenderse como un reporte sobre la explotación observada, no como una prueba de que hubiera sido imposible atacar una versión afectada. 172031

La diferencia es importante. Una reproducción en laboratorio puede confirmar que una ruta vulnerable funciona bajo determinadas condiciones sin demostrar que delincuentes la hayan utilizado en la práctica.

Las otras dos fallas corregidas en la versión 1.22.3

La versión 1.22.3 corrigió otras dos vulnerabilidades de la app de Ethereum que seguían siendo relevantes después de la actualización a 1.22.2. El índice de boletines de seguridad de Ledger las identifica como LSB-024 y LSB-025. 46

LSB-024: un lote de firma clara podía ocultar operaciones

LSB-024 estaba relacionada con un fallo en el manejo de enteros o del número de operaciones durante la firma clara (clear signing). Un lote especialmente preparado con 257 operaciones podía hacer que el dispositivo mostrara únicamente la operación final, aunque firmara el lote completo.

Se trata de un fallo de integridad en la revisión de la transacción. El dispositivo podía seguir solicitando la confirmación del usuario, pero la información mostrada ya no describía fielmente todo el contenido que se iba a firmar. Ledger denomina el problema «bypass de la firma clara mediante truncamiento del contador de la matriz». 46

LSB-025: un pago de intercambio podía convertirse en una aprobación de tokens

LSB-025 afectaba al flujo de los intercambios. Un proveedor de swaps comprometido podía sustituir el pago esperado por una aprobación de tokens sin provocar una nueva solicitud de confirmación en el dispositivo. Ledger describe el problema como «el flujo de intercambio aceptaba una aprobación de tokens en lugar de un pago». 46

Los límites de la vulnerabilidad son relevantes. No se describió como un mecanismo para crear una autorización ilimitada ni para aprobar una dirección arbitraria elegida por el atacante. Aun así, podía llevar al usuario a firmar una aprobación que no pretendía autorizar, algo materialmente distinto del pago esperado en un intercambio. 46

¿Por qué LSB-024 y LSB-025 no llegaron con la versión 1.22.2?

El material público disponible para este informe indica que los cambios relacionados con las dos fallas posteriores ya se habían preparado o fusionado meses antes del lanzamiento de la versión 1.22.2. Sin embargo, las correcciones aparecieron en la versión 1.22.3. Los reportes describen la omisión como una cuestión de lanzamiento o integración que sigue sin resolverse públicamente. 37

No existe documentación pública suficientemente autorizada para determinar si la causa fue la priorización del lanzamiento, un fallo de integración, las pruebas u otra decisión interna. La conclusión que sí puede sostenerse es más limitada: las correcciones no se incluyeron en la versión 1.22.2 y el motivo preciso sigue sin estar explicado públicamente. Afirmar algo más contundente iría más allá de las pruebas disponibles.

Qué revela el caso sobre el modelo de seguridad actualizable de Ledger

Ledger defendió que una arquitectura actualizable permite corregir y distribuir parches para vulnerabilidades en las aplicaciones del dispositivo y en el software que las respalda. En teoría, el proceso consiste en identificar un fallo, desarrollar una solución, publicarla y divulgar después los detalles técnicos. LSB-023 fue presentada como un ejemplo de ese procedimiento: la vulnerabilidad se identificó internamente, se corrigió y posteriormente se documentó en un boletín de seguridad. 3

El beneficio es claro: una vulnerabilidad de software descubierta no tiene por qué permanecer para siempre en una cartera de hardware. Pero el modelo también impone una responsabilidad operativa a los usuarios. Un parche solo protege el dispositivo cuando la aplicación afectada se ha actualizado realmente, y un lanzamiento tardío o incompleto puede dejar problemas relacionados sin resolver, como muestra la diferencia entre las versiones 1.22.2 y 1.22.3. 37

Qué deben hacer los usuarios de Ledger

1. Actualiza la app de Ethereum a la versión 1.22.3 o posterior. Los reportes identifican la versión 1.22.3 como la que corrigió LSB-024 y LSB-025, mientras que la versión 1.22.2 contenía la corrección de la app para LSB-023. 1737
2. Utiliza el administrador de dispositivos de Ledger Live y los canales oficiales de Ledger para instalar actualizaciones. Las instrucciones de Ledger indican que la app de Ethereum se instala mediante Ledger Live. 7
3. Revisa cada aviso en la pantalla del dispositivo, especialmente durante los intercambios. Si el dispositivo solicita una aprobación cuando esperabas un pago, detén la operación y recházala.
4. Desconfía de lotes inusualmente grandes u opacos. Evita la firma ciega cuando sea posible, sobre todo si no puedes revisar de forma comprensible todo el contenido en el dispositivo.
5. Incluye el ordenador y los proveedores conectados en tu modelo de amenazas. Estas vulnerabilidades afectaban a la comunicación entre el equipo o el servicio y la aplicación de Ledger. Una cartera de hardware reduce ciertos riesgos, pero no elimina los derivados de malware, páginas maliciosas, aplicaciones descentralizadas comprometidas o proveedores de swaps hostiles. 328
6. Revisa las autorizaciones de tokens después de usar software afectado. Si realizaste intercambios o firmaste aprobaciones con una versión vulnerable de la app, comprueba si existen autorizaciones innecesarias y revócalas mediante una interfaz de confianza.

La conclusión inmediata es sencilla: OneKey demostró una vulnerabilidad real en una versión antigua de la app de Ethereum de Ledger, pero las pruebas disponibles no muestran un hackeo activo de Ledger. El incidente sigue siendo relevante porque LSB-024 y LSB-025 demuestran que instalar la primera corrección disponible no necesariamente puso fin a toda la historia de seguridad.