Além do Contrato Inteligente: Segurança Operacional de Domínio e DNS na Web3

1. O ponto de entrada off-chain: onde a segurança operacional web3 começa

O limite de segurança de um projeto web3 há muito se estende além de seus contratos inteligentes. Chaves de servidor vazadas, frontends adulterados, resolução de DNS sequestrada — isso acontece fora do contrato, mas altera diretamente qual página um usuário carrega e qual transação esse usuário assina. Do lado do usuário, pouco importa se o ataque ocorreu on-chain ou off-chain. O que importa é se ele foi direcionado para o ponto de entrada errado.

As auditorias de contratos são comparativamente maduras. A segurança operacional off-chain não é: há muito tempo faltava uma estrutura compartilhada que as equipes de projeto pudessem aplicar continuamente e que um terceiro pudesse verificar. SEAL Certifications [1], a estrutura aberta de certificação de segurança operacional publicada pela Security Alliance, foi construída exatamente em torno dessa lacuna. Ela divide a segurança operacional em seis módulos: operações multisig, operações de tesouraria, resposta a incidentes, DevOps e infraestrutura, DNS e registrador, e gestão de identidade e conta.

Este artigo segue esse fio até um dos seis módulos — DNS e registrador. Ele está bem na frente do caminho que os usuários percorrem para chegar a um projeto, o que o torna a forma mais direta de um atacante contornar as defesas em nível de contrato. Não tentamos uma avaliação exaustiva de segurança operacional. Adotamos um ponto de vista externo e fizemos uma pergunta mais restrita: quão bem configurados estão os pontos de entrada públicos que os principais projetos apresentam aos seus usuários?

Para responder a isso, desenvolvemos o BlockSec DNS Security Scanner (BDSS) com base no módulo DNS e registrador do SEAL [2], e o executamos contra 100 domínios exclusivos pertencentes ao DefiLlama TVL Top 100 — oito verificações padronizadas cada, 800 verificações no total. Após confirmação manual, as lacunas de linha de base mostraram-se tanto generalizadas quanto concentradas em um pequeno número de controles: apenas 1% da amostra passou em todas as verificações, e mais de nove em cada dez domínios apresentaram pelo menos um sinal de ponto de entrada. 72% não tinham registro CAA e 47% apresentaram defeitos de validação DNSSEC, com a autenticação de e-mail e o bloqueio de domínio expondo deficiências claras próprias.

2. DNS e registrador: o limite de segurança diante do usuário

O DNS transforma um domínio legível por humanos em um endereço de serviço acessível. É o ponto de entrada off-chain por meio do qual os usuários chegam ao site de um projeto, ao frontend de negociação, à documentação, às APIs de negócios e ao e-mail oficial. Uma vez comprometido o caminho de resolução ou o controle do domínio, um usuário pode ser levado a uma página falsificada sem perceber — e cada conexão de carteira, assinatura e transação que se segue perde seu fundamento. DNS e registrador não devem, portanto, ser tratados como configuração comum de infraestrutura; eles pertencem ao limite de segurança operacional do projeto.

Incidentes públicos já tornaram o risco concreto. A Curve Finance sofreu sequestro de DNS em 2022 e novamente em 2025 [3][4]. Em outubro de 2023, um atacante de engenharia social assumiu o controle da conta de registrador da Galxe e redirecionou visitantes para um frontend malicioso; o projeto divulgou que aproximadamente 1.120 usuários foram afetados [5]. Em 2025, o domínio principal da Aerodrome Finance sofreu um ataque de frontend [6]. Em abril de 2026, um atacante obteve controle do domínio da CoW Swap e direcionou usuários para uma página de phishing, com perdas estimadas em cerca de US$ 1,2 milhão [7]. O sequestro de rota BGP da cBridge, anterior a esses casos, ilustra outro ponto: os usuários nem sempre podem confiar em um alerta do navegador para saber que o ponto de entrada saiu do curso [8]. Em cada um desses casos, o contrato on-chain não necessariamente estava quebrado, mas os fundos dos usuários ainda estavam em risco porque o caminho de acesso havia sido perdido.

