lunes, 28 de junio de 2010

IP DEfragmentation & Snort

En la entrada de la semana pasada introdujimos algunos conceptos de IP Fragmentation, qué es un IP Fragmentation Overlapping, y realizamos un pequeño ejemplo con FragRoute en el que realizábamos una conexión contra un sistema Windows, fragmentando con un overlapping de tal forma que solo fuera reconstruible por sistemas Windows, y lo comprobamos usando un sistema Linux.

Pero... ¿está todo perdido? ¿no podemos obtener la conexión original de ninguna forma a partir de la captura de red?

Por supuesto, la respuesta es SI, claro que podemos obtener la conexión original a partir de la captura de red, solo necesitamos... "pensar" como el servidor destino de la conexión, respirar lo que él respira, comer lo que él come, y defragmentar como él defragmenta :P

La idea más inmediata es disponer de al menos un sistema de cada uno de los tipos de defragmentado que comentamos en la anterior entrada, con el Wireshark instalado y, simplemente, abrir la captura de red para que defragmente de la manera que lo haría ese sistema, pero...


Podemos ver como la misma captura, abierta con un Windows, muestra el mismo resultado que cuando la abrimos desde un Linux, así que no hemos solucionado nada nuestro problema. Según parece, Wireshark no utiliza la pila TCP/IP del sistema en el que se ejecuta para realizar el refragmentado, sino que utiliza un módulo propio, como podemos ver en la siguiente captura de la ventana que se encuentra en Preferencias->Protocolos->IP.


Vale, opción uno a la basura, ¿qué hacemos ahora? La lógica dice que no sería raro que existiera algún tipo de herramienta que le pasaras como parámetros un pcap y algún tipo de fichero de configuración de que tipo de defragmentado quieres para cada uno de los hosts, y te devolviera un pcap con los fragmentos ya reconstruidos. Sin embargo, yo no conozco o hasta ahora no he encontrado una herramienta que haga algo así (si alguien conoce una, que lo diga), así que la opción dos se nos va a la basura también.

Muy bien, no tenemos una herramienta que haga directamente lo que queremos, pero sí hay herramientas que están preparadas para realizar estos refragmentados, y es posible que pudiéramos "tunearlas" para obtener el pcap de la manera que queremos. Estoy pensando claramente en los Sistemas de Detección de Intrusos basados en Red (NIDS). ¿Recordáis que comentamos que las técnicas de IP Fragmentation Overlapping podían ser usadas para evadir las protecciones de los IDS? Pues los fabricantes de IDS no se han quedado con los brazos cruzados, y muchos de ellos realizan una especie de "emulación" de las distintas maneras de refragmentar que existen.

Preprocesador Frag3

En el caso de Snort, uno de los NIDS más utilizados de la actualidad, la respuesta es el preprocesador frag3. Una vez configurado, este preprocesador es el encargado de recomponer el paquete de la misma forma que lo hará el sistema destino de la conexión, para que de esta manera ambos puedan ver el mismo paquete, y por tanto comprobar las firmas de ataques de forma efectiva.

Para configurar correctamente el preprocesador frag3 deberemos editar el fichero /etc/snort/snort.conf (en BackTrack, en otros sistemas podría cambiar de lugar) y buscar la cadena "frag3", que nos llevará a la zona del fichero de configuración en la que deberemos configurar el preprocesador. En la zona comentada podemos ver con todo detalle como configurar este preprocesador. En este caso, tenemos una captura de red con los paquetes y fragmentos creados el post de la semana pasada, contra un Windows en la IP 172.16.25.151, así que tenemos que hacerle saber a frag3 que lo que hay detrás de esa IP es un Windows. Para ello, añadiremos las siguientes lineas al final de todos los comentarios de la zona de configuración del frag3:

preprocessor frag3_global: max_frags 65536
preprocessor frag3_engine: policy windows bind_to 172.16.24.151

El frag3_global es algo que se tiene que poner una vez al principio de las frag3_engine. Este sería un buen valor por defecto.

Vale, ya le hemos dicho a Snort que 172.16.24.151 es un Windows, así que ahora cualquier paquete fragmentado que vaya contra esa dirección debería ser correctamente defragmentado, pero... ¿cómo conseguimos obtener el pcap resultante tras defragmentar?

Output Plugin log_tcpdump

Aunque la salida típica de Snort es un log texto, existen una gran cantidad de plugins de salida que podemos utilizar para obtener una gran variedad de salidas. Entre ellas, existe la posibilidad de conservar el paquete entero mediante el plugin log_tcpdump, el cual será guardado en formato pcap, tal y como queremos.

