Falsificação de registros de DNS através de violações de atualizações dinâmicas de DNS via DHCP
Resumo executivo
Os pesquisadores da Akamai descobriram um novo conjunto de ataques contra domínios do Active Directory que usam servidores DHCP (Dynamic Host Configuration Protocol ou protocolo de configuração dinâmica de hosts) da Microsoft.
Esses ataques podem permitir que invasores falsifiquem registros DNS confidenciais, resultando em consequências variáveis, desde o roubo de credenciais até o comprometimento total do domínio do Active Directory. Os ataques não exigem credenciais e funcionam com a configuração padrão do servidor DHCP da Microsoft.
O número de organizações impactadas pode ser significativo. O servidor DHCP da Microsoft é muito popular. Foi observado que ele está sendo executado em 40% das redes monitoradas pela Akamai.
Relatamos nossas descobertas à Microsoft, mas uma correção não está planejada.
Nessa publicação do blog, detalhamos as práticas recomendadas para configurar o servidor DHCP da Microsoft de forma que possamos mitigar esses ataques e compartilhamos uma ferramenta para ser usada por administradores de sistema e equipes azuis para detectar configurações arriscadas.
Em uma futura publicação no blog, vamos compartilhar detalhes técnicos sobre a implementação desses ataques do ponto de vista de um invasor.
Introdução
A capacidade de falsificar registros DNS é muito atraente para os invasores, pois pode levar a consequências devastadoras, incluindo exposição de dados confidenciais, comprometimento de credenciais e até execução remota de código.
Nessa publicação do blog, examinamos uma superfície de ataque no DNS que raramente foi pesquisada e é exposta por um recurso de DHCP aparentemente inofensivo. Ao usá-la, encontramos várias maneiras diferentes de os invasores falsificar registros DNS em servidores DNS da Microsoft, incluindo uma substituição de registro DNS arbitrário não autenticado.
Além dos fluxos de ataque, também descrevemos em detalhes o funcionamento interno de um servidor DHCP da Microsoft, sua interação com DNS e Active Directory e como proteger adequadamente essas interfaces. Embora existam online muitos recursos dispersos (e imprecisos!) sobre DHCP, acreditamos que esta publicação do blog seja um recurso preciso e abrangente sobre o assunto, onde todas as informações críticas para os defensores são apresentadas em um só lugar.
DNS e Active Directory
Nossa jornada começa com o Active Directory (AD). O AD depende muito do DNS para sua operação. Cada domínio precisa de um servidor DNS que hospede uma zona DNS especial chamada zona DNS integrada do Active Directory (ADIDNS) (Figura 1). Essa zona é usada para hospedar registros DNS para todas as máquinas que ingressaram no domínio e os diferentes serviços no AD.
Fig. 1: O ADIDNS padrão
Os registros em zonas ADI são gerenciados usando um recurso DNS chamado Atualizações dinâmicas. Esse recurso permite que cada cliente seja responsável por seu próprio registro. Quando eles precisam criar ou modificar seu registro DNS, eles enviam uma solicitação de DNS especial que inclui os dados que precisam ser modificados no servidor (Figura 2). Quando o servidor DNS recebe essa solicitação, ele modifica os registros do cliente de acordo.
Fig. 2: Um exemplo de conteúdo atualizado de DNS
Um dos recursos importantes das atualizações dinâmicas de DNS são as Atualizações seguras, que foram concebidas para controlar quem pode modificar cada registro DNS na zona. Sem atualizações seguras, o servidor DNS obedece cegamente a qualquer solicitação de atualização, o que permite que os invasores substituam facilmente os registros existentes. Com esse recurso, somente atualizações seguras são aceitas pelo servidor DNS para zonas ADI por padrão (Figura 3).
Fig. 3: Configurações padrão de atualizações dinâmicas de DNS
Quando as atualizações seguras são usadas, todas as solicitações de atualização recebidas pelo servidor são autenticadas e autorizadas — em zonas ADI, isso é realizado usando Kerberos. Quando uma atualização é enviada ao servidor, ela inclui uma permissão Kerberos que é usada para autenticar o usuário (Figura 4). Para obter mais informações sobre o processo de autenticação Kerberos sobre DNS, consulte a pesquisa de Dirk-Jan Mollema sobre sobre retransmissão Kerberos via DNS.
Fig. 4: Uma permissão Kerberos dentro de uma atualização de DNS
Cada registro DNS é protegido por uma lista de controle de acesso (ACL) que determina os direitos de acesso de cada principal. Esses direitos de acesso são determinados quando o registro é criado inicialmente: Quando um cliente cria um registro DNS enviando uma Atualização dinâmica de DNS, a conta de máquina que criou o registro DNS é atribuída automaticamente como o proprietário do registro e recebe permissões sobre ele. Normalmente, cada cliente DNS usa seu próprio tíquete de conta de máquina para executar atualizações de DNS. Para autorizar uma solicitação de atualização, o servidor DNS verifica a ACL do registro em relação ao principal autenticado.
Na Figura 5, podemos ver a ACL do registro DNS do host “PC.aka.test”. Esse registro foi criado pela conta do computador, portanto, ele tem permissões para modificá-lo.
Fig. 5: Padrão ACL de registro DNS
Outros principais (exceto alguns grupos de alta segurança integrados) não devem ter permissões sobre o registro. Quando um principal diferente tenta modificar um registro DNS que não possui ou tem permissões, o servidor recusa a atualização.
As zonas ADIDNS podem ser muito interessantes para os invasores. Pesquisa anterior de Kevin Robertson do NETSPI destacou alguns ataques interessantes nessas zonas DNS. Queríamos expandir essa superfície de ataque, então começamos a analisar recursos adicionais relacionados, o que nos levou a uma superfície interessante: atualizações dinâmicas de DNS via DHCP.
Atualizações dinâmicas de DNS via DHCP
DHCP é um protocolo de gerenciamento de rede usado para atribuir automaticamente endereços IP e outras opções de rede aos clientes. Quando um cliente ingressa em uma nova rede, ele tentará alcançar um servidor DHCP enviando uma mensagem de transmissão, solicitando configurações de rede. Quando um servidor DHCP recebe essa solicitação, ele responderá ao cliente com um endereço IP atribuído.
O DHCP é um protocolo muito comum usado na maioria das redes corporativas, e o servidor DHCP da Microsoft, em particular, é uma opção muito popular — vimos o servidor DHCP da Microsoft sendo executado em 40% das redes de data center que monitoramos.
Embora os clientes Windows modernos (Windows 2000 e superior) normalmente criem seus próprios registros enviando atualizações dinâmicas de DNS, isso nem sempre acontece. Os registros DNS também podem ser criados usando um recurso DHCP chamado atualizações dinâmicas de DNS via DHCP. O objetivo deste recurso é permitir que um servidor DHCP cadastre registros DNS em nome de seus clientes. Sempre que um cliente recebe um endereço IP pelo servidor DHCP, ele pode entrar em contato com o servidor DNS e atualizar o registro DNS do cliente. Para executar essas atualizações, o servidor DHCP usa (advinha?) atualizações dinâmicas de DNS.
A semelhança do nome pode ser bastante confusa, então vamos esclarecer:
Recurso |
Protocolo |
Finalidade |
|---|---|---|
Atualizações dinâmicas de DNS |
DNS |
Permite que clientes DNS criem ou modifiquem registros DNS no servidor DNS |
Atualizações dinâmicas de DNS via DHCP |
DHCP |
Permite que o servidor DHCP crie ou modifique registros DNS em nome de seus clientes e as atualizações são realizadas usando atualizações dinâmicas de DNS |
O processo de atualização dinâmica de DNS via DHCP é mostrado na Figura 6.
Fig. 6: Processo de atualização dinâmica de DNS DHCP
O cliente DHCP obtém um endereço IP do servidor DHCP e o informa sobre seu FQDN.
O servidor DHCP envia uma solicitação de atualização dinâmica ao servidor DNS.
O servidor DNS valida a solicitação, cria um registro relevante e informa ao servidor DHCP o resultado em uma resposta de Atualização dinâmica.
Observe que, mesmo quando o recurso Atualizações dinâmicas de DNS via DHCP está ativado, a configuração padrão exige que o cliente especifique explicitamente que um registro DNS deve ser criado em seu nome (Figura 7).
Fig. 7: Configuração padrão de atualizações dinâmicas de DNS DHCP
Para especificar isso, o cliente precisa enviar uma opção DHCP dedicada. Opções DHCP (Figura 8) são campos adicionais que podem ser adicionados a um pacote DHCP e são usados pelo cliente e pelo servidor para trocar informações.
Fig. 8: Um exemplo de opções DHCP
Para a nossa causa, o cliente envia a opção FQDN, especificada em RFC 4702. Essa opção permite que o cliente DHCP informe o servidor de seu nome de domínio totalmente qualificado (FQDN) e especifique se ele deve cadastrar um registro DNS em nome do cliente. Para fazer isso, o cliente pode usar o Server Flag, que faz parte da opção FQDN. Configurá-lo como 1 informa ao servidor que ele deve criar um registro com base no FQDN fornecido (Figura 9).
Fig. 9: Solicitação de DHCP com opção FQDN
Após receber essa solicitação, o servidor DHCP envia uma Atualização dinâmica de DNS e cria o registro solicitado (Figura 10).
Fig. 10: Zona DNS ADI com nosso novo registro
Esse recurso é útil, mas não é comumente usado hoje (como afirmado, a maioria dos clientes Windows modernos simplesmente cria seus próprios registros). Apesar disso, os servidores DHCP da Microsoft têm este recurso ativado por padrão, o que significa que o servidor DHCP cadastrará um registro DNS para qualquer cliente que o solicitar.
Observe que atualizações dinâmicas de DNS via DHCP não precisam de autenticação pelo cliente DHCP. Qualquer pessoa na rede pode alugar um IP de um servidor DHCP, de forma que um invasor possa usar essencialmente o servidor DHCP para se autenticar no servidor DNS em nome dele mesmo. Isso concede ao invasor acesso à zona ADIDNS sem nenhuma credencial.
A Microsoft parece estar ciente dos possíveis riscos que esse recurso representa e reconhece alguns deles, mas essa superfície de ataque ainda é desconhecida principalmente para invasores e defensores
As seções a seguir detalham os ataques que podem ser realizados abusando das atualizações dinâmicas de DNS via DHCP.
Falsificação de DNS via DHCP
Os ataques de falsificação de ADIDNS descritos anteriormente transformaram o ADIDNS em arma para melhorar o clássico ataque de falsificação de LLMNR/NBNS . Depois de identificar tentativas malsucedidas de resolução de nomes (“hosts mortos”), um invasor registraria o nome na zona ADI, fazendo tentativas futuras de resolução de nomes apontarem para a máquina do invasor.
Esse ataque pode ter muito impacto, mas teve um pré-requisito importante: credenciais de domínio válidas. Ao utilizar o servidor DHCP, podemos ignorar este requisito e operar sem quaisquer credenciais. Podemos simplesmente enviar uma atualização dinâmica de DNS via DHCP para qualquer FQDN que não exista na zona ADI, e o servidor DHCP irá criá-la para nós. Chamando essa variação do ataque de falsificação de DNS via DHCP. Essa técnica também foi coberta em uma publicação do blog por Hans Lakhan da TrustedSec.
Quais nomes DNS poderíamos usar para esse ataque? Novamente desenhando da pesquisa de Robertson, alguns candidatos óbvios não funcionariam.
O notório nome de host WPAD seria bloqueado pela lista de bloqueio de consulta global (GQBL) no servidor DNS.
O registro curinga (“*”) não pode ser criado através de atualizações dinâmicas de DNS, portanto não pode ser abusado neste cenário.
Sem esses dois candidatos, ficamos com a opção de identificar hosts inativos que são específicos da rede. Podemos identificá-los através de sniffing da rede para transmissões de resolução de nomes por LLMNR (Link-local Multicast Name Resolution) ou NBT-NS (NetBIOS Name Service). Depois de identificarmos um possível host morto, podemos criar um registro DNS correspondente enviando uma Atualização dinâmica de DNS via DHCP (Figura 11).
Fig. 11: Usar a Atualização dinâmica de DNS DHCP para falsificar nomes de host inativos
Um host na rede tenta resolver o nome “PC.aka.test” e envia ao servidor DNS uma consulta.
“PC.aka.test” é desconhecido para o servidor DNS, por isso responde com “Nome não existe”.
Em seguida, o host envia um multicast LLMNR para tentar localizar o “PC.aka.test” em sua LAN.
O invasor identifica essa tentativa e solicita um aluguel de IP do servidor DHCP com “PC.aka.test” como FQDN.
O servidor envia uma solicitação de atualização dinâmica ao servidor DNS e o registro é criado.
Agora, da próxima vez que qualquer host na rede tentar resolver “PC.aka.test”, eles serão redirecionados ao invasor. Tudo o que o invasor precisa fazer agora é disparar ntlmrelayx.py e aguardar as tentativas de autenticação.
Essa abordagem é melhor do que o método de falsificação de LLMNR/NBNS padrão e a variação de falsificação de ADIDNS.
A falsificação de LLMNR/NBNS clássica não requer autenticação, mas é limitada às vítimas na mesma LAN (uma vez que LLMNR/NBNS baseiam-se em transmissão).
A falsificação de ADIDNS nos permitiu direcionar as vítimas para fora da LAN (como o DNS funciona em sub-redes), mas exigiu um usuário autenticado.
Com as atualizações dinâmicas de DNS via DHCP, obtemos o melhor de dois mundos: o ataque funciona em vítimas fora da LAN e não requer autenticação.
Isso é muito legal, mas ainda podemos melhorar.
Substituindo registros existentes
Criar registros DNS não existentes é interessante, mas isso nos levou a pensar em outra opção: O que acontece se tentarmos criar um registro para um nome de host que já existe? Poderíamos, possivelmente, substituí-los de alguma forma? De forma ideal, não deveria ser possível, certo? Bem...
Identificamos casos em que pode ser possível que invasores não autenticados substituam os registros existentes. Chamamos essa técnica de substituição de DHCP DNS. Antes de entrarmos nesses casos, vamos discutir mais alguns detalhes sobre o processo de atualizações dinâmicas via DHCP.
Tipos de registro DNS e seus proprietários
No contexto de ataques DNS via DHCP, há uma distinção importante a ser feita entre dois tipos de registros DNS (Figura 12). Usaremos os seguintes termos a partir de agora:
Registros do cliente: registros que foram criados diretamente por clientes Windows
Registros gerenciados: registros que foram criados pelo servidor DHCP em nome dos clientes
Fig. 12: Tipos de registro DNS
A diferença crucial entre esses clientes é o seu proprietário. Conforme descrito mais cedo nessa publicação, quando uma atualização de DNS é realizada, um registro de cliente é criado e o principal que enviou a solicitação de atualização é atribuído como o proprietário do registro. Para clientes Windows normais, este principal é a conta de máquina do cliente.
Pode-se esperar que os registros gerenciados também sejam de propriedade de seu cliente solicitante, mas esse não é o caso. Quando o servidor DHCP envia atualizações de DNS em nome dos clientes, ele também se autentica usando sua própria conta de máquina, que se torna o proprietário do registro.
Podemos ver essa diferença na Figura 12. PC2 é um registro de cliente de propriedade do cliente e PC1 é um registro gerenciado de propriedade do servidor DHCP.
As listas de controle de acesso limitam as substituições de DNS via DHCP
Quando tentamos executar uma atualização dinâmica de DNS via DHCP em um registro existente, neste caso, o registro “PC.aka.test”, nós falhamos. Um comportamento interessante é observado: O servidor de DHCP, na verdade, envia uma atualização de DNS com nosso FQDN fornecido, mas a atualização é então recusada pelo servidor (Figura 13).
Fig. 13: Atualização de DNS DHCP recusada pelo servidor
Isso acontece porque o servidor DHCP não está autorizado a modificar o registro.
PC.aka.test é um registro de cliente , de propriedade do PC$ principal. Quando o servidor DHCP envia a atualização de DNS, ele autentica usando sua própria conta de máquina, DHCP$. Como essa conta não tem permissões sobre o registro, a atualização é recusada (Figura 14).
Fig. 14: Falhar na substituição do registro DNS
Para resumir: é possível que os invasores usem o servidor DHCP para enviar atualizações arbitrárias de DNS, mas os registros de DNS devem estar seguros contra substituições devido às suas ACLs.
Agora que entendemos o mecanismo que deve impedir substituições, vamos ver como eles ainda podem ser executados.
Substituição de registro gerenciado
Embora as substituições de registros de clientes existentes não funcionem por causa de suas ACLs restritivas, as substituições de registros gerenciados (criados por DHCP) funcionam, pois a máquina de autenticação também é o proprietário do registro (Figura 15).
Isso é possível porque um servidor DHCP não verifica a propriedade do registro DNS e envia uma atualização DNS para qualquer FQDN solicitado.
Fig. 15: Substituição de DNS DHCP de registros pertencentes ao servidor DHCP
Como podemos ver, o servidor DHCP executa uma atualização usando a mesma conta que possui o registro, que é o seu próprio, para que a atualização seja bem-sucedida.
Vamos ver um exemplo. Inicializamos um servidor Ubuntu, que não faz parte do domínio e, portanto, não pode registrar seu próprio registro DNS. Em vez disso, ele solicita que o servidor DHCP faça isso em seu nome (Figura 16).
Fig. 16: O servidor DHCP grava um registro DNS em nome do servidor Ubuntu
Este registro é de propriedade da conta de máquina do servidor DHCP. Agora, em nossa máquina de ataque, solicitamos o mesmo FQDN do servidor DHCP no processo de aluguel. Verificamos a zona DNS e vemos que nossa substituição foi bem-sucedida, e o registro agora aponta para o IP que acabou de ser alugado para nós (Figura 17).
Fig. 17: Registro DNS do servidor Ubuntu substituído
Esse ataque é aceitável, mas seu impacto é bem limitado, pois afeta apenas os registros gerenciados. Como mencionamos anteriormente, esses registros são muito menos comuns que os registros de clientes, que não são afetados por esse ataque. Apesar disso, os registros gerenciados ainda podem ser encontrados em alguns casos em que o cliente não consegue registrar seu próprio registro, como:
Clientes não Windows
Clientes Windows legados
Clientes Windows que desabilitaram as atualizações de DNS do cliente
Auto substituição de DHCP
Para aumentar o possível impacto, queremos poder substituir os registros que estão presentes em qualquer zona ADI: registros de clientes. O problema é que esses registros são de propriedade das máquinas que os criaram, e só podemos autenticar usando a conta de máquina do servidor DHCP.
Mas e o registro DNS do servidor DHCP? Quando o servidor DHCP cria seu próprio registro DNS, sua conta de máquina se torna o proprietário do registro! Acontece que podemos fazer com que o servidor DHCP execute a substituição de DNS via DHCP por si mesmo. Se fornecermos o nome do servidor DHCP como nosso FQDN, o servidor DHCP enviará uma atualização de DNS para seu próprio registro de cliente, e essa substituição será bem-sucedida!
A Figura 18 mostra o fluxo do ataque.
Fig. 18: Substituição de DNS DHCP do registro DNS do servidor DHCP
Esse ataque é mais confiável: se um servidor DHCP da Microsoft estiver presente na rede, um registro de cliente correspondente é garantido, enquanto os registros gerenciados (necessários para o cenário de substituição anterior) são mais raros.
Quanto ao impacto, os invasores poderão interceptar qualquer comunicação destinada ao servidor DHCP. A gravidade dependeria da natureza desse tráfego. Na maioria dos casos, a capacidade de interceptar a comunicação destinada ao servidor DHCP pode ser abusada para interceptar credenciais e transmiti-las, ou capturar o tráfego confidencial de outros serviços que possam estar instalados no servidor.
E por falar em serviços sensíveis: E se o servidor DHCP estiver instalado em um controlador de domínio (DC)? Podemos substituir o registro DC? Bem, podemos.
Substituição arbitrária de DC via DHCP
Se o servidor DHCP estiver instalado em um DC, poderemos executar uma substituição de DNS via DHCP no próprio registro do DC (por causa dos motivos descritos anteriormente nesta publicação). Isso pode ser muito útil, mas há mais que podemos fazer.
Como já sabemos, se o servidor DHCP estiver instalado em um DC, a conta de máquina do DC será usada ao enviar atualizações de DNS. Curiosamente, se inspecionarmos a ACL padrão de um registro DNS arbitrário, veremos que os CONTROLADORES DE DOMÍNIO CORPORATIVO principais tem permissão de gravação em todos os registros de DNS na zona, independentemente de quem o criou (Figura 19).
Fig. 19: A ACL padrão de todos os registros de domínio que contêm o grupo ENTERPRISE DOMAIN CONTROLLERS
Isso é muito relevante. Se o servidor DHCP for um DC, ele terá permissões sobre todos os registros na zona e os invasores poderão usá-lo para substituir qualquer registro DNS A dentro da zona ADI como um usuário não autenticado! O ataque é ilustrado na Figura 20.
Fig. 20: O DNS DHCP arbitrário substitui quando o servidor DHCP é um DC
Nossos dados mostram que essa configuração arriscada é muito comum, entre as redes que observamos usando o servidor DHCP da Microsoft, 57% tem um servidor DHCP instalado em um DC. Todos esses domínios são vulneráveis por padrão.
Embora esse risco tenha sido reconhecido pela Microsoft em sua documentação, acreditamos que a conscientização sobre essa configuração incorreta não está de acordo com seu possível impacto.
Mitigações para ataques de DNS via DHCP e como eles podem ser contornados
Todos os ataques descritos até agora funcionam com a configuração padrão dos servidores DHCP da Microsoft. No entanto, há duas configurações que podem ajudar a atenuar algumas delas. Vamos dar uma olhada nelas e ver como elas também podem ser contornadas.
Proteção de nomes de DHCP
Como sabemos, quando um servidor DHCP cria um registro DNS, não há nada impedindo que outros clientes solicitem o mesmo FQDN e forcem o servidor a substitui-lo. A Proteção de nomes é um recurso destinado a evitar que isso aconteça.
A Proteção de nomes é implementada usando um tipo de registro DNS especial: DHCID (identificador de cliente DHCP). Com a proteção de nomes ativada, sempre que um servidor DHCP grava um registro em nome de um cliente, um registro DHCID adicional é criado (Figura 21).
Fig. 21: Registro DHCID criado por um servidor DHCP com proteção de nome habilitada
Como você pode ver, o valor do registro DHCID é um bloco de dados codificados em Base64. Este valor (que analisaremos posteriormente nesta publicação) é uma assinatura exclusiva destinada a identificar o cliente DHCP que solicitou a criação ou atualização do registro.
Quando o servidor DHCP é solicitado a modificar um registro de DNS, ele calcula o valor de DHCID do cliente e envia uma atualização de DNS que inclui os dados atualizados juntamente com esse valor de DHCID.
Se o registro ainda não existir no servidor DNS, ele simplesmente criará o registro e o registro DHCID correspondente. No entanto, se os registros Host (A) e DHCID existirem, o valor DHCID existente será comparado com aquele enviado pelo servidor DHCP. A atualização será executada somente se os valores corresponderem.
Portanto, essencialmente, o registro DHCID associa um registro DNS ao cliente que o criou. Depois que essa associação for criada, somente esse cliente original poderá executar modificações no registro.
Contornando a proteção de nomes
Encontramos uma maneira de contornar a proteção de nomes usando uma mensagem de liberação DHCP: uma mensagem enviada por clientes DHCP para informar o servidor quando eles não precisam mais de seu endereço IP alugado. Para manter o controle dos endereços alugados, o servidor DHCP mantém uma tabela que armazena os diferentes endereços, seus tempos de expiração e o identificador exclusivo do cliente que os alugou (Figura 22).
Fig. 22: Entrada da tabela de concessão do servidor DHCP
O identificador exclusivo é simplesmente o endereço MAC do cliente. Ao receber uma mensagem de Liberação de um cliente, o servidor DHCP procura uma entrada existente com um endereço e ID correspondentes e a exclui se for encontrada. Quando as atualizações dinâmicas de DNS via DHCP estiverem ativadas, além de liberar o endereço IP, o servidor DHCP também enviará uma Atualização dinâmica de DNS para excluir o registro DNS associado do cliente.
Se pudermos enviar uma versão de DHCP com um ID exclusivo (endereço MAC) que corresponda ao ID do nosso destino, o servidor DHCP excluirá o registro, permitindo que nós o registemos para nós mesmos — o único requisito para contornar a proteção de nomes é o endereço MAC da vítima! (Observe que não há necessidade de alterar nosso MAC real, já que o valor é obtido do cabeçalho DHCP.)
Se estivermos na mesma LAN que o destino, encontrar seu MAC é bastante trivial; por exemplo, podemos encontrá-lo enviando uma solicitação ARP. Mas e se não estivermos na mesma LAN? Temos outra opção.
Forçar os registros DHCID de forma bruta para contornar a proteção de nome
Os registros de DHCID são definidos na RFC 4701, e seu algoritmo é bastante simples:
Concatene o seguinte valores:
DHCP HTYPE (tipo de hardware). Para Ethernet, o valor é 01.
Opções de ID do cliente DHCP
Registre FQDN (em formato de conexão DNS)
SHA256 o resultado
Adicionar bits de dados DHCID (na implementação do Windows, esse valor é constante)
Codifique o resultado em Base64
A Figura 23 mostra um exemplo de cálculo de DHCID.
Fig. 23: Um exemplo de cálculo de DHCID
Como sabemos que o FQDN e os bits de dados são constantes, a única variável é o ID do cliente, que é novamente o endereço MAC do cliente.
Os registros de DHCID são registros DNS normais, de modo que qualquer cliente pode consultar o servidor DNS quanto ao seu valor. Como sabemos o algoritmo para calcular um registro DHCID, podemos iterar todos os endereços MAC possíveis e calcular seu valor DHCID e comparar cada resultado com nosso registro de destino. Quando obtemos uma correspondência, sabemos que encontramos o endereço MAC correto. Isso permite que os invasores forcem o endereço MAC em tempo razoável; 248 possíveis endereços MAC podem ser decifrados por um computador moderno e dedicado em apenas alguns dias. Podemos reduzir esse tempo drasticamente se usarmos apenas IDs de fornecedores comuns. Um exemplo desse processo pode ser visto na Figura 24.
Fig. 24: Exclusão de um registro DNS com proteção de nomes
O código referenciado pode ser usado para calcular o valor de DHCID com base nos parâmetros especificados.
As atenuações de efeito colateral da proteção de nomes
A proteção de nomes DHCP destina-se a registros gerenciados: Essencialmente, o servidor DHCP protege os registros que foram criados por ele contra serem modificados por clientes aleatórios. A proteção de nomes não tem nada a ver com registros de clientes.
Apesar disso, em alguns casos, a proteção de nomes ainda pode atenuar ataques em registros de clientes.
Ao atualizar registros DNS com a proteção de nomes habilitada, o servidor DHCP requer a presença de um registro DHCID. Como os clientes DNS normais não criam registros DHCID, os registros de clientes não são acompanhados por eles. Como resultado, qualquer tentativa de atualizar um registro de cliente de um servidor DHCP falharia (Figura 25).
Fig. 25: Falha na atualização do DNS quando um registro DHCID não existe
Isso acontece por causa da maneira como a proteção de nomes é implementada. Quando um servidor DHCP com a proteção de nomes ativada envia uma atualização de DNS, ele adiciona um campo Pré-requisitos à solicitação. Este campo especifica as condições que devem ser atendidas no servidor DNS para que a atualização do DNS ocorra. Na Figura 26 podemos ver que a atualização de DNS enviada pelo servidor DHCP inclui um pré-requisito para o valor DHCID.
Fig. 26: Pré-requisitos de atualização de DNS
Isso significa que a atualização falhará se um valor correspondente não existir. Como os registros do cliente nunca devem ter um registro DHCID, se a proteção de nomes estiver ativada, os registros do cliente devem estar protegidos contra substituições de DNS via DHCP sem uma maneira de contornar isso. Devem estar.
Isso não faz parte do recurso de proteção de nomes, mais um subproduto dele, pois, por definição, a proteção de nomes é destinada a proteger apenas registros gerenciados. Ainda assim, devido à lógica que acabamos de descrever, ele também pode proteger os registros do cliente. Mas mesmo essa defesa acidental pode ser contornada.
Escopos de DHCP para o resgate?
Os servidores DHCP podem definir vários escopos - um escopo é um conjunto definido de endereços IP em uma sub-rede específica que o DHCP pode alugar (Figura 27).
Fig. 27: Um exemplo de escopos DHCP
A separação em escopos permite um melhor gerenciamento da distribuição de endereços e também permite a aplicação de diferentes políticas para diferentes sub-redes. A proteção de nomes é uma dessas políticas e está habilitada no nível do escopo, o que significa que diferentes escopos podem ter configurações diferentes.
Como mencionamos anteriormente nesta publicação, quando tentamos executar uma substituição de DNS DHCP em um registro de cliente, falhamos porque nosso aluguel era de um escopo de DHCP com a Proteção de nomes. Mas há algo importante a ser compreendido: Escopo é um termo de DHCP. Os registros do cliente não estão cientes deles e não estão associados a nenhum escopo.
Por isso, se pudermos obter um aluguel de outro escopo que tenha a proteção de nomes desabilitada, poderemos “contornar” essa mitigação. (Como obter um aluguel de outro escopo que tenha a proteção de nomes desabilitada está além da abrangência desta publicação, mas você pode consultar a opção de retransmissão de DHCP)
Isso significa que, mesmo que um único escopo do servidor tenha a proteção de nomes desabilitada, deve ser suficiente para que um invasor substitua os registros do cliente (dada uma das configurações incorretas discutidas anteriormente).
Credencial de DNS
Outra configuração que pode ser configurada no servidor DHCP é a credencial de DNS. Essa configuração nos permite fornecer a credencial de um usuário do domínio e tê-la usada pelo servidor DHCP em vez da conta da máquina ao criar e atualizar registros (Figura 28).
Fig. 28: Configuração de credenciais DNS DHCP
Vamos voltar ao exemplo em que um servidor DHCP foi instalado em um DC. Ao atualizar os registros DNS, a conta de máquina DC foi usada, uma conta que tem permissões sobre qualquer registro na zona. Com uma credencial de DNS configurada, uma conta vulnerável poderia ser usada e o ataque não funcionaria mais.
A configuração de uma credencial de DNS é muito importante, pois permite uma redução da superfície de ataque exposta pelo servidor DHCP. Ele deve ser capaz de atenuar os ataques mais graves que descrevemos anteriormente.
No entanto, há dois detalhes que você precisa considerar ao usar este recurso:
A credencial configurada deve ser um usuário vulnerável. Se o configurarmos como administrador de domínio, por exemplo, o servidor DHCP ainda poderá substituir registros arbitrários.
Os registros DNS criados pelo servidor DHCP ainda seriam de propriedade da mesma credencial e ainda estariam vulneráveis à substituição de DNS DHCP.
Grupo DNSUpdateProxy
Durante nossa investigação sobre o DHCP da Microsoft e sua interação com o DNS, encontramos outro recurso que pode ser abusado: o grupo DNSUpdateProxy . Este grupo tem o objetivo de resolver dois problemas relacionados a permissões de registros gerenciados: o problema do cliente atualizado e o problema de vários servidores DHCP.
Problema do cliente atualizado
Vamos considerar primeiro o problema do cliente atualizado: Inicialmente, um cliente herdado usa o servidor DHCP para registrar um registro DNS, mas depois é atualizado para um OS mais recente que suporta atualizações dinâmicas de DNS. O cliente não pode modificar seu registro diretamente, pois o registro é de propriedade do servidor DHCP que o criou.
Para resolver este problema, o servidor DHCP pode ser adicionado ao grupo DNSUpdateProxy.
Este grupo tem dois efeitos: Primeiro, quando seus membros criam um registro DNS, a ACL do registro é diferente dos registros gerenciados normais, o grupo usuários autenticados recebe permissão de gravação sobre o registro. Isso significa que qualquer cliente no domínio pode modificá-lo (Figura 29).
Fig. 29: ACL de registro DnsUpdateProxy
O segundo efeito é um recurso de “controle de registro”. O primeiro cliente que modifica um registro criado por um membro DnsUpdateProxy recebe propriedade sobre ele e remove a permissão de gravação dos usuários autenticados. Isso resolve o problema do cliente atualizado, permitindo que os clientes modifiquem e assumam seu próprio registro depois que eles forem obrigados a fazê-lo.
Problema de vários servidores DHCP
O segundo problema surge quando vários servidores DHCP são necessários para trabalhar juntos. Neste exemplo temos dois servidores DHCP: DHCP1 e DHCP2, e um cliente PC1 registra um registro DNS através do DHCP1.
Agora, vamos imaginar que o DHCP1 fica offline por algum motivo e o DHCP2 é colocado em ação. O aluguel do cliente expira, portanto ele entra em contato com DHCP2 para uma renovação. Quando DHCP2 aluga o novo IP e tenta modificar o registro DNS para o cliente, ele falha, porque o registro é de propriedade de DHCP1 (Figura 30).
Fig. 30: Um exemplo de uma configuração de servidor DHCP múltiplo
Esse problema pode ser resolvido novamente usando DnsUpdateProxy, devido a um recurso adicional desse grupo. Se um membro DnsUpdateProxy tentar modificar um registro de propriedade de outro membro, a atualização será bem-sucedida devido à ACL, mas desta vez a ACL e a propriedade não mudam. Isso permite que vários servidores detenham a “copropriedade” dos registros.
Um risco de segurança e um bug
Agora, você provavelmente entende que o grupo DnsUpdateProxy expõe um risco de segurança: Qualquer registro criado por membros desse grupo pode ser “roubado” por qualquer usuário autenticado. Esta não é uma vulnerabilidade, é apenas um abuso do design da funcionalidade. Este risco é reconhecido pela Microsoft.
Além desse risco, identificamos outro problema que deriva do que parece ser um bug na implementação do recurso DnsUpdateProxy. Quando um membro do grupo cria seu próprio registro DNS, ele é criado com a mesma ACL vulnerável, para a qual os usuários autenticados têm permissões de gravação.
A Figura 31 mostra um exemplo. Nosso registro dhcp1.aka.test do servidor DHCP inicialmente tem uma ACL segura.
Fig. 31: ACL inicial do servidor DHCP
Podemos ver que a conta de máquina tem permissões sobre ela, e o grupo usuários autenticados não é encontrado em nenhum lugar. Agora, adicionamos o servidor ao grupo DnsUpdateProxy e acionamos uma recriação do registro DNS. Isso pode acontecer por vários motivos; por exemplo, se o nome do servidor for alterado. Depois que o registro DNS é recriado, inspecionamos sua nova ACL (Figura 32).
Fig. 32: ACL vulnerável do servidor DHCP
Vemos que o novo registro DNS agora é gravável por usuários do domínio. Obviamente, essa não é uma parte pretendida do recurso. Os registros gerenciados criados pelo servidor devem ter uma ACL modificada, mas o registro do próprio cliente do servidor não deve ser afetado.
Mitigando ataques de DNS via DHCP
Existem muitos riscos relacionados às atualizações dinâmicas de DNS via DHCP. Vamos resumir todas as diferentes configurações possíveis de servidor e aprender a atenuar os ataques que acabamos de descrever.
Nós nos referiremos aos dois tipos de registros: registros gerenciados que foram criados pelo servidor DHCP e registros de clientes que foram criados diretamente pelos clientes Windows.
A versão TL;DR é:
Desative as atualizações dinâmicas de DNS via DHCP se não precisar delas
Os registros de clientes devem ser seguros se você configurar um usuário vulnerável como a credencial de DNS
Os registros gerenciados não podem ser protegidos contra falsificação com qualquer configuração; use registros DNS estáticos para hosts confidenciais não Windows, se possível
Não use DnsUpdateProxy; em vez disso, use a mesma credencial de DNS em todos os seus servidores DHCP
Credencial de DNS
Esta é a melhor maneira de mitigar substituições de DNS via DHCP em registros de clientes. Configure um usuário vulnerável com uma senha de alta segurança dedicada a essa finalidade. Se você executar um servidor DHCP em seu DC, isso é crítico. Esta configuração não irá interromper as substituições de DNS via DHCP em registros gerenciados.
Proteção de nomes
A proteção de nomes deve, na teoria, proteger os registros gerenciados, mas na prática, os invasores podem contorná-los com muita facilidade. Ele ainda deve ser habilitado para tornar as substituições menos triviais.
Embora a proteção de nomes não se destinasse a proteger registros de clientes, se ela estiver habilitada em todos os escopos no servidor, os ataques de substituição ainda serão atenuados.
Ao configurar a proteção de nomes no DHCP da Microsoft, há duas maneiras de aplicá-la: no nível do servidor ou no nível do escopo. Pode-se pensar que a proteção de nomes que está sendo ativada no nível do servidor significaria que a proteção de nome seria ativada no nível do servidor, certo? Mas, na realidade, esse não é o caso. Ativar a proteção de nomes no nível do servidor só garante que novos escopos no servidor são criados com a configuração ativada, mas ela não é ativada nos escopos existentes. É importante verificar se a proteção de nomes está ativada no nível de escopo de cada escopo no servidor.
DNSUpdateProxy
Você não deve usar este grupo. É um risco de segurança porque todos os registros criados por seus membros são suscetíveis a substituições.
Se você tiver vários servidores DHCP e quiser que eles funcionem juntos, use a credencial de DNS. Basta configurar a mesma credencial de DNS em todos os servidores DHCP, o que permitirá que eles editem os registros uns dos outros.
DnsUpdateProxy só é útil se você tiver clientes Windows NT 4.0 (ou mais antigos) que planeja atualizar em breve. E se você tiver alguma coisa vintage dessa, você tem problemas maiores do que DnsUpdateProxy.
Se, por algum motivo, você precisar usar DnsUpdateProxy, é recomendável criar um registro DNS estático para cada um dos membros do grupo. Um registro estático seria de propriedade de sua conta de criação, que deve ser diferente das contas de máquina dos diferentes servidores. Isso impedirá que os servidores criem seus próprios registros com permissões inseguras.
Falsificação de DNS via DHCP
Não há como impedir que invasores não autenticados criem registros DNS não existentes. A única maneira de fazer isso seria desativar as atualizações dinâmicas de DNS via DHCP em todos os servidores DHCP. Em geral, se o recurso atualizações dinâmicas de DNS via DHCP não for necessário em seu ambiente, desativá-las provavelmente é uma boa ideia. Isso eliminará alguns riscos e ajudará a reduzir a superfície de ataque.
Detecção de configurações incorretas com o Invoke-DHCPCheckup
Para ajudá-lo a atravessar a bagunça de possíveis configurações DHCP, estamos lançando uma ferramenta PowerShell chamada Invoke-DHCPCheckup para identificar riscos relacionados a atualizações dinâmicas de DNS DHCP (Figura 33).
Fig. 33: Exemplo de saída invoque-DHCPCheckup
A ferramenta identifica as seguintes configurações incorretas:
Credencial de DNS
A credencial de DNS não está configurada
A credencial de DNS configurada é de um usuário forte
Proteção de nomes
A Proteção de nomes não está ativada em um escopo
A Proteção de nomes não está ativada por padrão em novos escopos
DNSUpdateProxy
Exibir membros do grupo
Especifique se os membros são servidores DHCP
ACLs de registro vulneráveis
Liste registros de propriedade de servidores DHCP (registros gerenciados)
Liste os registros que podem ser substituídos por usuários autenticados
Essa ferramenta depende da API de gerenciamento de servidor DHCP e requer que um usuário forte seja executado, portanto, a ferramenta é destinada principalmente a equipes azuis.
Resumo
Relatamos todas as nossas descobertas à Microsoft, que responderam que todos os problemas mencionados acima são por projeto, ou não graves o suficiente para receber uma correção.
Tendemos a discordar. O impacto dos ataques que destacamos podem ser muito significativos e a capacidade de substituir registros de DNS sem qualquer autenticação permite que os invasores obtenham uma posição “machine-in-the-middle” nos hosts do domínio. Isso pode expor facilmente informações confidenciais e credenciais, além de permitir ataques de retransmissão, permitindo que invasores violem domínios do AD e aumentem privilégios. As estatísticas que compartilhamos nesta publicação demonstram a solidez da ameaça para muitas redes de data center.
Como uma correção para esses problemas não é planejada, recomendamos que os defensores examinem seus ambientes usando o Invoke-DHCPCheckup para tentar localizar as configurações erradas de risco que destacamos. Alerta de spoiler! Se você não alterou a configuração padrão, você está vulnerável.
Fique atento
Em uma futura publicação do blog, lançaremos DDSpoof (DHCP DNS spoof), uma ferramenta que implementa todos os ataques que descrevemos neste artigo. Mostraremos como invasores não autenticados podem coletar dados necessários de servidores DHCP, identificar registros DNS vulneráveis, substitui-los e usar essa capacidade para comprometer domínios do AD.
