A falha silenciosa de DNS que tornou possíveis sites falsos
Ao visitar um site, seu computador não se conecta a um nome como "example.com". Em vez disso, ele precisa de um IP address. Seu computador envia uma solicitação para um resolver, geralmente seu roteador ou ISP, que então consulta vários servidores DNS para encontrar o IP address correto.
As respostas iniciais de DNS eram vulneráveis porque dependiam de um simples ID de transação de 16 bits para corresponder respostas a solicitações. Embora esse ID ajudasse a organizar as consultas, ele não oferecia prova criptográfica da identidade do remetente. Atacantes podiam inundar um resolver com respostas forjadas, adivinhando um dos 65.536 IDs possíveis, e se uma resposta falsa chegasse antes da legítima, o resolver a aceitaria e armazenaria em cache os dados maliciosos.
Essa falha fundamental tornou-se claramente evidente em 2008 com a descoberta do Kaminsky attack. Dan Kaminsky demonstrou como explorar essa fraqueza visando subdomínios arbitrários inexistentes, permitindo que atacantes envenenassem rapidamente o registro do nameserver autoritativo de um domínio. Isso expôs o risco generalizado de DNS cache poisoning e destacou a necessidade urgente de uma arquitetura de DNS mais segura.
A solução de longo prazo, DNSSEC, já havia sido formulada em 2005. Ela introduziu a autenticação criptográfica, garantindo que cada etapa na cadeia de consulta de DNS — dos servidores raiz aos servidores de domínio individuais — possa verificar a autenticidade da próxima. Esse sistema estabeleceu uma cadeia de confiança, impedindo que atacantes injetassem informações fraudulentas e redirecionassem usuários para sites maliciosos.
A cadeia de confiança termina em uma chave raiz
DNSSEC, a solução de longo prazo para vulnerabilidades de DNS, usa criptografia de chave pública para proteger as consultas. Cada assinante possui uma private key para gerar assinaturas digitais para dados de DNS e uma public key correspondente para verificação. Os resolvers usam essas public keys para confirmar que os dados de DNS não foram alterados em trânsito, garantindo sua autenticidade.
Uma cadeia de confiança se estende da raiz do DNS até domínios individuais. Quando um resolver consulta example.com, ele primeiro consulta os servidores raiz, que atestam os servidores de domínio de nível superior (TLD) .com. Os servidores .com então atestam o próprio servidor DNS de example.com. Cada zona pai assina criptograficamente as public keys de suas zonas filhas, criando um caminho de validação ininterrupto.
A Root Zone Key Signing Key (KSK) é única; não existe autoridade de DNS superior para autenticá-la. Portanto, sua public key deve ser pré-configurada como um trust anchor em todos os resolvers que validam DNSSEC. Quem controlar a metade privada da KSK poderia assinar dados raiz falsos, minando toda a cadeia de confiança do DNS. Essa private key crítica é mantida em um Hardware Security Module altamente seguro, isolado da rede (air-gapped), e só é acessada durante cerimônias de chave rigorosamente controladas e multipartidárias.
Dentro da cerimônia criada para manter uma chave em segredo
Manter o sigilo da chave raiz requer um protocolo de segurança elaborado e multicamadas, executado em uma instalação segura em Culpeper, Virgínia. Este local, operado pela ICANN e pela Public Technical Identifiers (PTI), protege os Hardware Security Modules (HSMs) que geram e armazenam a private key. O acesso à sala da cerimônia envolve vários pontos de verificação de segurança, seguidos por uma gaiola trancada e, em seguida, cofres contendo os próprios HSMs.
O processo de assinatura é uma salvaguarda de várias pessoas. Sete Crypto Officers designados, escolhidos da comunidade global da internet e independentes da ICANN, possuem cada um uma chave de segurança para o seu cofre individual. Para ativar o HSM e realizar uma operação protegida, um mínimo de três Crypto Officers deve estar fisicamente presente e inserir as suas chaves de segurança únicas.
As cerimónias são publicamente observáveis e documentadas, garantindo transparência. Os participantes iniciam um computador a partir de um sistema operativo de leitura apenas confiável, verificando a sua impressão digital criptográfica em voz alta. Assim que as três chaves de segurança são inseridas, um único comando inicia o processo de geração de chaves dentro do HSM isolado (air-gapped). A chave privada nunca deixa este ambiente seguro, exceto como uma cópia de segurança encriptada. O identificador da nova chave, como 38696 para a chave de 2024, é então registado, e o processo termina com todos os participantes a assinarem um guião em papel. Para mais detalhes sobre estes procedimentos, consulte a documentação IANA Root KSK Ceremonies.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
O que muda quando a chave raiz é renovada
As renovações de chaves introduzem uma nova Key Signing Key (KSK), substituindo a antiga como a chave de assinatura ativa para o conjunto de registos DNSKEY da zona raiz. Embora a nova chave seja gerada e certificada com meses de antecedência, a "renovação" real ocorre quando esta se torna a chave de assinatura principal, e o seu componente público deve estar disponível para todos os validadores DNSSEC como uma trust anchor.
A falha na atualização desta trust anchor pode causar interrupções significativas. Um validador com uma chave pública desatualizada será incapaz de validar assinaturas geradas pela nova KSK, rejeitando todas as respostas DNS para domínios assinados. Isto resulta em utilizadores a ver erros SERVFAIL, fazendo com que os websites pareçam inacessíveis mesmo que os seus servidores estejam totalmente operacionais.
Os validadores DNSSEC modernos, como os de ISPs ou serviços públicos como o Cloudflare 1.1.1.1 e o Google 8.8.8.8, utilizam normalmente atualizações automáticas de trust anchor, mitigando a maioria dos riscos. No entanto, firmware de routers mais antigos ou sistemas configurados manualmente podem estar desatualizados, exigindo atualizações explícitas. Se encontrar falhas de DNS coincidentes com uma renovação, atualizar o firmware do seu router ou o software do validador é um bom primeiro passo. Lembre-se, a proteção DNSSEC depende tanto de domínios assinados como de validadores.
Perguntas Frequentes
O que é a chave mestra DNSSEC da internet?
É a parte privada da Key Signing Key (KSK) da zona raiz, usada para assinar as chaves DNSSEC da zona raiz. A sua contraparte pública é uma trust anchor para validadores.
Porque é que o DNS precisa de DNSSEC?
O DNSSEC adiciona assinaturas criptográficas que permitem aos validadores verificar se os dados DNS são autênticos e inalterados, ajudando a evitar que respostas falsificadas sejam aceites.
Pode uma renovação da chave raiz interromper a minha ligação à internet?
Pode interromper o DNS para utilizadores atrás de um validador que não tenha aprendido a nova trust anchor. O validador pode rejeitar respostas, devolvendo frequentemente SERVFAIL.
Como é protegida a chave raiz?
A chave privada é mantida em hardware seguro, e as operações de chave requerem vários participantes autorizados. As cerimónias utilizam instalações controladas, procedimentos documentados e registos públicos.