Envenenamiento de direcciones: el ataque que solo necesita que copies lo equivocado
Casi todos los ataques contra usuarios de cripto necesitan que cometas un error: pulsar un enlace, escribir una frase semilla en un formulario, aprobar algo que no leíste. El envenenamiento de direcciones necesita menos que eso. Necesita que copies una dirección de tu propio historial de transacciones.
No hay malware, ni web de phishing, ni ninguna firma que sacarte con engaños. La aportación entera del atacante consiste en dejar una cadena de aspecto plausible en un sitio al que más adelante irás a buscar.
Cómo funciona
Empecemos por lo que lo hace posible: nadie lee direcciones. Una dirección de Bitcoin o Ethereum son treinta y tantos caracteres de base58 o hexadecimal sin significado, sin una suma de verificación que puedas juzgar a ojo y sin ningún motivo para retenerla en la cabeza. Así que todos los monederos, exploradores de bloques y exchanges las acortan para mostrarlas —0x8f3C…9A063— y todos los usuarios aprenden a comprobar los extremos visibles y saltarse el medio.
Ese hábito es toda la superficie de ataque.
El atacante genera direcciones por fuerza bruta hasta que una comparte los primeros y los últimos caracteres con una dirección que sí usas, normalmente una a la que enviaste dinero hace poco. Es barato. Generar pares de claves es rápido, y hacer coincidir, digamos, cuatro caracteres iniciales y cuatro finales lleva segundos en hardware corriente. Nadie está rompiendo nada; solo tiran los dados hasta que un número resulta familiar.
Después meten esa dirección en tu historial. Los métodos habituales:
Dusting. Te envían una cantidad minúscula —unos satoshis, una fracción de céntimo de algún token— desde la dirección parecida. Es una transacción entrante corriente, así que aterriza en tu historial como cualquier otra. En cadenas UTXO ese polvo se convierte además en una moneda gastable dentro de tu monedero, lo cual importa más adelante.
Transferencias de valor cero. En cadenas EVM, una transfer de cero tokens ERC-20 es una transacción válida. El atacante envía 0 tokens desde tu dirección a su dirección parecida, y algunas interfaces lo muestran como un pago saliente hecho por ti. Tu historial pasa a mostrar que aparentemente enviaste a una dirección que nunca elegiste.
Eventos falsos. Un contrato de token malicioso puede emitir un evento Transfer que nunca ocurrió. Los exploradores y monederos que confían en los registros de eventos lo mostrarán. No se movió nada; el registro es sencillamente una mentira.
Y luego esperan. Días, a veces meses. El ataque cobra la próxima vez que vas a pagar a esa misma contraparte, recorres el historial buscando «la dirección que usé la última vez» y copias la fila equivocada. Ambas se ven como 0x8f3C…9A063. Compruebas los extremos. Los extremos coinciden.
Por qué el consejo habitual no aguanta
«Comprueba siempre la dirección» es la recomendación estándar, y por sí sola falla, porque comprobar es precisamente lo que el ataque da por descontado. Tú sí comprobaste. Comparaste los seis caracteres que te mostró el monedero con los seis caracteres que recordabas, y eran idénticos, porque el atacante los hizo idénticos.
La verificación solo sirve cuando aquello que comparas es caro de falsificar. Cuatro o seis caracteres coincidentes cuestan segundos. Dieciséis caracteres coincidentes costarían más de lo que vale el robo. Todo el juego consiste en en qué extremo de esa curva se sitúan tus hábitos.
Hay una segunda trampa en las cadenas UTXO. Ese pago de polvo es ahora una moneda dentro de tu monedero y, si tu monedero consolida entradas automáticamente, puede acabar barrido dentro de una transacción posterior, enlazando la dirección del polvo con el resto de tus monedas. Es un problema de privacidad más que de robo, pero es la razón por la que conviene ignorar el polvo en lugar de ordenarlo.
Qué defiende de verdad
Nunca saques una dirección de un historial de transacciones. Este es el único cambio que importa. Tu historial es un registro de lo que ocurrió, no una lista de en quién confías, y cualquiera en el mundo puede escribir en él. Consigue las direcciones de la contraparte, por un canal en el que notarías a un impostor, o de una agenda que hayas rellenado tú.
Compara direcciones enteras, o compara algo que resuma la dirección entera. Leer los cuarenta y dos caracteres no es realista. Comparar un identicono —una pequeña imagen generada de forma determinista a partir de toda la cadena— sí lo es, porque una dirección parecida que difiera en cualquier punto del medio produce un dibujo visiblemente distinto. Tu ojo hace el trabajo que tu paciencia no hará.
Usa un contacto guardado. Una dirección que guardaste una vez, desde una fuente que verificaste una vez, ya no puede envenenarse después. Para eso sirven las agendas de direcciones, y por eso SSP guarda los contactos en tu dispositivo y no en un servidor: una lista de contactos solo es fiable si nadie más puede editarla.
Manda un pago de prueba en transferencias grandes o primerizas. Cantidad pequeña, confirma la recepción por otro canal, y luego envía el resto. Las comisiones hacen que esto sea molesto, y sigue siendo lo correcto para un pago que odiarías perder.
Ignora el polvo. No lo gastes, no lo «limpies», y ten cuidado con la consolidación automática si te importa la privacidad.
Qué hace SSP al respecto
El envenenamiento de direcciones es tanto un problema de representación visual como de seguridad, así que parte de la respuesta vive en cómo se dibujan las direcciones.
SSP acorta las direcciones con seis caracteres iniciales y seis finales —0x8f3C4b…9A0631— en lugar de los tres o cuatro que usan muchas interfaces. No es una decisión cosmética. Cada carácter adicional multiplica el coste de fuerza bruta de producir una coincidencia, y doce caracteres visibles dejan una imitación convincente bastante fuera del alcance de la generación casual.
El medio se atenúa, no se borra. En la forma expandida el monedero muestra la cadena completa con los extremos en negrita y el medio en un color más claro, de modo que la parte que los atacantes cuentan con que te saltes sigue estando físicamente en pantalla, en vez de reemplazada por unos puntos suspensivos que podrían esconder cualquier cosa.
El mismo código corre en las dos aplicaciones. splitAddressForDisplay en SSP Wallet es un port directo del de SSP Key, mantenido deliberadamente idéntico para que una dirección se vea igual en tu navegador y en tu teléfono. Eso importa porque SSP te enseña la transacción dos veces, en dos dispositivos, y un segundo vistazo solo es una comprobación real si ambas superficies representan lo mismo de la misma manera. Dos truncados distintos permitirían que una discrepancia se escondiera en la diferencia.
En la pantalla de aprobación de SSP Key, el destinatario se muestra con un identicono generado a partir de la dirección completa, junto al texto acortado, y al tocarlo se despliega la dirección entera como texto seleccionable. El identicono es la parte que derrota un cambio en medio de la cadena: un atacante puede hacer coincidir tus caracteres iniciales y finales, pero no puede hacer coincidir una imagen derivada de todos los caracteres sin resolver un problema mucho más duro.
Nada de esto es una garantía. Si pegas una dirección envenenada y la apruebas en ambos dispositivos, SSP la firmará: eso significa ser un monedero que tú controlas y no un custodio que cuestiona tus decisiones. El multifirma 2 de 2 impide que otra persona gaste tus monedas; no puede impedir que tú pagues a la persona equivocada a propósito. Como en todo ataque que funciona haciendo que actúes tú, la defensa tiene que llegar antes de la firma, no durante.
La versión corta
El envenenamiento de direcciones funciona porque comparas seis caracteres en lugar de cuarenta y dos, y el atacante sabe cuáles seis. La defensa no es más diligencia: es no coger nunca una dirección de un sitio en el que un atacante pueda escribir, y usar herramientas que te devuelvan delante las partes que te saltarías.
