Resumen

  • El ataque de abril de 2018 convirtió anuncios BGP más específicos contra direcciones de Route 53 en respuestas DNS falsas para MyEtherWallet, pero solo en los caminos y resolutores que aceptaron ese estado.
  • La dirección no debe buscar un único control soberano: debe asignar dueño, telemetría y capacidad de rechazo a cada capa, y reservar una confirmación independiente para la acción que ya no puede deshacerse.

El nombre correcto no era una prueba

Para el usuario, myetherwallet.com seguía siendo el nombre escrito. El engaño ocurrió antes de que el navegador pudiera preguntar quién respondía realmente. Un resolutor recursivo había seguido una ruta hacia servidores impostores y devolvió la dirección falsa como resultado de una consulta ordinaria.

Cloudflare observó el 24 de abril de 2018 anuncios /24 dentro de cuatro rangos /23 de Amazon usados por Route 53. Comenzaron cerca de las 11:05 UTC y persistieron aproximadamente hasta las 12:55. El espacio estaba asociado a Amazon AS16509; el origen observado fue eNet AS10297 y parte de la propagación pasó por Hurricane Electric AS6939.

Esos datos no identifican al atacante. Cloudflare señaló que un cliente de eNet pudo haber originado los anuncios. El AS que aparece en una tabla BGP es evidencia técnica de origen observado, no una sentencia sobre intención, control humano o responsabilidad penal.

La longitud hizo el trabajo. Las rutas falsas eran más específicas que los anuncios legítimos agregados de Amazon. Los operadores que las aceptaron podían preferirlas sin retirar la ruta original. Otros tránsitos no parecieron propagarlas. Por eso el incidente no tuvo un minuto global ni una frontera uniforme.

Un resolutor podía exponer a una red inocente

El cliente final no necesitaba estar conectado a un proveedor que hubiera aceptado la ruta. Bastaba con usar un resolutor cuya instancia o camino sí la hubiera elegido. El resolutor consultaba al falso servidor autoritativo, recibía una respuesta para MyEtherWallet y la servía a sus clientes.

Cloudflare enumeró ubicaciones afectadas de 1.1.1.1 en Chicago, Oceanía, Asia, Oriente Medio y África, mientras otras seguían funcionando. Esa distribución muestra que la dependencia real era la combinación entre anycast, interconexión y selección de rutas del resolutor.

El atacante tampoco imitó todo Route 53. Los servidores respondían a myetherwallet.com y dejaban fallar otras consultas. Esa conducta selectiva concentró el ataque y, al mismo tiempo, produjo una señal: una autoridad que responde bien para un objetivo valioso y falla para zonas ajenas no se comporta como una avería normal.

El ataque todavía encontró una puerta cerrada

La respuesta DNS falsa condujo a una página de phishing. Según Cloudflare, el sitio presentó un certificado autofirmado. El navegador reconoció el nombre, pero no confió en el emisor. La cadena aún podía detenerse.

Los relatos públicos indican que el daño se produjo cuando algunas personas ignoraron la advertencia y continuaron. MyEtherWallet calculó después una pérdida de unos 150.000 dólares en Ether. El monto debe citarse como estimación del servicio afectado; no hay en el paquete revisado una auditoría completa de víctimas y transacciones.

Esta última decisión no absuelve a la infraestructura. El usuario vio la advertencia solo después de que un anuncio hostil fuera propagado, un camino lo prefiriera, un resolutor llegara al impostor y una respuesta falsa fuera aceptada. Culpar exclusivamente al clic final borra cuatro decisiones anteriores.

No hubo una autoridad única

El anunciante podía producir información de alcance. Los tránsitos podían difundirla o filtrarla. Cada red receptora podía aceptarla. El resolutor podía validar o no el dato DNS. El navegador podía rechazar el certificado. La aplicación podía exigir o evitar la exposición de secretos y la firma de una transferencia.

