Saltar al contenido
Financial Context Wiki

Envenenamiento de direcciones

El envenenamiento de direcciones inserta un destinatario parecido en el historial de transacciones u otra interfaz que parece fiable para que un pago posterior se copie hacia el atacante; explota la verificación del destinatario, sin cambiar la dirección real ni robar su clave.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

El envenenamiento de direcciones es un fraude por sustitución del destinatario. El atacante genera una dirección distinta cuyo prefijo y sufijo visibles se parecen a los de un destinatario fiable y la inserta en el historial de transacciones u otra interfaz aparentemente fiable. Espera que un remitente copie después esa dirección parecida y firme un pago válido dirigido a ella. El ataque no altera la dirección legítima, no vulnera su clave privada ni hace que el consenso desvíe la transferencia.

El registro insertado puede proceder de una transacción real de un activo nativo, una transferencia de tokens de valor cero conforme al estándar o un log emitido por otro contrato de tokens. Las páginas de actividad de wallets y exploradores son vistas derivadas: una fila etiquetada como «enviado» puede proceder de campos de eventos, no de una transacción externa firmada por la dirección from mostrada. Hay que verificar por separado el remitente y destino de la transacción externa, el contrato invocado, el contrato emisor del evento, los campos indexados y los cambios reales de saldo.

El checksum ERC-55 ayuda a detectar algunos errores de escritura accidentales, pero una dirección distinta del atacante puede ser sintácticamente válida y tener un checksum correcto. Las direcciones EVM ordinarias de 20 bytes tampoco identifican por sí mismas la cadena prevista, el activo, la función del destinatario, el memo de depósito ni la llamada al contrato. Una instrucción de pago segura vincula todos esos datos con el destino completo.

Envenenamiento de direcciones
0 / 5
0 elementos revisados; 5 elementos pendientes

Completar esta revisión no demuestra que un activo, una transacción o un sistema sean seguros.

Cómo funciona

El atacante observa un patrón público de pagos y busca una vanity address que coincida con los caracteres que la wallet muestra de forma truncada. Hacer coincidir ciertos caracteres hexadecimales no clona una cuenta: los bytes ocultos siguen siendo distintos y el atacante controla la nueva clave. Una transferencia diminuta puede introducir esa dirección real en el historial. Por separado, ERC-20 exige tratar las transferencias de valor cero como transferencias normales y emitir Transfer; por ello, un registro de valor cero no demuestra por sí mismo falsificación, compromiso, autorización ni pérdida económica.

Un contrato de token malicioso también puede emitir su propio log Transfer(victim, lookalike, 0). Ese log es un dato real del recibo atribuible al contrato emisor, pero no es un evento del contrato canónico del activo ni demuestra que la víctima firmara la transacción externa. No obstante, un indexador que clasifique actividad a partir de topics de eventos sin suficiente contexto del contrato y de la llamada puede presentar una fila saliente engañosa.

El control decisivo es la intención final del pago. Debe vincular cadena y red, activo nativo o contrato de token exacto, dirección completa del destinatario, tipo de destinatario, importe y unidades raw, además de cualquier calldata, memo, destination tag o periodo de validez. Las direcciones de depósito de exchanges, bridges, proxies y rutas de un solo uso pueden caducar o exigir más que una dirección. El malware del portapapeles y los códigos QR comprometidos son ataques distintos, pero la misma verificación del destino completo detecta la sustitución antes de firmar.

Los nombres y pagos de prueba son controles auxiliares, no pruebas de identidad. Resuelva un nombre ENS para la cadena y el registro previstos en el momento de firmar; si se muestra un nombre inverso, vuelva a resolverlo hacia delante hasta la misma dirección. Una prueba pequeña solo ayuda si el destinatario la confirma de forma independiente y el pago principal reutiliza el mismo destino fijado. Volver a copiar desde el historial elimina esa protección.

Utilice este proceso:

  1. Fije la cadena, red, activo y contrato de token exacto, tipo de destinatario, formato de dirección, importe y cualquier memo, tag, calldata, versión o vencimiento a partir de una fuente independiente autenticada.
  2. Resuelva una vez el nombre o QR, valide su formato y checksum y vincule los bytes completos del destino con la cadena prevista; confirme hacia delante cualquier nombre inverso en lugar de tratar la etiqueta como identidad.
  3. Compare el destino con una allowlist controlada, libreta de direcciones o factura firmada, nunca con el historial; exija aprobación independiente o doble para destinatarios nuevos o con cambios relevantes.
  4. Decodifique la transacción exacta sin firmar: distinga el to nativo de un contrato de token o bridge e inspeccione en la calldata el destinatario, token, importe raw, aprobación, deadline y semántica del destino.
  5. Cuando proceda, envíe una pequeña prueba al destino fijado y obtenga confirmación independiente del destinatario; no vuelva a copiar una dirección del historial para el pago principal.
  6. Firme la transferencia principal solo desde el registro verificado, compare destino e importe completos en una pantalla fiable y compruebe después recibo, contrato emisor, logs y variaciones de saldo en la cadena correcta.
  7. Si sospecha envenenamiento o un envío erróneo, detenga pagos posteriores, conserve hashes y pruebas y contacte de inmediato al servicio destinatario, emisor o autoridades cuando corresponda; considere la congelación, devolución y recuperación condicionales, nunca garantizadas.

