Dos de las mayores pérdidas de nuestro Rastreador de Incidentes comparten un mecanismo, y no es el que la gente espera. Nadie adivinó una clave. A quienes firmaban se les mostró una transacción y aprobaron otra distinta.
Esta guía trata sobre la distancia entre lo que un sitio web dice que hará una transacción y lo que la transacción hace realmente, y sobre qué pantalla resuelve esa discrepancia.
Por qué existe esa distancia
Cuando interactúas con una aplicación web que quiere que firmes una transacción, ocurren varias cosas a la vez. La página construye una transacción. Tu cartera la recibe. Tu cartera —o un dispositivo de hardware conectado— muestra alguna representación de ella. Tú apruebas.
La descripción que lees en la página la escribe la página. Es el texto promocional de la transacción. No se deriva de la transacción, y nada obliga a que ambas coincidan.
En el incidente de Bybit, el fallo declarado fue exactamente este: una transferencia rutinaria en la que la carga que se ejecutó difería de lo que mostraba la interfaz de firma. Se movieron aproximadamente 1500 millones de dólares estadounidenses, según el propio anuncio del FBI. Varias personas firmantes lo aprobaron. A cada una se le mostró la misma tergiversación, de modo que ser varias no aportó nada.
La jerarquía de las pantallas
No todas las pantallas merecen la misma confianza. En orden descendente:
- La pantalla propia de una cartera de hardware. La genera el dispositivo a partir de la transacción que realmente se le ha pedido firmar. Es lo más difícil de influir de toda la cadena para una página web comprometida, que es justamente la razón de que el dispositivo tenga pantalla.
- El diálogo de confirmación del software de tu cartera. Mejor que la página, pero se ejecuta en la misma máquina y, en el caso de una extensión de navegador, en un entorno que la página comparte.
- La descripción de la página web. Útil para entender la intención. Inservible como verificación.
El compromiso de Ledger Connect Kit ilustra el punto con precisión. Se inyectó código malicioso en una biblioteca cargada por muchas aplicaciones descentralizadas, y este presentaba a los usuarios una transacción de vaciado. Quien leyó la pantalla del dispositivo antes de aprobar pudo ver una transferencia que no había solicitado. Quien confirmó a partir de la descripción de la página, no.
Qué mirar exactamente
En la pantalla del dispositivo, para una transferencia:
- La dirección de destino: entera, no los cuatro primeros y los cuatro últimos caracteres. Los ataques de envenenamiento de direcciones funcionan precisamente generando direcciones cuyos extremos coinciden con los de otra que ya has usado.
- El importe y el activo. Confirma ambos, incluida la posición del decimal.
- La red. La transacción correcta en la cadena equivocada sigue siendo una pérdida.
Para una interacción con un contrato:
- La función que se invoca, cuando el dispositivo puede decodificarla. Un
approve,setApprovalForAllopermitinesperado cuando creías estar haciendo staking o reclamando algo es la señal para detenerse. - La dirección del gastador o del operador en una autorización, que es la dirección a la que estás facultando, no el contrato que crees estar usando.
- Las advertencias de firma a ciegas. Si el dispositivo dice que no puede decodificar lo que se le pide firmar, eso es información, no un estorbo.
Confirmación por otra vía
Para cualquier cosa de consecuencia, confirma el destino por un canal que no sea el que propone la transacción. Si una página aporta una dirección, y esa misma página confirma que la dirección es correcta, no has verificado nada. Esta es la versión organizativa del mismo control: si los procedimientos para transferencias grandes exigen una confirmación por vía separada, es porque un único canal comprometido puede ser coherente consigo mismo.
De qué no te protege esto
- Una autorización que ya concediste. Leer con cuidado las transacciones a partir de hoy no hace nada frente a una asignación permanente del año pasado. Véase cómo comprobar tus autorizaciones.
- Una frase de recuperación comprometida. Ningún cuidado en el momento de firmar sirve si otra persona puede reconstruir la cuenta.
- Un protocolo que está roto de por sí. Una transacción perfectamente legítima hacia un contrato vulnerable sigue expuesta a esa vulnerabilidad. La mayoría de los incidentes de nuestro rastreador afectan a usuarios que firmaron exactamente lo que pretendían.
- El cansancio. Este es el límite real. Nadie lee la centésima autorización rutinaria con el cuidado que puso en la primera, y los ataques se diseñan en torno a eso.
El resumen honesto
Leer lo que firmas es el único control que habría evitado varias de las pérdidas que registramos, y es también genuinamente difícil de sostener. Tómatelo de forma proporcionada: las interacciones pequeñas y rutinarias no necesitan ceremonia, y toda transacción cuya pérdida te importaría merece la pantalla del dispositivo, la dirección completa y una pausa.
No es asesoramiento. Conisec informa solo a título informativo. Nada de este artículo es asesoramiento financiero, jurídico, fiscal ni de seguridad. Verifícalo con las fuentes primarias enlazadas más arriba antes de actuar.
