¿ Dónde está mi IP ?: atacando DHCP

Continuamos con la serie de artículos destinados a aprovechar  la falta de seguridad del protocolo para implementar ataques contra él.

En el siguiente artículo mostraremos como de una forma  sencilla podemos impedir el acceso a red de los usuarios aprovechándonos del modo de funcionamiento del protocolo DHCP (Dynamic Host Configuration Protocol).

Primero un poco de teoría....

Protocolo DHCP (Dynamic Host Configuration Protocol)

El protocolo DHCP se define en el RFC 2131 y su misión básicamente es la de proporcionar la configuración de direccionamiento IP / máscara red / gateway y DNS a los equipos clientes dentro de una red.

El funcionamiento del protocolo DHCP sigue un modelo cliente-servidor:

La operativa del protocolo consiste en:

• El cliente envía una petición de broadcast  "mensaje DHCP Discover", en busca de un servidor DHCP que pueda atender su petición.

• El servidor DHCP contestará mediante un mensaje unicast "DHCP offer con los datos de configuración para el cliente (por ejemplo dirección IP, máscara, dominio, gateway, tiempo de vida de la IP).

• Recibido el ofrecimiento del servidor, el cliente responde con una solicitud formal de esos datos al servidor en cuestión, mediante un mensaje broadcast (DHCPREQUEST).

• El servidor responde con un mensaje unicast al cliente de ACK, confirmando que se ha reservado los datos de IP para el cliente.

Durante la operativa normal del protocolo, se puede observar a simple vista algunos puntos débiles.

• El cliente envía una petición de broadcast a la espera de que un servidor DHCP le responda, esto implica que más de un servidor DHCP a la vez podría responder.

• De la misma forma, un cliente podría enviar muchas peticiones de solicitud de IP a un servidor, colapsando el pool de direccionamiento del servidor.

Escenario

Consideremos el siguiente escenario en el cual disponemos de un servidor DHCP en una determinida Vlan (Vlan20) y un cliente en una Vlan diferente (Vlan10).

La configuración de nuestro servidor DHCP para la Vlan 10 podría ser la siguiente:


subnet 192.168.10.0 netmask 255.255.255.0 {
        interface eth0;
        range 192.168.10.10 192.168.10.240
        default-lease-time 6000;
        max-lease-time 7200;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.10.255;
        option routers 192.168.10.253;
        option domain-name-servers 192.168.20.28, 192.168.30.28;
        option time-offset -3600;
}

La configuración de nuestro Switch L3 con el agente Relay sobre la Vlan10

interface Vlan10
 ip address 192.168.10.253 255.255.255.0
 ip helper-address 192.168.20.22
!

Recordemos que las peticiones DHCP desde los clientes se inician mediante un mensaje Broadcast, por lo tanto, solo se transmiten en el propio segmento, para que el mensaje puede alcanzar a un servidor DHCP en otra Vlan existe una funcionalidad denominada "DHCP Relay".

A grandes rasgos un agente "DHCP Relay" permite reenviar las peticiones y respuestas DHCP entre un cliente y un servidor que se encuentran en redes diferentes.


Analizando el tráfico entre cliente y servidor 


Del lado del servidor podemos observar logs del servicio DHCP:

Apr 18 16:17:04 dhcp dhcpd: DHCPDISCOVER from 1c:c1:de:c0:58:12  via 192.168.10.253

Apr 18 16:17:42 dhcp dhcpd: DHCPOFFER on 192.168.10.186 to 1c:c1:de:c0:58:12  via 192.168.10.253

Apr 18 16:17:42 dhcp dhcpd: DHCPREQUEST for 192.168.10.186 (192.168.20.22) from 1c:c1:de:c0:58:12  via 192.168.10.253

Apr 18 16:17:42 dhcp dhcpd: DHCPACK on 192.168.10.186 to 1c:c1:de:c0:58:12  via 192.168.10.253

Podemos observar como al servidor DHCP llegan peticiones iniciales DHCP (DHCPDISCOVER) desde la MAC 1c:c1:de:c0:58:12 del equipo del cliente.

También podemos ver como esas peticiones llegan realmente desde la IP del agente Relay DHCP (192.168.10.253).

El servidor responde con el correspondiente DHCPOFFER al cliente, proponiendo una configuración de direccionamiento IP.

A nuestro  cliente le parece bien y solicita (DHCPREQUEST) los datos de configuración IP al servidor DHCP.

El servidor está deacuerdo y responde con un DHCPACK al cliente

