martes, octubre 25, 2011

Ataque Man in the middle con DHCP ACK Injector

Si ayer os hablaba de GetMSNIPs para obtener las direcciones IP de los contactos del Messenger, hoy toca hablaros de otra herramientas más que han salido desde el departamento de Auditoría de Aplicaciones Web de Informática64 para ser usada en las clases del FTSAI, y que también se ha programado nuestro amigo Thor (@francisco_oca). Además de esta tool, en Seguridad Apple otro compañero, The Sur, ha revisado USB Dumping para robar datos de los pendrives enchufados a tu Mac OS X, con soporte para enviar los datos robados a servidores FTP. Además, ya está disponible desde hace poco tiempo C.A.C.A. la herramienta para hacer fingerprinting de aplicaciones en servidores Citrix que se picó nuestro compi Rodol. Ahora vamos con DHCP ACK Injector.

Introducción a los ataques Man in the middle

Hoy en día cuando se habla de realizar un ataque MITM en redes LAN a todos se nos viene a la cabeza el término ARP Poisoning. La técnica, a grandes rasgos, consiste en envenenar la cache ARP de un cliente de una red LAN para hacerle creer que la MAC de la puerta de enlace es la dirección MAC del equipo atacante, pudiendo de este modo situar la máquina del atacante en medio de las comunicaciones efectuadas entre el equipo víctima y la puerta de enlace. Con el siguiente gráfico sacado de la Wikipedia nos podemos hacer una idea de su funcionamiento:

Figura 1: ARP Poisoning

Sin embargo, para detectar estos ataques existen ya infinidad de herramientas  como ArpON, Patriot NG y nuestra querida Marmita que pronto verá la luz. Incluso para Mac OS X, nuestros compañeros de Seguridad Apple hicieron un script basado en nmap y arp_cop para detectar también los ataques man in the middle. Sin embargo, existe otra forma muy sencilla de realizar un ataque MITM en redes LAN utilizando el protocolo DHCP.

El Protocolo DHCP

Primero vamos a echar un vistazo al protocolo DHCP en Wikipedia:

DHCP (sigla en inglés de Dynamic Host Configuration Protocol - Protocolo de configuración dinámica de host) es un protocolo de red que permite a los clientes de una red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después.

Figura 2: Comunicación DHCP
Los pasos que definen su funcionamiento son los siguientes:

• El cliente envía un paquete DISCOVERY para que el servidor DHCP de dicha red de computadoras le asigne una Dirección IP y otros parámetros como la máscara de red o el nombre DNS.

• A continuación el servidor DHCP responde con un OFFER en el que suministra una serie de parámetros al cliente, IP, puerta de enlace, DNS, etcétera.

• El cliente selecciona los parámetros que le interesan y con un REQUEST solicita estos parámetros al servidor.

• Por último el servidor reconoce que se ha reservado correctamente los parámetros solicitados con un DHCP ACK y se los envía al cliente.

Una vez que conocemos como funciona el protocolo, ¿cómo podemos aprovecharlo para realizar ataques MITM?

Servidor DHCP falso: Roge DHCP Server

Una opción es configurar un servidor DHCP falso, por ejemplo con el demonio dhcp3 de Linux. De esta forma cuando el cliente envía un DISCOVERY responden con un OFFER tanto el DHCP real como el servidor DHCP que hemos montado en Linux. Pero ¿a quién hace caso el cliente? Pues al que consiga enviar antes al cliente la respuesta DHCP OFFER, unas veces puede ser nuestro servicio dhcp3, otras el servidor DHCP real.

Para realizar esto de una forma sencilla se puede utilizar el programa Ghost Phisher. Éste monta un servidor DHCP falso utilizando el servicio dhcp3, también permite montar un servidor DNS que resuelva determinadas direcciones o todas hacia una IP que le indiquemos.

Lo malo de este ataque es que podemos detectar fácilmente que existen 2 servidores DHCP. Con Wireshark mismamente podemos ver que responden a las peticiones DHCP dos direcciones IP distintas:

Figura 3: DCHP Offer desde distintas direcciones IP

Otro de los problemas es que necesitamos conocer a priori el rango de direcciones IP válidas y podría darse el caso de que nuestro servidor DHCP asigne direcciones IP que ya se encuentras asignadas a otros usuarios.

DHCP ACK Injection Attack

