Resumo

  • Prefixos mais específicos dentro do espaço da Amazon desviaram parte do tráfego para servidores que respondiam seletivamente por myetherwallet.com; o efeito dependia do caminho de cada resolvedor.
  • A defesa madura conserva recusas locais em cada camada e correlaciona rota, DNS, TLS e transação antes que uma capacidade temporária produza uma perda permanente.

O incidente atravessou fronteiras que o contrato não mostrava

Em 24 de abril de 2018, usuários podiam estar na mesma cidade e receber respostas diferentes para o mesmo nome. A diferença não era o domínio digitado, mas o caminho do resolvedor recursivo escolhido por cada serviço.

Os coletores da Cloudflare viram, entre aproximadamente 11h05 e 12h55 UTC, anúncios /24 mais específicos dentro de quatro blocos /23 da Amazon usados pelo DNS autoritativo Route 53. O espaço legítimo estava ligado ao AS16509. O originador observado era o AS10297 da eNet, e parte da propagação apareceu por meio do AS6939 da Hurricane Electric.

Isso não identifica o autor. A Cloudflare registrou a possibilidade de um cliente da eNet ter feito o anúncio. Um ASN no plano de controle mostra como a rota apareceu, não quem apertou a tecla nem com qual intenção.

Os /24 podiam vencer pela regra do prefixo mais específico sem eliminar os agregados da Amazon. Alguns trânsitos aparentemente não os aceitaram. Por isso o evento foi regionalmente irregular, não um comando global.

A Cloudflare relatou nós do 1.1.1.1 afetados em Chicago, Oceania, Ásia, Oriente Médio e África, enquanto outros funcionavam. Um usuário cuja operadora nunca aceitou a rota podia receber a resposta falsa se o resolvedor usado por ele tivesse sido exposto.

Uma autoridade falsa que só sabia responder uma pergunta

Os servidores impostores respondiam por myetherwallet.com e falhavam para outros nomes. Não eram uma cópia do Route 53. Eram uma peça estreita, montada para transformar uma janela de roteamento em fraude dirigida.

Também não há prova pública de invasão ao console AWS, alteração da zona hospedada, transferência do domínio ou comprometimento do código da MyEtherWallet. O atacante ganhou capacidade técnica para receber pacotes, não autoridade legítima sobre endereços, zona ou aplicação.

A resposta DNS levou a uma página de phishing com certificado autoassinado, segundo a Cloudflare. O navegador ainda conseguia recusar a conexão. O dano dependia de atravessar o alerta e realizar uma interação útil ao atacante.

A MyEtherWallet estimou depois cerca de US$ 150 mil em Ether subtraídos. O valor deve permanecer atribuído à organização afetada; as fontes não fornecem auditoria completa de vítimas e transferências.

Cada camada respondeu a uma pergunta menor

BGP ofereceu alcançabilidade. As redes decidiram propagar e preferir. O resolvedor decidiu como tratar a resposta DNS. O navegador avaliou a cadeia do certificado. A aplicação e o usuário permitiram ou recusaram a ação final.

Alcançar um prefixo não autentica um nome. Receber um dado DNS não autentica um site. Um certificado não prova a honestidade do negócio. Uma interface identificada não prova a intenção de uma transferência.

O ataque funcionou ao fazer uma resposta estreita herdar a autoridade da próxima. Essa herança, e não um soberano invisível, foi o centro operacional do incidente.

RPKI e DNSSEC não são substitutos

O RFC 6811 define a validação da origem. Redes que validam uma ROA com limites corretos e rejeitam Invalid podem impedir que um anúncio mais específico de origem diferente chegue ao resolvedor.

RPKI não valida o caminho completo, não obriga todos os operadores e pode ser contornado por tentativas de forjar uma origem autorizada. O desenho de maxLength também importa.

DNSSEC autentica os dados DNS. Os RFCs 4033 e 9364 deixam claro que um resolvedor validador pode rejeitar uma resposta sem a assinatura correta, mesmo quando BGP o levou ao servidor errado. DNSSEC não corrige BGP nem confirma uma transação.

A AWS lançou assinatura DNSSEC para zonas públicas do Route 53 e validação no Route 53 Resolver em dezembro de 2020. A data prova uma capacidade posterior, não a configuração exata da zona em 2018.

O pacote de resposta precisa ser desmontado

A MyEtherWallet anunciou Registry Lock, Registrar Lock, HSTS e preload, CAA, DNSSEC, CDN e proteção DDoS. Cada item protege uma superfície diferente.

Os locks evitam mudanças de domínio, não anúncios BGP. CAA restringe emissores, mas o certificado autoassinado já era rejeitado. HSTS preload elimina a escolha de ignorar o alerta. DNSSEC valida o dado. ROA e ROV limitam a origem. Monitoramento distribuído conecta as pistas.

Uma lista extensa não substitui uma arquitetura de responsabilidade. Para cada controle, a direção deve conhecer condição bloqueada, operador, prova de funcionamento, alerta de falha e estado residual na recuperação.

O limite da autoridade operacional

Running-Code Primacy, de Heng Lu, ajuda a separar registro e efeito. A rota só teve força onde redes em operação a aceitaram. A resposta só teve força onde resolvedores a serviram. O alerta TLS permaneceu uma decisão local.

Distribuição não garante verdade; preserva múltiplos lugares de recusa. Capacidade técnica também não vira autoridade jurídica. Atrair tráfego não transfere o prefixo. Responder por um nome não transfere o domínio. Induzir um clique não cria consentimento.

Conclusão

Não se conhece publicamente o autor, o número completo de resolvedores, a duração de cada cache ou a perda auditada. O ataque não foi global nem prova invasão dos sistemas de controle da AWS.

Ele prova algo mais útil: uma rota temporária pode pegar um nome emprestado e tentar converter essa aparência em resultado irreversível. A arquitetura forte impede que uma prova estreita ganhe autoridade automática na camada seguinte.

Fontes