Ejemplos

  • El truncamiento oculta la diferencia. La dirección legítima 0x12ab1111111111111111111111111111111189ef y la del atacante 0x12ab9999999999999999999999999999999989ef se muestran ambas como 0x12ab...89ef. Comparten 4 + 4 = 8 caracteres hexadecimales visibles, pero difieren en los 32 caracteres centrales. Comparar solo los extremos mostrados produce una coincidencia falsa; comparar todos los bytes, no.
  • Trabajo de búsqueda vanity. Hacer coincidir k = 8 caracteres hexadecimales elegidos requiere un trabajo esperado de 16^8 = 4,294,967,296 candidatos. A una velocidad supuesta de 50,000,000 candidates/s, el tiempo esperado es 4,294,967,296 / 50,000,000 = 85.89934592 s. Esto ilustra un espacio de búsqueda, no un tiempo de ejecución prometido ni un umbral de alerta de una wallet.
  • Log frente a estado. Un contrato de token emite Transfer(victim, lookalike, 0). El saldo de la víctima pasa de 250,000.000000 a 250,000.000000, por lo que la variación es 0.000000; aun así, un índice de actividad puede mostrar una fila de transferencia. Compruebe el contrato emisor y la autorización de la llamada: la fila por sí sola no demuestra movimiento de valor ni firma de la víctima.
  • Una prueba debe fijar el destino. Una tesorería planea enviar 50,000 USDC, envía 1 USDC a una dirección verificada, recibe confirmación independiente y envía 49,999 USDC desde el mismo registro fijado: 1 + 49,999 = 50,000 USDC. Si el personal vuelve a copiar una dirección parecida del historial para el segundo tramo, la prueba deja de proteger el pago de 49,999 USDC.

Riesgos

  • El remitente copia una dirección parecida de un historial envenenado.
  • Una interfaz truncada oculta los caracteres centrales diferentes.
  • Un prefijo o sufijo vanity se confunde con la identidad del destinatario.
  • Una transferencia ERC-20 de valor cero crea una fila de historial engañosa.
  • Un token falsificado o su log se confunde con actividad del activo canónico.
  • Un indexador clasifica mal campos de eventos o los corrige demasiado tarde.
  • El nombre, símbolo o icono de un token spam suplanta un activo fiable.
  • Un malware del portapapeles sustituye una dirección verificada antes de firmar.
  • Una libreta de direcciones local o sincronizada está envenenada u obsoleta.
  • Una allowlist vincula la cadena, activo, función o versión de dirección equivocados.
  • Se ignora una advertencia por checksum inválido o ausente.
  • Un checksum válido se confunde con una prueba de identidad del destinatario.
  • La resolución ENS cambia, usa el coin type incorrecto o queda obsoleta.
  • Se muestra un nombre inverso sin confirmación de resolución directa.
  • Tras una prueba se vuelve a copiar desde una fuente no fiable.
  • La dirección de depósito, red, memo o tag de un exchange es incorrecto o ha caducado.
  • Se interpretan mal el destino y calldata exigida por un bridge, proxy o contrato.
  • El firmante solo comprueba texto truncado, incluso en un dispositivo hardware.
  • Una transferencia al destinatario equivocado se vuelve canónica antes de intervenir.
  • La víctima confía en una congelación discrecional del emisor o en una estafa de recuperación.

Errores comunes

  • El envenenamiento significa que hackearon la wallet, la clave o la blockchain. El ataque habitual explota la selección del destinatario mientras criptografía y consenso válidos ejecutan la intención firmada equivocada.
  • Una fila de valor cero debe ser una transacción falsa en cadena. Las transferencias conformes y los logs reales pueden tener valor cero; examine su origen y efecto sobre el estado.
  • Extremos coincidentes más checksum prueban el destinatario. Otra dirección válida puede coincidir en los caracteres visibles y tener su propio checksum válido.
  • Una prueba exitosa protege automáticamente la transferencia siguiente. La protección se pierde si el pago principal no reutiliza el destino fijado y confirmado.
  • Una wallet, validador o emisor de tokens siempre puede revertir el pago. Las facultades y cooperación para recuperar dependen del activo, servicio, jurisdicción, pruebas y tiempo.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...