Cada actor dominaba una pregunta más estrecha que el resultado. BGP no certificaba propiedad. DNS no certificaba la ruta. TLS no certificaba la intención comercial. La interacción del monedero no corregía ninguna mentira previa.

El fraude ensambló respuestas parciales hasta construir una apariencia completa. Esa es la autoridad por capas: poder efectivo sin un centro que posea todo el sistema.

La diferencia entre RPKI y DNSSEC

RFC 6811 permite comparar el origen de una ruta con autorizaciones validadas. Una red que aplique ROV puede rechazar un /24 de origen distinto si la autorización está diseñada con la longitud correcta, antes de que esa ruta influya en un resolvedor.

RPKI no valida el camino entero ni obliga a todos los operadores. Un adversario puede intentar falsificar el origen autorizado en el AS-PATH. Una ROA demasiado permisiva también deja espacio a anuncios específicos. Es un veto local sobre el origen, no una policía global.

DNSSEC responde a otra pregunta. RFC 4033 define autenticación de origen e integridad de datos DNS; RFC 9364 la declara práctica actual recomendada. El resolutor validador puede rechazar la respuesta del impostor aunque BGP le haya llevado hasta él.

AWS lanzó firma DNSSEC para zonas públicas de Route 53 y validación en Route 53 Resolver en diciembre de 2020. Esa fecha demuestra una capacidad posterior, no el estado exacto de la zona de MyEtherWallet en 2018. Tampoco convierte a DNSSEC en filtro BGP o control de transacciones.

Una lista de mitigaciones no es una arquitectura

MyEtherWallet anunció después bloqueo de registro y registrador, HSTS y precarga, CAA, DNSSEC, CDN y protección DDoS. Son controles útiles, pero no intercambiables.

Los bloqueos impiden cambios de dominio; el ataque observado no necesitó cambiar el dominio. CAA restringe emisores de certificados, pero el navegador ya desconfiaba del certificado autofirmado. HSTS precargado elimina la opción de ignorar el error. DNSSEC autentica el dato. ROA y ROV actúan sobre la ruta. El monitoreo detecta la combinación.

Una empresa madura no pregunta si “tiene todos”. Pregunta qué condición detiene cada uno, quién conserva las claves y contactos, qué alerta produce, cuánto tarda la recuperación y qué control permanece independiente si la cuenta principal cae.

El límite que propone Running-Code Primacy

La tesis de Heng Lu ayuda a evitar una conclusión equivocada. Los registros institucionales describen estados, pero el poder práctico nace de sistemas en ejecución que los aceptan. La ruta de AS10297 fue eficaz en algunas redes y nula en otras. La respuesta falsa fue útil en algunos resolutores y no en otros. La advertencia TLS continuó siendo un rechazo local.

Eso no significa que la descentralización garantice verdad. Significa que distribuye oportunidades de aceptación y de negativa. La seguridad depende de que la evidencia de una capa no se convierta automáticamente en mandato para la siguiente.

La capacidad técnica tampoco equivale a autoridad legítima. Atraer paquetes no otorgó derecho sobre direcciones de Amazon. Responder por un nombre no transfirió el dominio. Obtener una interacción no convirtió el engaño en consentimiento.

Una conclusión limitada y útil

No sabemos quién ejecutó el ataque. No sabemos cuántos resolutores almacenaron la respuesta ni cuánto duró cada caché. No debemos afirmar que AWS, Route 53 o el código de MyEtherWallet fueron comprometidos. Tampoco debemos transformar una estimación de pérdidas en cifra auditada.

Sí sabemos que una ruta temporal cruzó capas hasta producir acciones permanentes. El control más fuerte es el que impide que una prueba estrecha herede autoridad que nunca tuvo.

Una ruta debe poder ser rechazada por su origen. Una respuesta debe poder ser rechazada por su firma. Un certificado debe poder ser rechazado sin excepción. Y una transferencia irreversible debe confirmarse en una superficie que la página web no pueda reescribir.

Fuentes