Figura 4: DHCP ACK Injection attack
Existe otro posible ataque. Dado que toda la comunicación DHCP se realiza enviando los paquetes a la dirección MAC de broadcast FF:FF:FF:FF:FF:FF todos los clientes de la LAN reciben los paquetes DHCP. Así que existe la posibilidad de que un atacante monitorice los intercambios DHCP y en un determinado punto de la comunicación envíe un paquete especialmente formado para modificar su comportamiento.

Uno de los puntos donde nos interesaría intervenir es cuando el servidor reconoce con un DHCP ACK la configuración del cliente. Primero se tiene que escuchar toda la comunicación poniendo atención en el paquete REQUEST donde el cliente solicita la IP, DNS, Gateway de aquellos datos que anteriormente le ha ofrecido el servidor DHCP.

Una vez recibido el REQUEST podríamos responder con un ACK como lo haría el servidor DHCP real pero estableciendo la configuración a nuestro antojo.

Ventajas e Inconvenientes de DHCP Injection Attack

La ventaja de este ataque es que no se necesita conocer el rango de direcciones IP válidas ni que direcciones están libres y cuales ocupadas. Dejamos que el servidor DHCP real nos dé toda esta información y solo se interviene en la fase final, en el reconocimiento que da el servidor sobre la configuración seleccionada.

Otra ventaja es que es más difícil de detectar a día de hoy que los ataques ARP-SPoofing. Solo se envía un paquete y este puede ser enviado con la IP spoofeada del servidor DHCP, y sería necesario que existieran reglas que validasen todos los paquetes DHCP de la red.

El problema como en el anterior escenario es que respondería tanto el atacante como el servidor DHCP real y el cliente solo hará caso al primero de ellos que responda. Algunas veces será más rápido el servidor DHCP otras nuestro programa.

DHCP ACK Injector 

Para automatizar este ataque en Informatica64 hemos desarrollado una aplicación en C#, es necesario tener instalado el .NET Framework 3.5. Aquí podemos ver su aspecto:

Figura 5: DHCP ACK Injector

En Wireshark la comunicación DHCP de un cliente que solicita una nueva dirección IP se ve así:

Figura 6: Captura de Wireshark con el DHCP Injection Attack

En rojo se han remarcado los dos paquetes ACK, el falso y a continuación el verdadero. La IP es la misma lo único que varía es la dirección MAC de origen del paquete ya que a los routers no les gusta mucho reenviar paquetes con su propia dirección MAC. Nótese que la diferencia entre el primer y el segundo ACK es de escasos 750 ms. Es importante responder lo más rápido posible.

En los detalles del protocolo DHCP podemos ver los datos falsos enviados en nuestro paquete ACK.

Figura 7: Detalles del paquete DHCP modificado

DHCP ACK Injector se ha desarrollado este mismo programa en C y, aunque ha sido desarrollado para Windows haciendo uso de WinPcap, creemos que no tendrá que ser muy complicado migrarlo a Linux, así que es probable que lo portemos.

Modo de uso:

DHCP ACK Injection Use: DHCPACKInjection.exe [-l|-i -g -d ]     
-l: List interfaces -i : Use the interface N        
-g : Change the gateway to IP_GATEWAY        
-d : Change the gateway IP to IP_GATEWAY

Figura 8: DHCP ACK Injector funcionando

Puedes descargar el programa desde DHCP ACK Injector.

18 comentarios:

Icko dijo...

Herramiente fucking increible. Un pasito más a dar en una auditoría.
Muchisimas gracias, chicos :)

kabracity dijo...

Esto siempre ha sido un quebradero de cabeza, incluso involuntariamente. Recuerdo haber tenido problemas, y descubrir que alguien había enganchado un router a la red, que estaba configurado como servidor de DHCP por defecto.

