DNS via DHCP como arma – Um Guia prático
Introdução
Na primeira parte desta série de blog, apresentamos 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 permitem que agentes de ameaça falsifiquem registros DNS em zonas DNS (ADIDNS) abusando do recurso Atualizações dinâmicas de DNS via DHCP. Exploramos a operação do recurso e destacamos erros de configuração que poderiam ser abusados pelos invasores para falsificar registros DNS confidenciais.
Nesta segunda postagem do blog, nosso objetivo é elaborar alguns dos detalhes técnicos necessários para explorar essa superfície de ataque. Detalharemos os métodos usados para coletar todas as informações necessárias para conduzir os ataques, descreveremos algumas limitações de ataque e exploraremos como podemos falsificar vários registros DNS abusando de um comportamento interessante do servidor DHCP.
Por fim, apresentamos uma nova ferramenta para adicionar à sua caixa de ferramentas. Combinamos tudo o que aprendemos a criar DDSpoof – Uma ferramenta Python que permite que equipes vermelhas e azuis executem e estudem ataques DNS via DHCP. Em um seção posterior nesta publicação, descreveremos como a ferramenta pode ser usada em vários cenários de ataque.
Isenção de responsabilidade: O DDSpoof pode ajudar as equipes de segurança a identificar riscos e, ao mesmo tempo, aumentar a conscientização sobre essa superfície de ataque. No entanto, a ferramenta por si só não é suficiente para causar danos reais. Ela requer acesso à rede e exploração adicional para abusar da falsificação primitiva de DNS.
Enumeração DHCP
Em nosso postagem anterior, compartilhamos a teoria por trás da falsificação de DNS via DHCP. Na prática, há várias informações necessárias para executar efetivamente os ataques que descrevemos. Felizmente para os invasores, a capacidade de descobrir servidores DHCP e saber mais sobre sua configuração fazem parte do protocolo DHCP, o que torna o processo de reconhecimento trivial.
Nas seções a seguir, descreveremos diferentes métodos e truques que os invasores podem usar de um contexto não autenticado para coletar essas diferentes informações.
Identificação de servidores de DHCP
A parte mais importante de um ataque DNS via DHCP é o servidor DHCP de destino, portanto, a primeira etapa seria identificar um. Identificar servidores DHCP ativos na rede é muito simples. Um invasor pode enviar uma transmissão de descoberta de DHCP e inspecionar respostas de ofertas de servidores.
Para enviar mensagem DHCP, você pode executar o dhclient Utilitário Linux: um cliente DHCP configurável que permite a interação com servidores DHCP. Podemos configurar dhclient editando seu arquivo de configuração, que está localizado em /etc/dhcp/dhclient.conf.
Quando o executamos, dhclient solicitará a configuração de rede do servidor DHCP e a aplicará à nossa máquina, substituindo o nosso endereço IP atual. Para evitar isso, você pode executá-la em uma interface virtual com a sintaxe a seguir:
dhclient <interface_name>:<virtual_interface_name>
Depois de executar esse comando, podemos ver que nosso endereço IP original (172.25.14.55) permanece inalterado, enquanto nossa interface virtual recebeu um novo endereço IP do servidor DHCP (Figura 1).
Fig. 1: Using dhclient on a virtual interface and keeping our original IP
Se registrarmos o tráfego e inspecionarmos as mensagens de oferta de DHCP, poderemos identificar todos os servidores DHCP ativos (Figura 2).
Fig. 2: Sending a DHCP Discover to identify active DHCP servers in the network
Como obter o domínio de um servidor DHCP e o servidor DNS
Depois de identificar os servidores DHCP na rede, precisamos saber quais registros podem ser falsificados em cada servidor. Um servidor DHCP só pode criar registros dentro de sua zona ADI associada: um servidor associado ao domínio "aka.test" só poderá gravar registros DNS com o mesmo sufixo: <nome do host>.aka.test. Para entender quais registros podemos falsificar, precisaremos identificar esse sufixo.
Além disso, gostaríamos de saber qual servidor DNS hospedará os novos registros, o que nos permitirá consultar e verificar o sucesso do ataque.
Um truque que os invasores podem usar para descobrir esses dois parâmetros é a opção Lista de solicitações de parâmetros, que permite consultar o servidor DHCP para obter configurações específicas. Para os nossos fins, podemos consultar o servidor associado Nome de domínio e Nome de domínio Opções de servidor.
Podemos usar novamente dhclient. Para adicionar a opção Lista de solicitações de parâmetros à nossa mensagem de Descoberta, incluímos a seguinte linha no dhclientde configuração do:
request domain-name, domain-name-servers;
Quando executamos dhclient (como antes, em uma interface virtual) e inspecionamos nossa mensagem de Descoberta vimos que ela inclui a opção Lista de solicitações de parâmetros com os campos que solicitamos (Figura 3).
Fig. 3: Parameter Request List inside a DHCP Discover message
Um servidor DHCP da Microsoft que esteja escutando deve enviar uma resposta de oferta a esta mensagem de descoberta com os parâmetros solicitados (Figura 4).
Fig. 4: DHCP server response with our requested settings
Dedução do status de Proteção de nome
Outra configuração que é importante ao tentar usar as atualizações dinâmicas de DNS via DHCP é a Proteção de nome, pois essa configuração determinará sedeterminados ataques de substituição são possíveis. Não podemos consultar diretamente o status da Proteção de nome, mas existe uma forma simples de deduzi-lo em quatro etapas.
Criar um registro de DNS usando Atualizações dinâmicas de DNS via DHCP
Verifique se um registro A foi criado
Consulte o servidor DNS do registro DHCID com o mesmo nome
Se existir um registro DHCID juntamente com o registro A, a Proteção de nome está ativada
Para invocar uma atualizações dinâmicas de DNS via DHCP usando dhclient, adicionamos as seguintes linhas ao arquivo de configuração:
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
As duas primeiras linhas adicionam a opção FQDN com Server Flag, que é necessário para fazer com que o servidor DHCP registre o registro DNS para nós. A terceira linha é opcional e nos permite adicionar uma opção de Identificador de servidor DHCP para direcionar um servidor DHCP específico nos casos em que vários estão presentes.
Depois de executar o dhclient, podemos usar nslookup para consultar o servidor DNS de destino e procurar um registro DHCID (Figura 5).
Fig. 5: Verifying Name Protection status with nslookup
Nesse caso, podemos ver que um registro DHCID foi criado, o que indica que a Proteção de nome está ativada.
Dedução da configuração de atualizações dinâmicas de DNS via DHCP
Há três opções que determinam em quais casos o servidor DHCP criará registros DNS para clientes (Figura 6). Saber qual configuração está sendo usada pode permitir que os invasores identifiquem solicitações DHCP e identifiquem aquelas que levam à criação de um registros gerenciados. Dessa forma, podem ser identificados possíveis alvos para substituição de registro gerenciado, a falsificação de registros criados pelo servidor de DHCP.
As três configurações possíveis são:
Atualize dinamicamente somente se solicitado pelo cliente. Esta é a opção padrão, que só criará um registro DNS se uma opção FQDN estiver presente na solicitação e o Server flag estiver definido.
Atualize dinamicamente sempre. Um registro DNS é criado para qualquer solicitação DHCP com uma opção FQDN, independentemente do valor do Server flag.
Atualize dinamicamente para clientes que não solicitam atualizações. Crie um registro DNS para clientes, mesmo quando a opção FQDN não estiver presente: o FQDN é baseado na opção Nome de host DHCP. Isso se destina a oferecer suporte a clientes DHCP antigos que não usam a opção FQDN.
Fig. 6: DHCP DNS Dynamic Update settings
Podemos deduzir essa configuração inspecionando seus "efeitos colaterais": Acionaremos uma Atualização dinâmica de DNS via DHCP sob as diferentes condições e consultaremos o servidor DNS para verificar se um registro foi criado. Isso pode ser feito usando o dhclient para alugar um endereço IP e usando nslookup para consultar o servidor DNS.
A configuração necessária dhclient a ser testada para cada uma das configurações possíveis é a seguinte:
Crie registros para clientes que não solicitem atualizações
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Crie registros sempre (quando a opção FQDN estiver presente)
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Crie registros somente se solicitado pelo cliente
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Limitações ao endereço dos registros falsificados
Para que nosso ataque seja eficaz, precisamos dos registros DNS falsificados para apontar para nossa máquina controlada. Com a falsificação de DNS via DHCP, dependemos do servidor DHCP para criar esses registros DNS. Infelizmente, não podemos escolher qualquer endereço IP arbitrário. O servidor DHCP tem um escopo definido de endereços IP internos e ele se recusará a alugar (e, subsequentemente, a criar um registro DNS para) qualquer endereço IP fora desse escopo.
Por esse motivo, há duas limitações no endereço para o qual redirecionamos a comunicação:
O endereço não pode ser fora da rede: Não é possível alugar um endereço IP externo do servidor DHCP e, portanto, não podemos usar um quando falsificado.
O endereço não pode ser de uma máquina com um endereço IP estático: Se uma máquina tiver um endereço IP estático configurado, é improvável que esse endereço esteja no pool de aluguel de um servidor DHCP e, portanto, não possa ser usado durante a falsificação.
Como temos acesso a uma máquina interna que pode usar um endereço IP dinâmico, podemos somente usar qualquer endereço oferecido pelo servidor DHCP para nossos registros falsificados.
Para garantir que estamos usando esse mesmo endereço ao executar ações adicionais, podemos usar a opção de endereço IP solicitado. Podemos fazer isso adicionando a seguinte linha dhclientdhclient:
send dhcp-requested-address 172.25.14.55;
Escrever vários registros DNS
Ao realizar a falsificação de DNS via DHCP, é mais provável que optemos por falsificar vários registros DNS em vez de um único, com o objetivo de redirecionar tráfego do maior número possível de vítimas. No entanto, quando tentamos direcionar vários registros DNS para o mesmo IP de destino, encontramos um problema.
Depois que um servidor DHCP aluga um determinado endereço IP a um host, ele não pode ser alugado por outros clientes. Esse comportamento serve para evitar conflitos de IP entre diferentes clientes. Quando alugamos um endereço IP com um determinado FQDN para executar um DDSpoof, esse endereço IP é removido do pool de endereços do servidor. Se tentarmos alugar o mesmo endereço IP novamente com um FQDN diferente, o servidor oferecerá um endereço diferente (Figura 7).
Fig. 7: DHCP lease process when the requested address is taken
Não podemos resolver esse problema liberando o aluguel anterior, pois isso acionaria uma Atualização dinâmica de DNS pelo servidor DHCP para excluir o registro que acabou de ser liberado e removeria nosso registro falsificado anteriormente (Figura 8).
Fig. 8: DHCP Release invokes the deletion of the associated DNS record
Em outras palavras, nossos objetivos são:
Liberar o endereço IP; ou seja, remover sua entrada de aluguel do servidor DHCP e retorná-la ao pool de endereços (para que possamos usá-la para registrar um novo registro DNS)
Evitar a exclusão do registro DNS falsificado existente
Encontramos um comportamento/bug interessante que nos permite fazer exatamente isso.
Enviamos um pacote de solicitação DHCP para o servidor DHCP que atualmente aluga nosso endereço IP, com os seguintes parâmetros:
O endereço MAC do cliente que foi usado para solicitar o aluguel DHCP existente do servidor
O Identificador de servidor de um servidor diferente do nosso servidor direcionado
Vendo essa mensagem de transmissão, nosso servidor DHCP direcionado "presumirá" que estamos solicitando um novo endereço IP de outro servidor e que, portanto, não precisamos mais do existente (alugado). Em seguida, ele excluirá o aluguel de IP sem excluir o registro DNS associado (Figura 9). Por que o registro DNS não é excluído não é claro para nós; suspeitamos que isso possa ser um bug de lógica.
Fig. 9: Deleting a lease entry without deleting its associated DNS record
Vamos ver isso em ação
Queremos criar dois registros DNS que apontem para o mesmo IP. Criamos o primeiro registro usando dhclient da mesma forma que descrevemos anteriormente. Nosso registro é criado e, se olharmos para a tabela de aluguel de servidor DHCP, podemos ver que nosso aluguel está presente lá (Figura 10).
Fig. 10: DHCP lease table entry
Agora modificamos a opção dhcp-server-identifier dhclient no arquivo de configuração para qualquer outro IP, executamos dhclient novamente, e vemos que nosso aluguel foi excluído!
Agora podemos simplesmente executar dhclient novamente com um FQDN diferente ao solicitar o mesmo endereço IP e criar um segundo registro (Figura 11).
Fig. 11: Multiple attacker DNS records point to the same IP address
Introdução do DDSpoof.py
Combinamos todos os recursos e técnicas descritos nesta série do blog para criar o DDSpoof, um kit de ferramentas que viabiliza a execução de ataques de DNS via DHCP. Esta ferramenta Python executa a enumeração do servidor DHCP, executa comandos DNS via DHCP personalizados e identifica possíveis alvos de falsificação. A funcionalidade do DDSpoof é documentada neste repositório.
Nas próximas seções, examinaremos vários cenários de ataque que podem ser realizados com o DDSpoof.
Configuração do DDSpoof
Estamos executando uma máquina Kali Linux dentro da nossa rede de destino, sem credenciais de domínio. Primeiro, executaremos o DDSpoof para verificar a rede e identificar possíveis destinos (especificando qual interface usar para enviar e receber pacotes; Figura 12).
Fig. 12: DDSpoof initial enumeration
Podemos ver que o DDSpoof executa o seguinte:
Identifica todos os servidores DHCP acessíveis e suas configurações
Determina o status da Proteção de nome
Verifica se nosso endereço IP atual está disponível para locação em nosso servidor de destino
Neste exemplo, nosso endereço IP não está disponível para locação em nosso servidor de destino, portanto, nós o modificamos manualmente para o endereço IP oferecido pelo servidor (Figura 13).
Fig. 13: Modifying our IP address to an address available on the DHCP server
Agora estamos prontos para iniciar a falsificação.
Falsificação de DNS via DHCP
Para realizar a nossa primeira falsificação de DNS via DHCP, queremos identificar tentativas de resolução de nomes com falha e criar registros DNS para eles que se direcionem para a nossa máquina. Para fazer isso, usaremos o comando start-llmnr DDSpoof. Esse comando inicia um detector de LLMNR que nos notificará sobre as consultas de LLMNR na rede, o que pode nos levar a possíveis alvos de falsificação (Figura 14).
Fig. 14: Using DDSpoof’s LLMNR sniffer to identify spoofing targets
Aqui podemos ver que o detector conseguiu identificar os arquivos de nome .aka.test. Agora, podemos usar o comando write-record para tentar registrar esse nome de DNS (Figura 15).
Fig. 15: Using DDSpoof to spoof a DNS record for the target name
Como podemos ver, o DDSpoof cria com sucesso esse registro DNS, direcionado ao nosso endereço IP! Podemos verificar isso com nslookup (Figura 16).
Fig. 16: Using nslookup to confirm that the record creation was successful
Da próxima vez que um host na rede tentar resolver os arquivos de nome .aka.test, ele será direcionado à nossa máquina controlada.
delete-record para remover nosso registro falsificado (Figura 17).
Fig. 17: Using DDSpoof to delete our spoofed record
Substituição de DNS via DHCP
Outra opção que temos é a substituição de DNS via DHCP. Se olharmos para a Figura 12, podemos ver que nosso servidor DHCP de destino também é um servidor DNS. Isso sugere que o servidor também pode ser um DC (Domain Controller, controlador de domínio), uma vez que o servidor DNS geralmente é instalado em um DC em ambientes Active Directory. Podemos verificar isso usando o seguinte comando nmap:
Nmap -p389 -sV 172.25.14.123
Fig. 18: Nmap output confirming the server is a domain controller
Se uma credencial de DNS não foi configurada, podemos substituir qualquer registro na zona ADI. Digamos que identificamos um host chamado file-server.aka.test (Figura 19).
Fig. 19: nslookup results for file-server.aka.test
Podemos tentar substituir seu registro DNS usando o comando write-record DDSpoof. Se uma credencial de DNS fraca tiver sido configurada, isso deverá falhar. Porém, nesse caso, uma credencial de DNS fraca não foi configurada, então nossa substituição foi bem-sucedida (Figura 20).
Fig. 20: Using DDSpoof to perform a DHCP DNS overwrite of the file-server DNS record
Fig. 21: Using nslookup to confirm that the overwrite was successful
Contornando a proteção de nomes
Em outro cenário, executamos o comando start-dhcp DDSpoof que identifica o tráfego DHCP, identificando mensagens de solicitação DHCP (Figura 22).
Fig. 22: Using DDSpoof’s DHCP sniffer to identify potential managed records
Neste exemplo, identificamos uma máquina chamada ubuntu-server.aka.test que enviou uma solicitação DHCP contendo seu FQDN. Isso pode fazer com que o servidor DHCP crie um registro DNS para ele, fornecendo uma oportunidade para uma substituição de registro gerenciado (lembre-se que um registro gerenciado é criado para hosts que não são do Windows, pois eles não fazem parte do domínio e, portanto, não podem falar diretamente com o servidor DNS).
Mas há um problema. Desta vez, nosso servidor DHCP de destino foi habilitado a Proteção de nome (Figura 23).
Fig. 23: DDSpoof enumerating a DHCP server with enabled Name Protection
Se consultarmos todos os registros de DNS para nosso destino ubuntu-server.aka.test, veremos que um registro DHCID está de fato presente (Figura 24).
Fig. 24: nslookup output containing a DHCID record
Mas não temos medo porque, como já sabemos, a Proteção de nomes pode ser facilmente contornada!
Para isso, basta enviar uma versão DHCP com um ID de cliente (CID), essencialmente o endereço MAC do cliente, que corresponde ao proprietário do registro original. Isso fará com que o servidor DHCP exclua o registro.
Para isso, podemos usar o comando . Fornecemos o CID de destino que obtivemos anteriormente, fazendo com que o DDSpoof represente o cliente DHCP original. Depois disse, podemos executar o delete-record para remover nosso registro de destino (Figura 25).
Fig. 25: Using DDSpoof to delete a DNS record protected with Name Protection
Agora, podemos simplesmente registrar o nome para nós mesmos usando o comando write-record (Figura 26).
Fig. 26: Using DDSpoof to create a new record after deleting the original one, bypassing Name Protection
Resumo
Nos cenários de ataque examinados nesta publicação, demonstramos como é possível falsificar vários registros DNS em domínios do Active Directory de um contexto não autenticado. Essa capacidade é muito flexível e pode ser abusada por invasores de várias maneiras, como por exemplo:
Visar máquinas Windows e interceptar a autenticação NTLM ou Kerberos, permitindo mais ataques de retransmissão ou de força bruta
Visar aplicações de destino que executam protocolos inseguros e interceptam dados confidenciais
Visar registros DNS de servidores de segurança internos, como antivírus ou SIEM, e bloquear o acesso a eles
Esses são apenas alguns exemplos de como essa capacidade pode ser abusada por agentes de ameaças. Há várias outras formas de fazê-lo.
Aos cuidados de: Equipes de segurança
A superfície de ataque exposta por Atualizações dinâmicas de DNS via DHCP é muito potente, e como a Microsoft não planeja lidar com isso, provavelmente chegou para ficar. Incentivamos as equipes de segurança a usarem as seguintes ferramentas para identificar e mitigar os riscos de falsificação de DNS via DHCP, idealmente antes que os invasores alcancem:
Invoke-DHCPCheckup: Identificar configurações DHCP e DNS no Active Directory
DDSpoof: Destaque os riscos e teste sua resiliência à superfície de ataque da Atualização dinâmica de DNS via DHCP
