baldassarrefe/fep3370-advanced-ethical-hackingExploração de DHCP com DynoRoot (CVE-2018-1111)
Este projeto demonstra uma vulnerabilidade conhecida de máquinas Fedora e RedHat relacionada a uma implementação insegura do lado do cliente do Protocolo de Configuração Dinâmica de Host (DHCP). Um servidor DHCP malicioso pode criar ofertas DHCP com uma carga maliciosa que é executada em um shell raiz na máquina vítima.
A vulnerabilidade é creditada a Felix Wilhelm e é conhecida como CVE-2018-1111 ou "DynoRoot".
O Protocolo de Configuração Dinâmica de Host (DHCP) é um componente frequentemente negligenciado em sistemas em rede. Sua função é permitir a configuração dinâmica de máquinas host que se conectam a uma rede existente. O caso de uso mais comum é atribuir um endereço IP a hosts recém-conectados e informá-los sobre as rotas existentes para acessar outras redes. Opções adicionais podem ser especificadas, por exemplo, o endereço de um servidor DNS local e a zona que ele atende, ou a localização de um arquivo de inicialização.
Vamos analisar o protocolo de 4 vias seguido quando um novo host deseja ingressar em uma rede após conectar-se fisicamente a ela por meio de uma conexão Ethernet ou sem fio.
DISCOVER para a rede.OFFER, contendo: endereço IP, máscara de sub-rede, endereço do roteador e outras opções.REQUEST, solicitando oficialmente o aluguel do endereço IP que foi oferecido.ACK, indicando que o cliente está autorizado a usar o endereço IP por um período especificado.Após a troca inicial, o cliente pode renovar o aluguel simplesmente enviando outra mensagem REQUEST. O servidor verificará a existência de um aluguel com o IP e o endereço MAC do cliente e responderá com um ACK.
Sessão DHCP (figura do Wikimedia Commons, sob licença CC BY-SA 4.0).
Algumas observações:
DISCOVER e imediatamente REQUEST um endereço. Isso é comum em cenários nos quais o cliente já se conectou à rede anteriormente e lembra do endereço anterior. Nesse caso, o servidor verifica a disponibilidade do endereço e envia um ACK para a solicitação, ou, caso o aluguel não esteja disponível, envia um NACK.RELEASE para informar ao servidor que o endereço agora está disponível. No entanto, isso não é obrigatório pelo protocolo e o servidor periodicamente recolherá aluguéis expirados.OFFER aluguéis para novos clientes.OFFERs, ele aceitará apenas um; os outros servidores observarão o REQUEST transmitido e invalidarão a oferta.A vulnerabilidade está localizada em /etc/NetworkManager/dispatcher.d/11-dhclient, que é executado pelo cliente para analisar e definir as opções recebidas via DHCP.
declare é um built-in do bash que, quando usado sem argumentos, lista todas as variáveis declaradas.grep filtra todas as variáveis relacionadas ao DHCP.while read opt itera sobre as variáveis DHCP uma a uma, realiza alguma análise e imprime uma linha como export new_optionname=value para cada opção.eval.```bash
eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]=' | while read opt; do
optname=${opt%%=}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
)"<!-- omit in toc -->
#### Operação normal
Em situações normais, o código funcionaria perfeitamente e analisaria as novas opções DHCP.
Como exemplo, o seguinte código:```bash
DHCP4_OPTION_ONE=42
DHCP4_OPTION_TWO="bla bla"
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
optname=${opt%%=*}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
Irá imprimir estas duas instruções export para serem avaliadas por eval:```bash
export new_option_one=42
export new_option_two='bla bla'
<!-- omit in toc -->
#### Injeção de código
No entanto, devido ao uso inseguro de `eval`, é possível injetar comandos bash:```bash
DHCP4_OPTION_ONE="x'& echo Hacked! #"
DHCP4_OPTION_TWO='bla bla'
eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
optname=${opt%%=*}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
)"
Resultará na avaliação de echo Hacked!:```text
[1] 1541
Hacked!
### Fontes
- [Entrada no banco de dados de exploits](https://www.exploit-db.com/exploits/44890)
- [Anúncio da RedHat](https://access.redhat.com/security/vulnerabilities/3442151)
- [Post do blog da Tenable](https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble)
- [Repositório no GitHub](https://github.com/kkirsche/CVE-2018-1111)
- [Anúncio no Twitter](https://twitter.com/_fel1x/status/996388421273882626?lang=en)
## Configuração
A configuração mínima para demonstrar a exploração consiste em apenas duas máquinas: a máquina `victim` executando Fedora 28, e uma máquina `attacker`. Nesta configuração, o atacante simplesmente precisa oferecer um serviço DHCP e aguardar a conexão da vítima.
<figure style="text-align:center">
<img src="https://raw.githubusercontent.com/baldassarrefe/fep3370-advanced-ethical-hacking/HEAD/media/network_simple.svg" style="max-width:400px;" width="90%"/>
<figcaption>Configuração mínima de exploração.</figcaption>
</figure>
Uma configuração mais realista colocaria as máquinas em uma rede privada, onde uma terceira máquina, o `gateway`, é configurada como o servidor DHCP benigno e como o gateway para a internet externa. Nesta configuração, o atacante deve impedir que a vítima se conecte ao servidor DHCP legítimo antes de tentar realizar o ataque.
<figure style="text-align:center">
<img src="https://raw.githubusercontent.com/baldassarrefe/fep3370-advanced-ethical-hacking/HEAD/media/network.svg" style="max-width:800px;" width="90%"/>
<figcaption>Configuração de rede privada com uma máquina gateway atuando como DHCP, roteador e firewall.</figcaption>
</figure>