As causas diferem, mas se reduzem a quatro caminhos de ataque que incidem diretamente sobre o ponto de entrada do usuário. Primeiro, um atacante altera registros de DNS ou o caminho de resolução e direciona visitantes para um frontend malicioso. Segundo, os controles de emissão de certificados são contornados ou mal configurados, permitindo que um site falsificado obtenha um certificado TLS confiável no navegador. Terceiro, uma conta de registrador ou o controle do domínio é assumido, permitindo a transferência do domínio ou alterações em registros críticos, como NS. Quarto, um atacante se apresenta como a marca ou o e-mail do projeto para atrair usuários a uma página de phishing. Os quatro podem terminar da mesma forma: o usuário chega à interface errada e é induzido a concluir a assinatura, aprovação ou transação errada.

O ponto subjacente é este: um ponto de entrada do usuário não é uma página web isolada, mas uma cadeia de confiança composta pelo controle do domínio, resolução de DNS, certificados TLS e comunicação oficial. Mesmo com um contrato on-chain impecável, a falha de um único elo permite que um atacante use o próprio domínio ou marca do projeto para guiar os usuários à página errada e ao fluxo de transação errado. Para uma equipe de projeto, o objetivo não é corrigir uma configuração isoladamente, mas garantir que o domínio não possa ser transferido sem autorização, que a resolução não possa ser silenciosamente alterada, que a emissão de certificados seja adequadamente restringida e que o e-mail oficial seja difícil de imitar. O scan externo que se segue cobre a parte dessa cadeia observável a partir da internet pública.

3. BDSS: design e escopo

Para transformar esses riscos de ponto de entrada em trabalho que uma equipe possa efetivamente executar, construímos o BDSS em torno dos controles observáveis externamente no módulo DNS e registrador do SEAL [2]. Ele não pretende substituir a revisão interna de um projeto. Estabelece uma linha de base para expor lacunas de configuração pública sem tocar em nenhum material operacional sensível.

O módulo DNS e registrador do SEAL [2] estabelece uma estrutura de avaliação completa, cobrindo tanto controles técnicos — resolução, certificados, e-mail, controle de domínio — quanto requisitos operacionais como gestão de ativos de domínio, controle de acesso de contas, gestão de mudanças, monitoramento e alertas, e resposta a incidentes.

O BDSS restringe isso aos controles que podem ser observados e verificados externamente, de modo que sinais de risco de configuração pública em resolução, certificados, e-mail e no lado do registrador possam ser identificados em escala. Ele abrange oito verificações padronizadas.

O BDSS não equivale a uma certificação de segurança completa do DNS de um projeto. Controles que não podem ser verificados a partir da internet pública — bloqueio de registro, aprovação de mudanças, procedimentos de recuperação — ainda exigem revisão em relação à documentação e aos processos próprios do projeto.

4. Resultados do scan externo no DefiLlama Top 100

A avaliação foi concluída em 17 de agosto de 2026, usando o DefiLlama TVL Top 100 daquela data. Os domínios principais foram identificados a partir dos pontos de entrada públicos apresentados aos usuários. Candidatos duplicados, sites não oficiais e domínios cujo propósito não pôde ser determinado foram excluídos após confirmação manual, restando 100 domínios exclusivos. Cada um foi submetido às oito verificações padronizadas em relação à linha de base de risco do ponto de entrada do usuário. Os resultados descrevem apenas o estado de configuração observável a partir da internet pública; eles não substituem uma avaliação dos processos internos ou uma certificação formal. Cada verificação resulta em um dos três estados. PASS significa que a configuração visível publicamente atendeu ao critério observável externamente que a verificação individual implementa, conforme derivado do módulo DNS e registrador do SEAL. WARN marca sinais que merecem atenção — um certificado ou domínio próximo do vencimento, um grande número de CAs autorizados via CAA, um TTL excessivamente longo. FAIL significa que um requisito explícito de um controle SEAL não foi atendido (por exemplo, DMARC não configurado como p=reject), ou que a implementação de segurança correspondente não foi satisfeita (por exemplo, mais de dez consultas DNS de SPF).

4.1 Resultados gerais

O scan cobriu 100 domínios, cada um sujeito às oito verificações padronizadas, produzindo 800 resultados: 232 FAIL e 119 WARN. Contando por domínio, 86 apresentaram pelo menos um FAIL, 13 não tiveram FAIL, mas tiveram pelo menos um WARN, e apenas 1 passou em todas as verificações. Entre os pontos de entrada públicos observados, em outras palavras, a cobertura total dos controles de linha de base de segurança operacional de DNS continua sendo a exceção.

