Auditoria de Logs de Transparência de Certificados TLS

Quando Usar

• Monitorar domínios próprios para emissão de certificados não autorizada ou inesperada por Autoridades Certificadoras desconhecidas
• Descobrir subdomínios e serviços ocultos através de certificados registrados em logs públicos de CT
• Detectar infraestrutura de phishing que utiliza certificados de domínios semelhantes (typosquatting, ataques homógrafos)
• Auditar a conformidade de Autoridades Certificadoras verificando se todos os certificados emitidos aparecem nos logs de CT, conforme exigido pelas políticas dos navegadores
• Incorporar monitoramento contínuo de certificados em um pipeline de operações de segurança com alertas para novas emissões

Não use para atacar ou interromper Autoridades Certificadoras, para raspar logs de CT violando limites de taxa ou termos de serviço, ou como o único método de enumeração de subdomínios sem corroborar os resultados através de verificação de DNS.

Pré-requisitos

• Python 3.10+ com as bibliotecas requests, cryptography e pyOpenSSL instaladas
• Acesso à rede ao crt.sh (HTTPS) e servidores públicos de logs de CT
• Uma lista de domínios para monitorar (domínios próprios, variações de marca, candidatos a typosquatting)
• Credenciais SMTP ou URL de webhook para alertas sobre novas descobertas de certificados
• Compreensão básica da estrutura de certificados X.509 e validação de cadeia de certificados TLS

Fluxo de Trabalho

Etapa 1: Inventário de Domínios e Linha de Base

Construa o inventário inicial de certificados para os domínios monitorados:

• Defina o escopo de monitoramento: Liste todos os domínios raiz próprios, nomes de marca registrados e subsidiárias conhecidas. Inclua padrões curinga (%.example.com) para cobertura abrangente de subdomínios.
• Consulte o crt.sh para certificados históricos: Use a API JSON do crt.sh para recuperar todos os certificados conhecidos para cada domínio. O endpoint da API https://crt.sh/?q=%.example.com&output=json retorna certificados que correspondem ao padrão curinga com campos incluindo issuer_ca_id, issuer_name, common_name, name_value, not_before, not_after e serial_number.
• Construa o banco de dados de linha de base: Armazene o conjunto inicial de certificados em um banco de dados SQLite local com colunas para ID do certificado, domínio, emissor, datas de validade, SANs (Subject Alternative Names) e carimbo de data/hora da primeira visualização. Essa linha de base evita alertas sobre certificados já conhecidos.
• Identifique CAs autorizadas: A partir da linha de base, extraia o conjunto de Autoridades Certificadoras que emitiram legitimamente certificados para seus domínios. Qualquer emissão futura de uma CA que não esteja neste conjunto aciona um alerta de alta prioridade.
• Mapeie subdomínios: Extraia todos os subdomínios únicos do campo name_value em todos os certificados para construir um inventário inicial de subdomínios.

Etapa 2: Monitoramento Contínuo de Logs de CT

Configure o monitoramento contínuo para novas emissões de certificados:

• Consulte o crt.sh periodicamente: Consulte a API do crt.sh em intervalos regulares (a cada 15-60 minutos) para novos certificados. Use o parâmetro exclude=expired para focar em certificados atualmente válidos. Compare os resultados com o banco de dados de linha de base para identificar novas entradas.
• Analise os detalhes do certificado: Para cada novo certificado, extraia a lista completa de SANs, a cadeia do emissor, o período de validade, o tipo e o tamanho da chave, os detalhes do SCT (Signed Certificate Timestamp) do log de CT e a impressão digital do certificado (SHA-256).
• Detecte pré-certificados: Os logs de CT incluem pré-certificados (certificados "envenenados" submetidos antes da emissão final). Monitore-os como alertas antecipados, pois indicam que um certificado está prestes a ser emitido, mas pode ainda não estar ativo.
• Monitore os Signed Tree Heads (STH) dos logs de CT: Para monitoramento avançado, consulte diretamente os servidores de logs de CT para buscar o STH mais recente e verificar provas de consistência entre cabeças de árvore consecutivas. Uma inconsistência indica comportamento incorreto do log (ataque de visão dividida).
• Consciência sobre limites de taxa: Respeite os limites de taxa do crt.sh espaçando as consultas e armazenando respostas em cache. Implemente backoff exponencial em respostas HTTP 429. Para monitoramento de alto volume, considere consultar diretamente a interface PostgreSQL do crt.sh em crt.sh:5432.
• Alternativa de feed Atom/RSS: Assine o feed Atom do crt.sh para um monitoramento mais leve: https://crt.sh/atom?q=%25.example.com fornece notificação em tempo real de novas entradas de log.

Etapa 3: Descoberta de Subdomínios via Dados de CT

Extraia e valide subdomínios encontrados em dados de transparência de certificados:

• Expansão de curinga: Certificados com SANs curinga (*.dev.example.com) revelam a existência de subdomínios que podem não estar nos arquivos de zona DNS. Registre o domínio pai como um alvo para enumeração adicional.

…