Del lado del cliente y con Wireshark podemos ver el mismo intercambio de mensajes DHCP pero en sentido Cliente-Servidor DHCP.

Podemos observar el funcionamiento de este protocolo sobre los puertos UDP 68 y 67

460 59.011871 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x2af5de99

Frame 460: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: HewlettP_c0:58:12 (1c:c1:de:c0:58:12), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Discover)


468 59.519157 192.168.10.253 255.255.255.255 DHCP 342 DHCP Offer    - Transaction ID 0x2af5de99

Frame 468: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: CiscoInc_71:50:bf (54:75:d0:71:50:bf), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.10.253, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67 (67), Dst Port: 68 (68)
Bootstrap Protocol (Offer)
 


469 59.519746 0.0.0.0 255.255.255.255 DHCP 358 DHCP Request  - Transaction ID 0x2af5de99
Frame 469: 358 bytes on wire (2864 bits), 358 bytes captured (2864 bits) on interface 0
Ethernet II, Src: HewlettP_c0:58:12 (1c:c1:de:c0:58:12), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol (Request)
 


471 59.540881 192.168.10.253 255.255.255.255 DHCP 342 DHCP ACK      - Transaction ID 0x2af5de99

Frame 471: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: CiscoInc_71:50:bf (54:75:d0:71:50:bf), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.10.253, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67 (67), Dst Port: 68 (68)
Bootstrap Protocol (ACK)



Teniendo claro como funciona nuestro escenario DHCP, es momento de ponerlo a prueba:


DHCP Starvation: Ataque DoS contra el servicio DHCP

La idea en este caso es inundar al servidor DHCP con peticiones DHCPDISCOVER desde diferentes direcciones MAC, de tal forma que agotemos su espacio de direccionamiento y el servidor DHCP no sea capaz de servir nuevas direcciones IP.

Una herramienta fantástica para implementar este ataque es Yersinia:

Yersinia  (Lanzar ataque - DHCP - Discover Packet)

Del lado del servidor podemos observar como:

El servidor DHCP atacado, comienza a recibir los DHCPDISCOVER y a ofrecer direcciones IP del pool a cada una de los clientes (direcciones MAC falsificadas):

Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from e0:bb:7b:38:32:c5 via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from 20:da:b8:2a:77:ab via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from e0:ad:9b:3e:f6:13 via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from 12:12:f0:2d:d0:0e via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from bc:ef:0e:29:c6:42 via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from 2a:61:1e:70:9e:25 via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from dc:e5:53:4a:5c:00 via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from 96:ac:03:49:c5:06 via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from 5a:a9:b3:64:67:fa via 192.168.10.253
Apr 19 13:54:19 dhcp dhcpd: DHCPDISCOVER from 4c:52:8b:0d:39:f6 via 192.168.10.253
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.133 to e0:bb:7b:38:32:c5 via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10143 to 20:da:b8:2a:77:ab via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.126 to e0:ad:9b:3e:f6:13 via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.127 to 12:12:f0:2d:d0:0e via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.131 to bc:ef:0e:29:c6:42 via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.124 to 2a:61:1e:70:9e:25 via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.123 to dc:e5:53:4a:5c:00 via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.132 to 96:ac:03:49:c5:06 via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.125 to 5a:a9:b3:64:67:fa via 192.168.10.253
Apr 19 13:54:20 dhcp dhcpd: DHCPOFFER on 192.168.10.135 to 4c:52:8b:0d:39:f6 via 192.168.10.253
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Del lado del atacante, podemos ver la generación de una enorme cantidad de paquetes Broadcast DHCP Discover, originados desde diferentes MACs, estos broadcast son recogidos por el Agente Relay (192.168.10.253) y reenviados al servidor DHCP.

El pool de 254 direcciones disponibles practicamente se agota de inmediato, a partir de ese momento, el servidor DHCP deja de poder atender sobre la Vlan correspondiente (Vlan10) las peticiones de otros clientes que deseen obtener direccionamiento IP en su conexión a la red.

Un cliente cualquiera que desee conectar a la red enviará peticiones DHCP Discover, sin respuesta alguna:

¿Por qué ha tenido éxito este ataque ?

Principalmente, porque el puerto de red al cual se ha conectado el atacante ha permitido  el tráfico desde  diferentes MACs address origen.

La solución sencilla pasaría por implementar Port Security, lo veremos en artículos posteriores.

Este tipo de ataque contra el DHCP son sencillos de implementar, pero también es sencillo su mitigación.

Este ataque se acompaña de un ataque posterior denominado DHCP Rogue, que nos permitirá controlar el direccionamiento IP de nuestras victimas.