Defensas frente a ataques DHCP
A raíz del post de @chemaalonso [1] sobre la herramienta DHCP Ack Inyector [2], recordé mis años en la universidad (allá por el 2005) donde ibas a la biblioteca, conectabas tu portátil y simplemente escuchando tráfico veías multitud de protocolos vulnerables o incorrectamente configurados como STP, HSRP, DTP, etc.
No solo eso, sino que no había ningún tipo de control sobre el tipo de datos que los usuarios podían enviar, por lo que, utilizando herramientas como Gobbler, dsniff, ettercap, yersinia, etc., podías llevar todo tipo de ataques man-in-the-middle. Lo curioso de todo era que la mayoría de los dispositivos de networking utilizados para gestionar todo el tráfico eran Cisco. Es decir, dispositivos más que suficientes para poder controlar y mitigar prácticamente la mayoría de esos ataques. Simplemente estaban configurados para cumplir con funciones básicas de red: enrutar tráfico, administrar VLANS, ACL, QoS, etc., pero o bien por desconocimiento o por descuido, no se les estaba sacado el provecho que realmente justificaría su adquisición.
Con el paso del tiempo me he dado cuenta de que este tipo de situación es bastante frecuente: es realmente difícil encontrar una empresa que tenga en cuenta políticas de configuración estrictas para asegurar un entorno local. Personalmente pienso que muchas organizaciones no son conscientes del daño que podría hacer un empleado descontento en un entorno local “poco controlado”. Sin llegar a utilizar herramientas sofisticadas como Loki o Yersinia [3], es posible desde tirar toda una red con apenas un par de paquetes y con ayuda de Scapy, hasta hacer MitM usando ARP / DHCP /VRRP [4] / HSRP o hasta cosas mas entretenidas como conseguir un pool de shells sin mucho esfuerzo con el browser_autopwn de Metasploit y etterfilters. [5]
En este caso, y a raíz del post de Chema, me gustaría hablar sobre ciertas medidas de seguridad, bien conocidas desde hace tiempo, que ayudarían a protegerse frente a herramientas como DHCP Ack Inyector y que hacen un mal uso del protocolo DHCP (IP Spoofing Attacks, Discover DoS attacks, etc.). Como se indica en su blog [6], DHCP Ack Inyector tiene un comportamiento algo diferente a herramientas como Ghost Phisher o cualquier otro fake DHCP server que pudiera instalarse (dhcp3, auxiliary / server / dhcp en Metasploit, etc.), para enviar información falsificada al cliente. En lugar de usar paquetes DHCPOffer, utiliza respuestas DHCPAck al contar con la ventaja adicional de conocer los datos ofrecidos previamente por el servidor y que se obtuvieron gracias albroadcast DHCPRequest emitido por la víctima, una técnica bastante astuta.
Sin embargo no es suficiente para eludir VACL (Vlan Access List) que controlen el trafico UDP dirigido a los puertos 68 y 67 o contramedidas más serias como DHCP Snooping implementadas en dispositivos Cisco. En el primer caso, cualquier switch que soporte VACL podría configurarse para bloquear tráfico UDP proveniente del puerto 67 para aquellos puertos destinados al usuario final. El problema de esta contramedida es que podría evadirse fácilmente si se falsifica la MAC e IP de los paquetes (y que en el caso de DHCP Ack Inyector es posible), por lo que para una protección más fiable tendríamos que recurrir a otros mecanismos de seguridad como DHCP Snooping.
La idea de esta funcionalidad es diferenciar entre dos tipos de puertos en un entorno conmutado: por una lado puertos confiables (trusted port) y, por otro, puertos no confiables (untrusted host). Los primeros no tendrán restricciones de cara al tipo de mensajes DHCP que puedan recibir, puesto que serán aquellos conectados a un entorno controlado (en este caso a los servidor/servidores DHCP). Sin embargo, los segundos únicamente podrán enviar aquellos paquetes que en condiciones normales un cliente necesita enviar para conseguir su configuración DHCP (DHCPDiscover,DHCPRequest, DHCPRelease). Los untrusted port por tanto serán configurados en aquellos puertos conectados a los usuarios finales y en el caso de que dicho puerto reciba un paquete spoofeadoDHCPoffer, un DHCPack, o DHCPNack (este es el caso de DHCP Ack Inyector), serán bloqueados.
Para llevar a cabo este proceso, el switch mantiene una tabla (binding table) que irá construyendo a medida que reciba la información del servidor DHCP legítimo durante la negociación de los clientes (aunque también es posible añadir entradas automáticamente, véase comando ip dhcp snooping [7]). En esta tabla se almacenará la siguiente información asociada a los untrusted ports: MAC address, IP address, lease time, binding type, VLAN, e interfaz. Esta información podrá ser utilizada además por otras funcionalidades de seguridad como DAI (Dinamic Arp Inspector [8]) para mitigar arp-spoof o IP Source Guard que veremos más adelante. Veamos un ejemplo de configuración:
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10
Switch(config)# interface Fastethernet 0/5
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit rate 10
Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/5 yes unlimited
Binding Table:
Switch#show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:01:02:03:04:05 10.0.0.1 86250 dhcp-snooping 10 FastEthernet0/5
Con DHCP Snooping no solo podremos mitigar ataques de este tipo (rogue server), si no también defendernos frente a DHCP exhaustion attacks, donde un atacante es capaz de acabar con el poolde direcciones libres del servidor DHCP en cuestión de segundos, mediante el envio de paquetes DHCP Discover solicitando nuevas direcciones IP.
Aunque podría pensarse que contramedidas como Port Security [9] serían más que suficientes para evitar este tipo de ataques, en realidad no lo es con determinadas herramientas como Yersiniao dhcpstarv. El motivo es que port security únicamente considera la MAC origen de la trama para crear filtros y establecer así que direcciones MAC están permitidas en un puerto determinado (útil para combatir MAC flooding attacks). El problema aquí es que estas herramientas no modifican tal MAC (como hace por ejemplo macof [10]), sino que aleatorizan el campo Client Hardware Address (CHADDR) dentro del propio payload DHCP. Este campo, junto al client identifier, es de gran importancia ya que será utilizado (véase RFC 2131 [11]) por el server para diferenciar entre las diversas peticiones de los diversos clientes, y que sin los cuales sería complicado distinguir entre los diversos usuarios en el caso de utilizar un DHCP Relay Agent.
dhcpstarv -i wlan0 -vDHCP Snooping tiene la inteligencia necesaria para leer el payload del propio protocolo DHCP y verificar que la dirección MAC origen y el CHADDR coinciden (comando opcional ip dhcp snooping verify mac-address). Además, puede establecer un “maximum threshold“, o número de paquetes por segundo que el switch puede recibir en un puerto determinado de forma que, si el número de paquetes DHCP alcanza dicho umbral, el puerto entraría en modo shutdown (bloqueo) y se generaría la alerta pertinente sobre dicho DoS.
Si se sospecha que se está haciendo un mal uso de DHCP podemos capturar tráfico dentro del mismo dominio broadcast en el que se encuentran los clientes mediante VACL, port-mirroring, etc. y filtrar por paquetes DHCPOffer y DHCPAck. Veamos la salida generada desde Wireshark:
Como vemos existen dos respuestas DHCPAck prácticamente enviadas en el mismo momento, comportamiento algo extraño. En el caso de DHCP Ack Inyector, por algún motivo no mantiene algunos campos como el “Server Host Name” así que podría servir como filtro (bootp.server == "" && bootp.option.type == 03) para buscar respuestas DHCPAck sospechosas.
Por último, indicar que la binding table generada por el DHCP Snooping puede utilizarse también para detectar IP Spoofing gracias a IP Source Guard [12]. Esta funcionalidad impide que los equipos conectados a puertos no confiables envíen paquetes hasta que no negocien dinámicamente su IP mediante el proceso de DHCP Snooping o bien se añada una entrada estática a la binding table(véase comando ip verify source vlan dhcp-snooping port-security). Posteriormente, una vez asignada una IP, una ACL será aplicada a dicho puerto y cualquier paquete con IP origen diferente a la almacenada en la binding table será eliminada.
Contar con dispositivos capa 2 que implementen medidas similares a DHCP Snooping, DAI, IP Source Guard, Port Security, 802.1x authentication [13], etc. pueden ahorrar verdaderos dolores de cabeza a los administradores de red. La inversión, por tanto, en un switch de estas características, siempre y cuando se saque partido de todas estas funcionalidades, puede estar más que justificado para un entorno en el que prime la seguridad (confidencialidad, integridad y disponibilidad) de la información.
URL to article: http://www.securityartwork.es/2012/03/07/defensas-frente-a-ataques-dhcp/
URLs in this post:
[1] @chemaalonso: http://twitter.com/#!/chemaalonso
[2] DHCP Ack Inyector: http://www.elladodelmal.com/2012/02/dhcp-ack-injector-se-hace-mas-selectivo.html
[3] Yersinia: http://www.yersinia.net/
[4] VRRP: http://www.securityartwork.es/2011/10/18/man-in-the-middle-en-entornos-vrrp-ii/
[5] con el browser_autopwn de Metasploit y etterfilters.: http://www.hackyeah.com/2010/10/ettercap-filters-with-metasploit-browser_autopwn/
[6] en su blog: http://www.elladodelmal.com/2011/10/ataque-man-in-middle-con-dhcp-ack.html
[7] ip dhcp snooping: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/12ew/configuration/guide/dhcp.pdf
[8] Dinamic Arp Inspector: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html
[9] Port Security: http://www.cisco.com/en/US/docs/swit.../port_sec.html
[10] macof: http://packetstormsecurity.org/files/11920/macof.sniff.dos.switched.txt
[11] RFC 2131: http://www.ietf.org/rfc/rfc2131.txt
[12] IP Source Guard: http://www.cisco.com/en/US/docs/swit...html#wp1149156
[13] 802.1x authentication: http://www.cisco.com/en/US/docs/swit...e/Sw8021x.html