Por tipo de verificação, os resultados FAIL concentram-se em três áreas — CAA, DNSSEC e autenticação de e-mail — enquanto os resultados WARN aparecem com mais frequência no escopo de autorização do CAA e no status de vencimento do domínio. A tabela abaixo apresenta a distribuição de PASS, WARN e FAIL para cada verificação, juntamente com a principal fonte de cada resultado.

4.2 Principais lacunas de configuração

Em conjunto, a linha de base de configuração pública de DNS entre os principais projetos permanece insuficiente, e as lacunas não se concentram em nenhum controle técnico isolado. A ausência de CAA, cadeias de confiança DNSSEC incompletas, política de autenticação de e-mail permissiva e proteções do lado do registrador que ainda exigem verificação afetam, respectivamente, a emissão de certificados, a confiabilidade da resolução, a comunicação de marca e o controle do domínio. Juntas, elas constituem as condições nas quais um usuário implicitamente confia ao chegar a um ponto de entrada oficial. Seguem quatro lacunas representativas.

1. As restrições de emissão via CAA estão amplamente ausentes: 72 domínios não tinham CAA configurado. Um registro CAA limita quais CAs podem emitir certificados TLS para um domínio [9]. Sua ausência não entrega um certificado a um atacante automaticamente, mas significa que o projeto não estabeleceu nenhum limite adicional de emissão por meio do DNS. Se a validação de domínio ou um plano de controle relacionado for subvertido, o conjunto de CAs capazes de aceitar uma solicitação de certificado torna-se muito mais difícil de conter. Para frontends web3, o CAA importa principalmente em cenários de ataque compostos: um atacante que interfere simultaneamente na validação de domínio, na resolução de DNS ou no encaminhamento de tráfego não enfrenta nenhuma restrição adicional de escopo de CA, o que aumenta a chance de que um frontend falsificado consiga apresentar um certificado confiável no navegador.

2. As cadeias de confiança DNSSEC estão incompletas: 47 domínios falharam na validação. As falhas apareceram principalmente como uma DNSKEY ausente (34 domínios) ou um DS de zona pai ausente (40 domínios), com sobreposição entre os dois. Sem esses registros, um resolvedor validador externo não consegue estabelecer uma cadeia de confiança DNSSEC completa [10]. O DNSSEC não impedirá a tomada de conta de registrador ou a adulteração do código do frontend, mas ajuda a verificar se um resultado de resolução foi forjado ou envenenado por cache. Para protocolos que pedem aos usuários que conectem uma carteira e assinem transações, a ausência dessa camada de verificação significa que um usuário pode ser direcionado ao endereço, servidor ou contrato errado enquanto a interface parece essencialmente inalterada.

3. A política de autenticação de e-mail é fraca: 38 verificações falharam. Alguns domínios apresentaram vários problemas simultaneamente: 35 não elevaram a política DMARC para p=reject [11], 6 não tinham endereço de relatório agregado rua configurado, e 4 tinham uma cadeia de autorização SPF excessivamente longa [12]. Uma política DMARC permissiva debilita a aplicação contra e-mails falsificados, a ausência de rua prejudica o monitoramento contínuo, e exceder o limite de consultas SPF pode causar erros de validação. Como o e-mail dos projetos rotineiramente carrega alertas de segurança, instruções de airdrop e avisos de migração, essas lacunas tornam o e-mail falsificado uma rampa de entrada mais eficaz para um frontend falsificado ou fluxo de phishing.

4. As proteções de controle de domínio ainda exigem verificação: 3 domínios não apresentaram bloqueio de transferência, e o status de bloqueio de registro foi indeterminado para outros 90. No status RDAP público, apenas 7 domínios exibiram um conjunto razoavelmente completo de sinais de bloqueio; para a maioria dos demais, apenas o bloqueio de transferência pôde ser confirmado, e se o bloqueio de registro está habilitado deve ser verificado por meio do painel do registrador ou da documentação do registro. O bloqueio de transferência é a medida básica contra transferência não autorizada; o bloqueio de registro é mais adequado para domínios de alto valor que carregam o frontend principal, a documentação e as APIs. A gestão de renovação também influencia a continuidade do controle: o scan encontrou 2 certificados TLS dentro da janela de alerta de 30 dias e 10 domínios dentro da janela de lembrete de vencimento de 90 dias. Para domínios que carregam pontos de entrada críticos, controles como renovação automática, lembretes escalonados e proprietários primários e de backup designados podem impedir que um certificado ou domínio próximo do vencimento se transforme em uma interrupção de serviço ou em uma perda de controle do ponto de entrada.

