Certificado válido não resolve um domínio cujo DNS foi sequestrado

Atacantes comprometeram operadores dos registros .gh, .sl e .as, alteraram DNS autoritativo e obtiveram certificados HTTPS não autorizados para propriedades do Google e outras organizações.[18] O Google afirma que seus próprios sistemas não foram invadidos e não vê motivo para concluir que as certificadoras agiram de forma imprópria.[18] O incidente expõe uma dependência que não está dentro do processo da aplicação: o controle do domínio.

O que muda para quem desenvolve

A emissão de certificados normalmente depende de demonstrar controle do domínio, por exemplo com um registro TXT de validação.[18] Quem controla o DNS autoritativo pode satisfazer essa etapa e apontar o site para infraestrutura própria, mesmo sem ser o proprietário legítimo.[18]

Minha análise é que monitorar apenas a disponibilidade do backend deixa uma lacuna. O serviço legítimo pode continuar saudável enquanto visitantes são encaminhados a outro destino. A operação precisa acompanhar tanto o funcionamento da aplicação quanto os elementos que fazem o usuário chegar a ela.

O Google bloqueou certificados de suas propriedades no Chrome por CRLSets e trabalhou com certificadoras na revogação.[18] Também examinou Certificate Transparency para encontrar emissões adicionais associadas ao ataque.[18] Isso oferece um caminho de detecção, mas não transforma a resposta de um navegador em proteção universal.

Como aplicar

Inclua no inventário domínios em uso e estacionados, responsáveis pelo registro, administração DNS e certificados esperados. A recomendação publicada é acompanhar Certificate Transparency para todo o portfólio, inclusive os domínios estacionados.[18]

Proponho criar alertas que comparem novas emissões com alterações autorizadas. Cada aviso deve permitir responder: o domínio é nosso, a certificadora era esperada e existe uma mudança que justifique a emissão? O objetivo não é bloquear automaticamente qualquer renovação, mas reduzir o tempo até investigar uma divergência.

Teste o fluxo de alerta com um evento sintético de emissão não aprovada. Confirme que o responsável recebe o caso e consegue localizar o inventário e o procedimento de resposta. Não é necessário sequestrar um domínio ou obter um certificado indevido para validar o encaminhamento.

A fonte recomenda registros CAA restritivos, incluindo limitações de certificadoras, contas ACME e métodos de validação autorizados.[18] Antes de aplicar restrições, mapeie os fluxos legítimos de emissão e renovação. Uma configuração de segurança que impede renovação sem avisar também cria um problema operacional.

Cuidados e limites

Durante um sequestro ativo do DNS, o atacante controla o próprio meio em que o CAA é publicado e pode contornar sua utilidade.[18] O mecanismo ajuda especialmente a evitar emissões adicionais com validações em cache após a restauração do controle legítimo.[18]

O levantamento pode não ter encontrado todos os domínios afetados, e as intervenções do Chrome não garantem proteção em outros navegadores.[18] Não conclua que HTTPS perdeu utilidade. Conclua que um certificado válido responde a uma parte da confiança técnica, não prova sozinho que a página está sob o controle da organização esperada.

Fonte

[18] Fonte: BleepingComputer