O certificado que o nomeou: Certificate Transparency como superfície de ataque
O desafio
A Caldera Freight tem uma aplicação que seu time de segurança jura não estar na internet. Nenhum registro DNS público que alguém lembre de ter criado, nenhum link a partir do site, fora de qualquer índice de busca, e o README diz com todas as letras que ela é interna. Pediram que você verifique essa afirmação de fora, usando apenas registros públicos. Existe um caminho, e não é uma wordlist. Toda vez que um certificado é emitido para um nome, esse nome é gravado em um log público, permanente e somente-adição, e ninguém na Caldera pensou nesse log no dia em que juntou dois hosts em um mesmo certificado para economizar uma renovação. Percorra as fontes, descarte os nomes mortos ou que pertencem a outra empresa, e envie o nome de host interno que está de fato vivo na internet.
O que você vai aprender
- Usar o Certificate Transparency como fonte primária para descoberta de subdomínios
- Ler os subject alternative names (SANs) em vez de apenas o common name
- Separar um certificado ativo de um host ativo usando DNS
- Descartar como inalcançáveis os nomes que resolvem para espaço RFC 1918
- Usar a titularidade do bloco de endereços para distinguir seus ativos dos de um fornecedor
Habilidades testadas
Pré-requisitos
- O que são um certificado TLS e um subdomínio
- Leitura de saída do dig e de uma resposta NXDOMAIN
Como funciona
O Certificate Transparency foi criado para pegar certificados emitidos incorretamente, e cumpre esse papel. O efeito colateral é que ele também é um índice permanente, público e somente-adição de nomes de host, alimentado gratuitamente por toda autoridade certificadora, sem forma de remover uma entrada. Se um nome já teve um certificado, esse nome é público, não importa o que diga a zona DNS ou o README.
O hábito que este exercício treina é ler o certificado inteiro. Um certificado tem um sujeito e uma lista de subject alternative names, e clientes modernos ignoram completamente o common name: a lista SAN é o que de fato é validado. O registro de id 9501338 é emitido para status.caldera.example, e enterrado na terceira posição da sua lista SAN está ops-console.caldera.example. Percorra só a coluna CN e o console fica invisível. O changelog explica por que ele está ali: o ticket OPS-4471 renovou o console no mesmo lote da página de status, porque era uma renovação a menos para lembrar.
A descoberta não é a linha de chegada, porque um certificado prova que um nome existiu, não que um host responde. vpn.caldera.example tem o certificado mais recente de todo o conjunto, emitido um dia antes do appliance ser aposentado, e é NXDOMAIN. Essa distância entre certificado e realidade é exatamente o motivo pelo qual a etapa de eliminação importa.
Mais dois filtros fecham a questão. internal.caldera.example resolve para 10.40.7.15, espaço RFC 1918 que não é roteável a partir da internet, então o nome vaza mas o host não. status e uptime apontam por CNAME para 203.0.113.77, endereço que o registro do bloco atribui a um fornecedor de hospedagem, não à Caldera. Alcançável, mas não é ativo da Caldera nem problema dela.
Resta um endereço dentro da própria atribuição da Caldera, respondendo na porta 443 com um formulário de login. O README descreve uma intenção que a infraestrutura nunca fez cumprir.
Erros comuns
- Ler só a linha CN. O console nunca aparece como sujeito, só como o terceiro nome alternativo no certificado de um vizinho.
- Responder vpn.caldera.example. O certificado mais recente do conjunto, e NXDOMAIN. Um certificado sobrevive ao host.
- Responder internal.caldera.example. Ele resolve, mas para espaço RFC 1918 ao qual você não consegue rotear.
- Responder status ou uptime. Ambos apontam para um bloco de endereços de um fornecedor que a Caldera não possui.
- Chutar admin ou portal. Ambos são NXDOMAIN, e o changelog diz que admin nunca foi provisionado.
Como se proteger
Você não consegue despublicar uma entrada do Certificate Transparency, então o controle é planejar em torno do log, não torcer para que ninguém o leia.
- Nunca junte um host interno a um certificado público para economizar uma renovação. Automatize a renovação em vez disso, para que a conveniência deixe de ser um motivo.
- Use uma autoridade certificadora privada para nomes internos, ou emita para um nome que só faz sentido dentro da rede.
- Monitore o Certificate Transparency dos seus próprios domínios e alerte sobre qualquer nome inesperado. O mesmo log que revela isso para um atacante revela para você primeiro.
- Pare de tratar obscuridade como controle. Coloque o console atrás da VPN ou de um proxy com verificação de identidade, para que saber o nome não valha nada.
- Reconcilie o DNS com o inventário de ativos em uma programação regular. Aposente registros e certificados juntos, e lembre-se de que o caso inverso, um registro aposentado com um certificado ativo, é o que engana os defensores.