Para activar este plugin de salida deberemos editar de nuevo el fichero /etc/snort/snort.conf y buscar la cadena "log_tcpdump" para llegar a la zona de este output plugin. Para activarlo, únicamente deberemos añadir la siguiente linea:

output log_tcpdump: tcpdump.log

Mediante esta linea, cada vez que algún paquete haga match con alguna de las reglas de snort, además de las otras salidas que hay configuradas, se nos guardará el paquete completo en un fichero tcpdump.log.[timestamp] en el directorio en el que hayamos configurado que se guarden los logs (en BackTrack: /var/log/snort/).

Perfecto, ya casi lo tenemos, pero... yo no quiero obtener un pcap con los paquetes que hagan match con algún ataque, yo quiero simplemente TODOS los paquetes, pero defragmentados, obviando las reglas de Snort ¿cómo podemos hacer eso?

Regla MatchAll para Snort

Bueno, si el problema es que solo vamos a obtener el pcap de los paquetes que hagan Match con alguna de las reglas de Snort y nosotros los queremos todos los paquetes... la solución parece fácil, creemos una regla de Snort que haga match con cualquier paquete, así en cualquiera de los casos todos los paquetes de nuestro pcap inicial harán match con alguna regla, así que todos ellos serán registrados en formato tcpdump tal y como queremos.

La regla podríamos afinarla todo lo que queremos para que nos registrara una conexión concreta, pero en este caso vamos a utilizar una que sencillamente haga Match con cualquier paquete de una conexión TCP. Para ello editamos el fichero /etc/snort/rules/local.rules y añadimos la siguiente regla:

alert tcp any any -> any any (msg:"ALL MATCH"; sid:1000001; rev:1;)

Bueno, parece que ya lo tenemos todo: Snort está preparado para defragmentar nuestro pcap, todos los paquetes resultantes de la defragmentación van a hacer match con una regla, y por tanto van a ser registrados en un pcap de salida. Ahora solo nos queda... pasarle este pcap a Snort de alguna forma, ya que por defecto este obtiene los paquetes sniffando directamente de la red.

Snort sobre un fichero PCAP

Además de ser lanzado para sniffar una interface de red, Snort puede ser lanzado pasándole como argumento (con la opción -r) un fichero pcap del cual obtendrá los paquetes de la misma forma que lo haría de un interface de red. Esta opción puede resultar muy útil en una investigación forense en la que disponemos de una captura de red, porque podemos identificar mediante Snort ataques conocidos o firmas de gusanos que se propaguen por la red, pero en este caso nos va a venir bien, simplemente, para defragmentar el pcap que hemos obtenido:

/usr/local/bin/snort -c /etc/snort/snort.conf -r fragmentado.pcap

Una vez lanzado, veremos que en el directorio /var/log/snort/ (o en el que tengáis configurado que se guarde la salida de Snort aparecen dos ficheros, un fichero "alert" típico de Snort con la salida en texto, y un fichero "tcpdump.log.[timestamp]" que debería contener nuestra conexión ya refragmentada de la misma forma que lo haría un Windows:


Como podemos ver, los fragmentos IP han desaparecido, no hay errores de Checksum (señal de un mal defragmentado) ni nada que no parezca una conexión TCP normal. Comprobémoslo realizando un "Follow TCP Stream" de la conexión:


Parece que esta vez sí que hemos conseguido defragmentar correctamente la conexión, porque vemos una comunicación HTTP que tiene toda la pinta de ser auténtica, y no con las cadenas basura que veíamos en la captura del inicio de esta entrada.

A partir de aquí a analizar, a ver que es eso que "los malos" han puesto tanto empeño en esconder detrás de una fragmentación con overlapping.

14 comentarios :

vierito5 dijo...

Genial el post!

Jose Selvi dijo...

@vierito5: Gracias! Es todo un cumplido viniendo de ti ;)

mgesteiro dijo...

buena segunda parte! :)

Jose Selvi dijo...

@mgesteiro: Lo siento, te he medio jodido lo de utilizarlo en tus HackContest xDD

Gracias por el comentario!
Saludos!

neofito dijo...

Muy bueno, al igual que el anterior.

Saludos

EgoPL dijo...

Esto si da gusto leerlo, muy bueno.

Anónimo dijo...

Una obra maestra. Como siempre, perfectamente explicado.
Un 10!

Jose Selvi dijo...

Gracias a todos por vuestros comentarios ;)

Unknown dijo...

A ver si me meto más en serio con wireshark y con snort para conseguir entenderlo del todo, :)

