domingo, 1 de junio de 2008

Evadiendo Snort con Paquetes Fragmentados

Hace unos días, iDefense publico un advisory sobre una vulnerabilidad en el preprocesador Frag3 de Snort que permitiría evadir la detección de un ataque con paquetes fragmentados.

Definitivamente esta vulnerabilidad no tuvo el mismo impacto mediático que la catástrofe criptográfica de Debian, pero que todas las redes protegidas por Snort, hayan sido susceptibles a ataques de los que nadie se ha enterado, no es para nada poca cosa.

Parte del advisory de iDefense decía lo siguiente:

"Due to a design error vulnerability, Snort does not properly reassemble fragmented IP packets. ... In order to exploit this vulnerability, an attacker would have to fragment IP packets destined for a targeted host, ensuring that the TTL difference is greater than the configured maximum. By default, the maximum difference is 5."

¿ Cuál es el problema ?

Básicamente, el problema se debía a la opción "ttl_limit" de frag3, que por default tiene un valor de 5. Esto significa que si llegaba un fragmento con una TTL de 40, y luego otro con una TTL de 46, debido a la vulnerabilidad encontrada estos fragmentos no serían controlados por la política de Snort.

Al parecer esto se debió a un error de concepto introducido en Snort 2.6 y 2.8, y que ha sido corregido por Sourcefire en el nuevo release 2.8.1. iDefense también propone un workaround a este problema, que consiste en llevar el "ttl_limit" a su valor máximo de 255.

¿ Qué es frag3 y porque controla la TTL ?

frag3 es un preprocesador de Snort. Un preprocesador sirve para detectar ataques que no pueden ser detectados mediante una comparación de firmas, o para normalizar datos que luego si puedan ser detectados por comparación de firmas. En particular, el preprocesador frag3 se encarga de reensamblar paquetes fragmentados para poder comparar el payload con firmas de ataques.

Una de las técnicas mas usadas para evadir un IDS es la fragmentación de paquetes, por lo que frag3 no solo reensambla los paquetes, sino que también verifica que no se este intentando realizar una evasión mediante paquetes fragmentados, y aquí es en donde entra en juego el control de la TTL.

frag3 posee 2 opciones para controlar la TTL, una es "min_ttl" y la otra es "ttl_limit", en la cual se descubrió la reciente vulnerabilidad. Veamoslas un poco más:

- min_ttl: Indica el valor mínimo de TTL que debe tener un paquete para ser aceptado. Esto es útil para detectar ataques de evasión en los que entre nuestro IDS y el target hay un router. La idea de estos ataques es enviar un paquete fragmentado con una TTL muy chica que al pasar por el router expire.

Por ejemplo, mandamos 3 paquetes fragmentados a un target, el primero y el tercero poseen un payload de ataque y una TTL alta, mientras que el segundo paquete posee un payload con datos basura y una TTL muy chica. Cuando Snort reensamble los 3 paquetes, se mezclará el payload de ataque con los datos basura, y ninguna comparación de firmas detectará el ataque. Como el segundo paquete tiene una TTL muy chica, va a expirar cuando pase por el router, y solamente llegarán al target el primer y el tercer paquete, que efectivamente tenían el payload de ataque.

- ttl_limit:
Como ya dijimos, esta opción controla la diferencia máxima del valor de la TTL que puede haber entre paquetes fragmentados con el mismo ID de fragmentación. Según se ha publicado, esto es un error de diseño que ya se venía arrastrando de versiones anteriores de Snort con frag2, y que en el futuro será descontinuado.

Al parecer, esta opción fue agregada porque herramientas como Fragroute, para realizar ataques de evasión con paquetes fragmentados, configuraban los campos de los paquetes con valores al azar que raramente se veían en tráfico normal. Por ejemplo, una diferencia de TTL de hasta 5 saltos podría llegar a ser normal ya que es posible que un paquete haya tomado una ruta mas larga, pero según entiende Snort más de 5 saltos ya es algo más raro.

Bueno, saludos a todos los administradores de Snort que seguramente deben tener mucho trabajo, primero corrigiendo esta vulnerabilidad, y después averiguando si en algún momento los han hackeado sin enterarse ;-)

Más info:
- iDefense Advisory
- Diff for /preprocessors/spp_frag3.c
- Snort: Frag3
- Eluding Network Intrusion Detection
- SecurityFocus: Evading NIDS, revisited

2 comentarios:

Anónimo dijo...

Me parece interesante esta vulnerabilidad , pero seria mucho mas conocer los flags en la herramienta que mencionas o algun tipo de PoC para realizar este tipo de ataque, tendras mas informacion de como realizar este ataque? Algun PoC o los pasos para hacer un buen ataque de fragmentacion ? me refiero mucho a los comandos que debemos hacer

-sergio

KungFooSion dijo...

Hola Sergio,

Para esta vulnerabilidad no se publico ningún PoC, y por lo que vi con Fragroute tampoco se podría hacer porque no deja configurarle una TTL específica a cada segmento, lo hace para todos por igual. El resto de los conocidos ataques de fragmentación que aparecen en el paper de Ptacek/Newsham, sí los podés realizar sin problemas usando Fragroute.

Si bien no probé hacer un PoC para esta vulnerabilidad, más que nada por falta de tiempo, no me parece que sea demasiado complicado y con Scapy lo podés hacer seguro.

Algunas puntas para probar:

Scapy tiene una función llamada fragment() que te fragmenta los paquetes automáticamente, en este caso es el famoso Ping of Death:

send(fragment(IP(dst="1.1.1.1")/ICMP()/("X"*60000)))

Tal vez se pueda usar esta función con el campo "ttl" para que lo incremente de a 6, hay que probarlo. Sino, otra es armar el paquete a mano:

send(IP(dst="target", id=31, ttl=40, flags="MF")/"PAYLOAD DEL ATAQUE")
send(IP(dst="target", id=31, ttl=46, flags="MF")/"PAYLOAD DEL ATAQUE")

Calculo que esto debería funcionar, la clave es que el ID sea el mismo, para identificar los mismos segmentos a reensamblarse, y que la TTL se incremente de a 6. Después le tendrías que poner el payload del ataque que querés realizar.

Hay que probarlo... a mi me interesa bastante este tema, así que apenas tengo un poco más de tiempo para investigar escribo un post más técnico con ejemplos para realizar este tipo de ataques.

Si lo probas y lo haces funcionar, avisa! ;)

LinkWithin