5. O que os resultados dizem sobre a segurança de DNS web3 atualmente

O scan mostra que a linha de base de configuração pública de DNS nos principais projetos DeFi permanece inadequadamente coberta. De 100 domínios, apenas 1 passou em todas as verificações e 86 apresentaram pelo menos um FAIL. As principais lacunas envolvem CAA, DNSSEC, autenticação de e-mail e bloqueios de domínio — afetando as restrições de emissão de certificados, a validação de resolução, a comunicação de marca e o controle do próprio domínio.

Essas lacunas não se limitam à camada de resolução ou a um único controle técnico. Elas estão distribuídas entre domínio, resolução, certificado e e-mail — vários elos distintos no caminho de entrada do usuário. A cobertura reduzida de CAA e DNSSEC, em particular, mostra que esses controles de ponto de entrada ainda não estão implantados de forma consistente na amostra — mesmo que o controle do domínio, os certificados e o caminho de resolução estejam diretamente na frente dos usuários. Nenhum desses sinais externos indica que um projeto tenha sido comprometido. Mas quando um atacante interfere na resolução de DNS, obtém um certificado válido por meio de um processo irregular, assume o controle de uma conta de registrador ou se passa por e-mail oficial, controles ausentes debilitam as defesas já existentes e facilitam que usuários sejam levados a uma página falsificada ou a um fluxo de phishing. A gestão inadequada de renovação de certificados e domínios também pode interromper os pontos de entrada oficiais.

O BDSS pode identificar lacunas de configuração a partir da internet pública e estabelecer uma linha de base de segurança externa comparável. Não pode, no entanto, demonstrar adequadamente controles operacionais como bloqueio de registro, MFA de conta de registrador, confirmação de mudanças críticas, monitoramento e alertas, ou resposta a incidentes — nenhum desses pode ser estabelecido apenas a partir de registros públicos. Sinais públicos, portanto, são adequados para descrever o estado do setor e identificar áreas que precisam de verificação adicional, mas não devem ser interpretados como um julgamento final sobre a capacidade operacional real de qualquer projeto. Trabalhando dentro desse limite, o scan externo e o SEAL Certifications se complementam: o primeiro torna as lacunas de configuração pública continuamente observáveis e comparáveis, enquanto o segundo se baseia em documentação operacional e processos reais para verificar controles internos sobre ativos de domínio, controle de acesso do registrador, gestão de mudanças e resposta a incidentes. Como auditor acreditado do primeiro grupo de SEAL Certifications — e o único na Ásia — a BlockSec pode ajudar os projetos a avaliar sua segurança operacional de forma sistemática dentro dessa estrutura.

Referências

[1] Security Alliance. SEAL Certifications Overview. https://frameworks.securityalliance.org/certs/overview/

[2] Security Alliance. SEAL Certification Framework: DNS Registrar. https://frameworks.securityalliance.org/certs/sfc-dns-registrar/

[3] Curve Finance. 2022 DNS incident statement. https://x.com/CurveFinance/status/1557505570533478403

[4] Curve Finance. 2025 domain incident statement. https://news.curve.finance/curve-domain-incident/

[5] Galxe. October 6th DNS Security Incident Statement & Guide. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide

[6] Aerodrome Finance. Domain incident statement. https://x.com/AerodromeFi/status/1992097133869375783

[7] CoW Swap. Domain incident statement. https://x.com/CoWSwap/status/2044924940886163780

[8] Celer Network. cBridge routing incident statement. https://x.com/CelerNetwork/status/1560022871564775424

[9] Hallam-Baker and Stradling. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. https://www.rfc-editor.org/rfc/rfc8659.html

[10] Arends et al. RFC 4033: DNS Security Introduction and Requirements. https://www.rfc-editor.org/rfc/rfc4033.html

[11] Kucherawy and Zwicky. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489.html

[12] Kitterman. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. https://www.rfc-editor.org/rfc/rfc7208.html