Gracias por los artículos.

NaCl u2

Jose Selvi dijo...

@Rigolox: Si te lo miras y tienes dudas dejanos un comentario o mandanos un correo. Suerte! ;)

Unknown dijo...

Hola, quiero aclarar que no soy informático ni ingeniero ni nada parecido, de hecho soy Biólogo, pero hace una par de años que estoy metido en esto de la seguridad, tu trayectoria es impresionante, y me anima a apreder cada día mas (desafortunadamente descubrí la Seguridad Informática algo tarde), actualmente estoy tratando de implementar Snort como NIDS en la red de mi trabajo, descubrí que es muy fácil penetrar los equipos de mi red desde adentro, tomar información y andar usmenado por ahí sin que nadie se de cuenta, utilizando BT4 realice varias pruebas en muchos de los equipos, econtre usuarios por default, contraseñas débiles, SO no parchados o sin actualizaciones, use Nmap, Netcat, Autoscan y otras en algunos servidores de archivos... y nada, o al menos nadie esta monitoreando la red ni los logs de los equipos, no hay conciencia de los usuarios respecto al manejo de información, no tenemos mucho presupuesto y pense en usar software libre solamente, tratamos de trabajar con OSSIM, pero terminamos por desecharlo y ahora estamos implementando Snort, Ntop, OCSInventory, OpenVas y Nagios como herramientas que nos sirvan para alcanzar nuestros objetivos, lo que mas me ha costado trabajo aprender es a configurar Snort, de hecho aún no termino, y tengo muchas dudas, pero me agradaría que me dijeras si voy por buen camino al utilizar estas herramientas, me agradaría una opinión tuya!!! saludos y excelente Blog.

Jose Selvi dijo...

@Edgar: Gracias por tus palabras, me alegra mucho que el blog te resulte de utilidad :D

Las herramientas que comentas... no vienen todas o casi todas integradas con OSSIM?

En cualquier caso, vas por buen camino, aunque si tienes aplicaciones web tendrás que buscar algún otro tipo de herramienta, porque OpenVAS (hasta donde yo sé) no realiza ningún tipo de chequeos sobre las aplicaciones web.

Snort es una maravilla, desde mi punto de vista una de las joyitas del mundo OpenSource, pero como tu dices es complicado de configurar. Simplemente te puedo decir que tengas paciencia, que le pegues una buena leída a la documentación y te vayas marcando que cosas crees que os pueden resultar útiles.

Estoy seguro que también podrás encontrar documentos que explican configuraciones buenas "a priori" para Snort, pero en este momento no tengo ninguna en la cabeza, lo siento.

Suerte!

Luis Torres dijo...

Muy bueno el artículo. Para este tipo de técnicas deberían aplicar Hashing así como se hace con los datos!!! Generalmente con un checksum también debería verificarse la integridad y secuencia de los paquetes en la red, pero en el caso de TCP/IP me parece que deberían de integrarlo con alguna técnica parecida al hashing para que se pueda validar la conexión de acuerdo al IPID de la red. No se si estoy hablando de dos cosas diferentes pero si quisiera saber si se podría hacer!!!

Jose Selvi dijo...

@Luis Torres: En realidad el CRC no es "tan distinto" de un Hash en el sentido de que ambos sirven para comprobar la integridad de algo.

La diferencia es que un Hash como un MD5, SHA-1, etc, es que es mucho más difícil de hacerlo colisionar (encontrar dos contenidos diferentes de los que salga el mismo hash). Los cálculos que se hacen son muchos más complejos, precisamente para intentar evitar que la colisión sea sencilla. Esto se usa para integridad de ficheros para evidencias forenses, y cosas así.

Un caso muy distinto es el de las cabeceras IP. En este caso el CRC es mucho más sencillo, tanto como un simple Checksum (sumar todos los bytes de la cabecera IP). No tiene tantas garantías de integridad, por lo que resultaría sencillo de hacerlo colisionar, pero sin embargo su cálculo es EXTREMADAMENTE SENCILLO, y eso resulta muy útil, ya que son los routers (máquinas a priori poco potentes y que van a tener que calcular la integridad de muchos paquetes por segundo) los encargados de procesar y comprobar este CRC.

Por otro lado, el IPID no tiene nada que ver con la red, es simplemente un numerito aleatorio que se asigna a los fragmentos que se obtienen de la fragmentación de un mismo paquete.

No sé si te estoy respondiendo, porque la verdad es que no acabo de entender demasiado tu duda.

Dame más detalles y le pegaré una pensada ;)
Saludos!