En el directorio activo, hay que autorizar el servidor DNS de cualquier equipo del dominio para que Windows Server lo permita, pero montando cualquier máquina fuera del dominio, un router, o una máquina Linux se salta rápidamente :(.

La RFC3118 salió para autenticar mensajes DHCP y evitar este tipo de ataques, pero no se ha usado casi por problemas de escalabilidad.

Sobre el ataque de inyección de ACK, ¿qué parámetros de pueden modificar que el cliente se "trague"? Lo digo porque según la RFC2141:

"Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The server SHOULD NOT check the offered network address at this point.

The 'yiaddr' field in the DHCPACK messages is filled in with the selected network address."

Anónimo dijo...

¿El DHCP snooping no tiene nada que decir aqui?

Thor dijo...

Gracias @Icko

@kabracity nosotros hemos probado a modificar el campo Gateway(bp_giaddr) y la dirección IP asignada(bp_yiaddr) seguramente sea posible modificar también la mascara de red.

@Anonimo DHCP snooping tiene mucho que decir, en breves publicaremos como defenderse de este ataque.

Anónimo dijo...

Esto huele y sabe a lo que es. MIERDA.

Anónimo dijo...

Desde la ignorancia,

Con esto lo que hemos conseguido es darle una IP diferente a la máquina víctima? Qué podemos hacer con eso?

Gracias

Eduardo dijo...

Entre otras cosas, ademas de una direccion IP diferente tambien le has podido dar, que se yo, un gateway diferente, y que todo el trafico pase por tu equipo para hacer un poco el mal y despues darle tu salida a la wan (internet/intranet) para que la cosa no se note...
...Por poner un ejemplo...

Rubén Crespo dijo...

¿La herramienta creada en C# con Visual Studio también hace uso de la librería WinPcap?

¿Sería esta la única forma de poder analizar el tráfico? ¿O existe alguna otra librería que te permita escuchar tráfico y utilizarlo en el desarrollo de tu propia herramienta?

Gracias!

Thor dijo...

@Rubén Crespo
Antes era posible también usando raw sockets, pero en las últimas versiones de Windows esto no es posible.
Fijate en el apartado "Limitations on Raw Sockets" de este artículo:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740548(v=vs.85).aspx

Anónimo dijo...

Estos son las publicaciones que me gustan! Muy bien explicado, se ha entendido a la perfección y me han dado ganas de enchufar mi wireshark y trastear con mi intranet :P

imaginawireless dijo...

Para evitar que el nuestro servidor DHCP faje sea el primero en llegar con su respuesta,

¿sería posible secuestrar todas las Ips de la red? Os explico la idea...

Supongamos que hacemos un software que fuera cambiando automáticamente la MAC de nuestro dispositivo y solicitando una IP al DCHP principal. Una vez que se ha alcanzado el número máximo de IPs que puede entregar, el DHCP no entreverá más IPs durante el tiempo de vida útil de estas cesiones, y con nuestro DCHP fake podriamos llegar sin problemas a todos los equipos de la red, sin ningún conflicto.

Lo que no tengo tan claro en como se engañaría al DHCP principal para que las IPs que ya ha asignado, se liberen para ser secuestradas, y no esperar a que se acabe el tiempo de vida de la misma.

Otra ventaja de esto es que tendríamos un control absoluto del rango de IPs de el DHCP principal.

Maligno dijo...

@Imaginawireless seguro que alguna se puede hacer con eso... }:))

Sam dijo...

Perdonad mi ignorancia: una vez dada la puerta de enlace spoofeada a la víctima (con la de por ejemplo una máquina windows), ¿cómo hacemos para redireccionar el tráfico entrante a la puerta de enlace real? ¿Con un proxy o gateway software? ¿Existe alguna apliación que directamente se le pueda indica que los datos recibidos por equipo con una MAC o IP determinada salgan a Internet a través del router real y luego puedan viajar de vuelta al equipo de la víctima?
Gracias, un saludo.

Maligno dijo...

@Sam, si te convertes en su gateway, todo pasa por allí. Tú solo tienes que darle conexión a Inet y listo.

Saludos!

Sam dijo...

Gracias Chema, lo que me falta es alguna herrameinta para ello (el concepto lo tengo claro, si soy la puerta de enlace, tengo que actuar como tal): he probado con un proxy http transparente, pero no quiero tener que limitarme al tráfico web, y no he encontrado ningún gateway SW para windows que pueda configurar (y he buscado, lo prometo con la mano en el pecho...). ¿Alguna pista o sugerencia de algo que hayáis probado?
Gracias una vez más y un saludo

Anónimo dijo...

Señores muchas gracias por todas sus publicaciones.

Thor, no habria forma de publicar el codigo de la aplicacion?

Creo que este se podria modificar de cierta forma para detectar servidores DHCP falsos.

Anónimo dijo...

Algun "tutorial" ?

Anónimo dijo...

Amoh a vé...

¿Difícil de detectar?
Si el usuario hace un tracert o tracepath a google.com y no sale el gateway (puerta de enlace) de su router, ¿qué?

Eleven Paths Blog

Seguridad Apple

Entradas populares