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.

IP Fragmentation Overlap & Fragroute

Hace algunas semanas vi en una de las pruebas de las PreQuals de la DEFCON una prueba (c500) en la que había que analizar una captura de red y obtener de ahí la solución. Como técnica de "ofuscación" del contenido de la comunicación, pareció haberse usado una técnica de IP Fragmentation Overlap, entre otras. Veamoslo rápidamente:

No vamos a entrar a la resolución de este reto, por ser algo más complejo, pero simplemente queremos haceros notar la existencia de IP Fragmentation Overlap, ya que los offsets de los fragmentos van de 40 en 40 bytes y sin embargo algunos paquetes contienen 80 bytes de datos.

Pero creo que nos estamos adelantando un poco, y este reto nos da pie para hablar un poco de la Fragmentación de paquetes IP, del Fragmentation Overlap y a poner un par de ejemplos usando Fragroute, una herramienta especialmente pensada para este tipo de ataques. No nos gusta mucho "soltar el rollo", pero en este caso creemos que es necesario para entender bien estos ataques.

¿Qué es IP Fragmentation?

Como ya sabéis, según el modelo TCP/IP, un Datagrama IP será "encapsulado" (para que nos entendamos) en algún tipo de protocolo a nivel de enlace, en redes locales generalmente Ethernet, pero podría usarse cualquier otro medio, en función del enlace que vayamos a usar. Cuando vamos a realizar esta "encapsulación", tenemos un requisito que tenemos que tener en cuenta, y es el llamado MTU (Maximum Transmission Unit) de dicha red, que es diferente según el tipo de red que vayamos a usar.

Para que nos hagamos una idea, es como si el Datagrama IP fuera un salami, y lo queremos meter en un buzón para que sea enviado. Si la rendija del buzón es más grande que nuestro salami, no hay problema, se mete entero y listo, pero... ¿qué pasa si la rendija es más pequeña? En ese caso tendremos que sacar un cuchillo y trocear nuestro salami de alguna manera, meter cada uno de los trozos en un sobre diferente y enviarlo por partes.

La única pega con esto es que, aunque el salami nos llegue a trozos, nos da igual por donde empezar a comerlo, pero con los fragmentos de un datagrama IP no pasa lo mismo, ya que tienen un orden que deberemos respetar. Para garantizar que estos fragmentos son "reensamblados" en destino de la misma forma, el protocolo IP cuenta con estos dos campos:

• IPID: Es el número que identifica a todos los fragmentos de un mismo paquete. Si un montón de fragmentos IP tienen el mismo IPID, quiere decir que deberán ser reensamblados en el mismo paquete.
• Offset: Es la posición en bytes que ocupará el fragmento desde el inicio del paquete. De esta forma, el fragmento con offset=0 será el primero, el offset=X (siendo X la cantidad de bytes en los que hemos troceado) será el segundo, offset=2*X será el tercero, y así sucesivamente hasta reensamblar el paquete completo.

Por lo tanto, ya sabemos que existe una técnica para trocear los datagramas IP si no "caben" en nuestra red y luego reensamblarlo en destino, pero... ¿como afecta esto a la seguridad?

En primer lugar, podemos forzar que se realice una fragmentación siempre que queramos, aunque el MTU de nuestra red no lo requiera, y en segundo lugar, podemos crear "anomalías" en la fragmentación que nos haga encontrarnos ante excepciones del protocolo que no están resueltas de una manera estándar, y que por tanto cada fabricante de sistemas operativos puede haber resuelto de forma diferente. Una de las maneras de hacerlo es un IP Fragmentation Overlap.

¿Qué es un IP Fragmentation Overlap?

Hemos dicho que el IPID identifica a todos los fragmentos que deberán ser recompuestos en un mismo datagrama IP, y que el Offset nos señala a partir de donde deben reensamblarse dichos datos. En un caso de fragmentación normal, si por ejemplo hemos partido el datagrama IP en bloques de 40 bytes, deberíamos tener un fragmento con offset 0, 40, 80, 120, y así sucesivamente, todos ellos con un tamaño de 40 bytes.

No hay problema, reensamblamos perfectamente y obtendremos de nuevo el datagrama IP, pero... qué sucede si alguno de los paquetes es mayor de 40 bytes, nos encontraríamos con algo como esto:

Ya le hemos liado, ¿cómo construimos el paquete ahora? ¿Qué información ponemos entre el byte 80 y el byte 119? ¿La que está en el segundo fragmento o en el tercero?

El protocolo no lo deja claro, así que ahí cada fabricante de sistemas operativos lo ha resuelto de una manera diferente. Según la documentación de Snort, en este momento hay en el mercado 7 políticas diferentes a la hora de realizar el reensamblado de paquetes:

• First: HP-UX 11, MacOS, SunOS <5.8
• Last: Cisco
• BSD: AIX, FreeBSD, HP-UX 10.x, IRIX
• BSD-Right: Algunas impresoras HP
• Linux: OpenBSD, Linux
• Windows: Windows (obviamente)
• Solaris: Solaris 9 y 10

La descripción de como realiza el reensamblado cada una de estas políticas (o al menos gran parte de ellas) puede encontrarse en este paper, salvo para Windows y Solaris, que Snort las ha separado recientemente de la política First, aunque sus diferencias sea leves.

El tema es que, aprovechando estas anomalías, podemos generar una conexión de red con una fragmentación especialmente creada para que funcione adecuadamente con nuestro sistema objetivo (un Windows, por ejemplo) pero que al ser reensamblado por otro tipo de sistemas (un Snort o un Wireshark en un Linux, por ejemplo) la información obtenida sea diferente, con lo que podemos ocultar una conexión e incluso provocar que el IDS no detecte ataques contra ese sistema (aunque ya veremos en otra ocasión como Snort tiene maneras de mitigar estos riesgos).

FragRoute

FragRoute es una herramienta de gran flexibilidad y potencia que nos permite forzar la fragmentación contra un sistema concreto, así como otros tipos de ataques de overlapping basados en TCP.

El tipo de ataques de fragmentación a realizar se define en un fichero de configuración con el que deberemos lanzar la herramienta. En nuestro caso, el fichero tiene el siguiente contenido:

ip_frag 40 old

order random

print

En este caso, estamos eligiendo realizar una fragmentación ip (ip_frag) de tamaño 40 bytes (40) y con overlaping favoreciendo que los fragmentos más antiguos tengan preferencia, es decir, estamos haciendo una fragmentación de tal forma que vamos a poder hablar con sistemas First, y probablemente Windows y Solaris (su política es muy similar a First). Además, estamos ordenando aleatoriamente los fragmentos (order random) y estamos señalando que queremos verlo por la pantalla (print), aunque por supuesto esta última parte es opcional.

Los usuarios de Ubuntu (o BackTrack, como es mi caso) pueden sufrir algún problema debido al contenido del fichero /proc/sys/net/ipv4/conf/all/rp_filter , que en este tipo de sistemas (y no sé si en algunos otros) está a "1" y debería estar a "0" para funcionar. Si os encontrais con problemas de funcionamiento en vuestro sistema, comprobad este flag:

# cat /proc/sys/net/ipv4/conf/all/rp_filter

1

# echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Ahora que ya tenemos esto configurado, si lanzamos la herramienta, probablemente nos encontraremos con el siguiente error:

# fragroute -f fragwin2.conf 172.16.24.151

fragroute: no route to 172.16.24.151: No such process

Por algún motivo, parece que fragroute requiere que tengamos al objetivo en nuestra tabla ARP o similar, así que tendremos que forzar una pequeña conexión antes de lanzarlo:

# ping -c 1 172.16.24.151 >/dev/null ; fragroute -f fragwin2.conf 172.16.24.151

fragroute: ip_frag -> order -> print

Por fin tenemos lanzado el fragroute. Ahora todo el tráfico que sea encaminado hacia 172.16.25.151, usemos la aplicación que usemos, será fragmentado de la manera que hemos escogido.

Como en el sistema Windows que hay en 172.16.24.151 tenemos un IIS a la escucha, vamos a ver que capturará el tcpdump o el wireshark cuando accedamos a este:

# tcpdump -nn -s 0 -w fragment.pcap host 172.16.24.151

# lynx -dump http://172.16.24.151

[respuesta esperada]

Tras ver que podemos visitar correctamente la web y que el Windows es capaz de reensamblar correctamente los fragmentos, vamos a ver que pasa cuando abrimos el pcap que hemos capturado en Wireshark:

Como podemos ver, el paquete reensamblado parece tener "basurilla" proveniente de los fragmentos con los que se hacía el overlapping. De hecho, si nos fijamos en la flecha, veremos que Wireshark nos muestra un fallo en el Checksum del contenido del paquete, algo lógico, ya que el Checksum fue calculado a partir del contenido original, y el contenido después de ser reconstruido el paquete es diferente, por lo que su Checksum no será el mismo.

Como decíamos antes, este tipo de técnicas pueden ser usadas para evadir la protección de los IDSs, ya que podemos hacer que un IDS sobre Linux (por ejemplo) reensamble el paquete de una forma incorrecta y que por lo tanto el contenido no haga match con ninguna regla, y sin embargo que el reensamblado en el host atacado sí que reensamble correctamente y sufra el ataque. También puede ser usado, como en el caso del reto de la DEFCON, para tocar los c****** a alguien que intenta analizar el tráfico de red :P

Sin embargo, no todo está perdido, ya que los IDSs pueden ser configurados de cierta forma que pueden detectar estos paquetes e incluso emular los diferentes tipos de reensamblado, pero claro, ha de ser configurado correctamente.

Pero eso será ya otro post.

Safari Same Domain Policy Bypass

Ayer por la mañana se publicó una vulnerabilidad en Safari en la manera en que se gestionan las URLs a la hora de verificar la Same Domain Policy.

Same Domain Policy es una protección de los navegadores que impide que un sitio web acceda a los objetos o métodos de otro sitio web, y es fundamental a la hora de proteger a los usuarios de gran cantidad de ataques. Según esta política, dos sitios web son el mismo, y por tanto deben poder acceder a los mismos objetos, cuando el protocolo, el nombre de host y el puerto al que se conecta son idénticos.

Explicado de una forma sencilla, una URL generalmente es de la siguiente forma:

http://banco.pentester.es/directorio/

Esta URL, al seguir los estándares, es gestionada de la misma forma por todo Safari, con "http" como protocolo, "banco.pentester.es" como host y "80" como puerto.

Sin embargo, se ha descubierto que una URL especialmente formada podría provocar errores al reconocer el host a la hora de verificar la Same Domain Policy:

http:banco.pentester.es/directorio/

Esta URL, al ser verificada por la Same Domain Policy, es reconocida como host cadena vacía (""), mientras que por contra es perfectamente usable a la hora de la navegación, y completamente equivalente a la que hemos visto anteriormente.

Por lo tanto, si tenemos una manera de formar URLs de tal forma que el navegador las reconozca como pertenecientes siempre a un host cadena vacía, podríamos construir varias URLs de diferentes sitios web de esta forma, y todos ellos serían reconocidos como pertenecientes al mismo dominio, con lo que podríamos acceder desde un sitio malicioso a los objetos y métodos de otros sitios web legítimos.

Veamos un pequeño ejemplo práctico.

Hemos creado un sitio web legítimo http://banco.pentester.es que contiene una vulnerabilidad que nos permite controlar el origen de un iframe de la web (para los puntillosos, también permite más cosas, pero vamos a centrarnos en el iframe). En realidad, este ataque a Safari podría realizarse simplemente con tener dos ventanas diferentes abiertas, sin necesidad de que exista ninguna otra vulnerabilidad en la web, pero nos parece un ejemplo interesante y real, así que vamos a ello:

Por otro lado, tenemos un sitio web malicioso http://test.sobreroblanco.es en el que tenemos un fichero que, a través de Javascript, pretende realizar modificaciones sobre el HTML de fuera del iframe. En este caso, cambiar el enlace "Contacto" de la web principal para que nos llegue a nosotros:

Tal cual está, si intentamos explotar la vulnerabilidad en el iframe, la web contenida dentro del iframe no va a ser capaz de alterar el contenido del resto de la web, ya que ambas webs se encuentran en dominios diferentes y el navegador no va a permitir que una acceda a los objetos de la otra:

http://banco.pentester.es/index.php?iframe=http://test.sombreroblanco.es

Como podemos ver, el enlace no ha cambiado, a pesar de que hemos intentado cambiarlo mediante Javascript, ya que la verificación del Same Domain Polocy ha fallado por tratarse de dominios diferentes.

Sin embargo, si formamos las URL de tal forma que hagamos que Safari crea que ambos dominios son cadena vacía (""), podríamos saltarnos esta restricción de seguridad:

http:banco.pentester.es/index.php?iframe=http:test.sombreroblanco.es

Como podemos ver en la parte inferior... AHORA SÍ, hemos conseguido cambiar el código HTML por medio de un código Javascript que se encuentra dentro del iframe y nos hemos saltado la Same Domain Policy.

Ya hemos explotado la vulnerabilidad, pero... no es tan fácil como parece, ya que si nos limitamos a escribir la URL maliciosa en el navegador no va a funcionar, ya que el navegador añadirá la doble barra (//) delante de los dos puntos (:) de forma automática para formar una URL correcta. Para que la explotación funcione correctamente, tenemos que conseguir que el usuario pinche sobre un enlace de la siguiente forma:

De esta manera, si conseguimos que un usuario pinche un enlace como este, es dirigido correctamente a la web que hemos visto antes y la vulnerabilidad es explotada.

Una de las maneras más evidentes de sacar provecho de este tipo de vulnerabilidades, además de cambiar el contenido de la web padre, es el robo de cookies de sesión. Sin embargo, tras realizar diversas pruebas, hemos llegado a la conclusión (o al menos nosotros no lo hemos conseguido) de que Safari no almacena correctamente las Cookies que provienen de un dominio cadena vacía, y por lo tanto no podemos utilizar esta técnica para forzar a que un usuario se autentique en la web legítima y robarle la Cookie desde el iframe, o incluso desde otra ventana del navegador. Para probarlo, hemos utilizado un sencillo código Javascript que crea una Cookie para posteriormente mostrarla con un alert:

Este código, accedido de la forma habitual (http://), nos muestra el valor nuevo que hemos introducido en al cookie:

Sin embargo, cuando lo llamamos mediante un "http:", no nos aparece en el alert ni la propia cookie que acabamos de configurar, sino que aparece completamente en blanco:

Este funcionamiento, por lo que hemos podido comprobar, inutilizaría la opción del robo de cookies, ya que estas simplemente nunca van a existir.

Sin embargo, que no exista la opción de robo de cookies no quiere decir que no exista la opción de robo de credenciales, ya que podríamos usar la misma técnica de cambio del código HTML para lanzar una web legítima con el formulario real de autenticación, y por otro lado nuestro sitio malicioso que altere el "action" de ese formulario para que las credenciales lleguen a un sitio controlado por el atacante.

Por lo tanto, se considera una vulnerabilidad de alto riesgo para los usuarios de Safari, por lo que recomendamos a todos ellos que apliquen los parches de seguridad publicados por Apple a la mayor brevedad posible.

NETinVM: Red en una Máquina Virtual

Una herramienta que suelo usar habitualmente para probar técnicas de seguridad en redes es NETinVM (NETwork IN VirtualMachine), una máquina virtual SuSe que contiene en su interior una serie de switches virtuales y máquinas UML que forman una red virtual al estilo de la que podríamos encontrar en cualquier red con su segmento "Internet", su segmento Interno, su DMZ, su firewall y todo lo demás.

Sus autores, mi ex-profesor de sistemas operativos de la universidad, Carlos Pérez y su hermano David Pérez, al que todos conoceréis como GSE del SANS y co-fundador de la empresa Taddong.

El esquema que por defecto viene configurado en la máquina virtual es el siguiente:

En total, por defecto, tenemos 7 máquinas UML separadas en tres redes. Tanto las máquinas de la DMZ como las externas presentan algunos servicios típicos como servicios web o similares, con el fin de que podamos realizar todo tipo de pruebas. También tenemos un firewall con iptables con el que podremos realizar pruebas de todo tipo, y que tiene pre-instalado un Snort que puede ser utilizado para probar a crear nuevas reglas que creemos y ver que tal funciona la detección. Además, las máquinas virtuales son Debian, por lo que podemos instalar lo que necesitemos en ellas, incluso a través de aptitude.

El funcionamiento de la máquina está perfectamente explicado en la documentación oficial. No obstante, hay algunas modificaciones que podemos hacer sobre NETinVM que consideramos interesantes:

Elección de máquinas virtuales

Para la gran mayoría de las pruebas que vayamos a realizar, probablemente las 7 máquinas UML que se arrancan por defecto sean innecesarias y simplemente van a consumirnos recursos, así que resulta muy interesante poder elegir cuales de estas máquinas UML queremos que arranquen, y cuales no.

Para ello, editaremos el fichero /home/user1/uml/bin/uml_run_all.sh que es el encargado de lanzar todas las máquinas, y nos encontramos lo siguiente:

uml.sh -d 4 fw

uml.sh -d 2 a ext

uml.sh -d 3 b ext

uml.sh -d 8 a int

uml.sh -d 7 b int

uml.sh -d 5 a dmz

uml.sh -d 6 b dmz

Como podemos ver, el script es sencillo, hay llamadas a otro script uml.sh que es el encargado de lanzar cada una de las máquinas virtuales de forma individual. El parámetro -d nos deja elegir el escritorio de entre los 8 que tiene la máquina virtual SuSe en el que queremos que la máquina UML se situe, mientras que en el resto de parámetros elegimos la red en la que se encontrará (ext, int, dmz) y cual de las máquinas de esa red queremos arrancar.

Por poner un ejemplo, imaginad que queremos realizar una prueba de MitM en LAN, con lo que solo necesitamos 2 máquinas en una LAN y 1 máquina de otra LAN a la que conectar para hacer la prueba, y por supuesto el firewall, así que podríamos reducir la cantidad de máquinas arrancadas cambiando el fichero de la siguiente manera con lo que ahorramos muchos recursos:

uml.sh -d 4 fw

uml.sh -d 2 a ext

uml.sh -d 8 a int

uml.sh -d 7 b int

Para otro tipo de ejercicios esta configuración podría (y debería) cambiar, por supuesto.

Memoria de cada máquina UML

Otro de los parámetros que podemos querer variar es la memoria que es asignada a cada máquina UML, ya que podemos encontrarnos con que una de las máquinas no realiza realmente ninguna función y por tanto no necesita mucho, y que por contra otras requieren utilizar múltiples herramientas que funcionarían de una forma mucho más ágil con un poquito más de memoria.

Para hacerlo, la manera más fácil es realizar una copia del fichero /home/user1/uml/bin/uml.sh a, por ejemplo, /home/user1/uml/bin/uml512.sh (lo lógico es poner un nombre representativo de la cantidad de memoria que le vamos a asignar) y editar este último fichero, en el que podremos leer las siguientes lineas:

# Virtual machine configuration

XTERM=terminal.sh

MEM=128M

A simple vista podemos ver que cambiando el valor de la variable MEM podemos cambiar la cantidad de memoria asignada a la máquina. En nuestro caso, lo cambiamos por 512M y guardamos los cambios.

Por último, tenemos que elegir cual de las máquinas que arrancamos va a tener esta configuración "especial", y eso lo tendremos que hacer editando uml_run_all.sh, tal y como hacíamos antes, y cambiar la llamada a uml.sh por uml512.sh en aquellas máquinas a las que queramos aumentarlas la memoria. Por ejemplo, en un caso en el que queramos hacer pruebas con el Snort del firewall podríamos querer disponer en esta máquina de más memoria.

uml512.sh -d 4 fw

uml.sh -d 2 a ext

uml.sh -d 8 a int

Por supuesto, a la hora de asignar una memoria distinta a las máquinas, tened en cuenta que la memoria asignada a la máquina virtual SuSe que lo contiene todo la tenga disponible, sino tendréis que aumentar ésta también.

Switches en modo Switch o Hub

Por defecto, imagino que para facilitar los ejercicios de sniffing, los switches virtuales se encuentran configurados en modo hub, por lo que todo el tráfico que envía cada una de las máquinas UML llega al resto de máquinas que se encuentran en la misma LAN. Esto, sin embargo, puede ser un problema si queremos realizar técnicas de MitM como por ejemplo ARP-Spoofing, ya que nos vemos el comportamiento real que tendría un switch.

Para hacer que los switches funcionen de su forma habitual, tendremos que editar el fichero /home/user1/uml/bin/uml_switch.sh y buscar la cadena "hub", con lo que nos encontraremos con la siguiente linea:

COMMAND="$UML_SWITCH -unix $SOCKET -hub -tap $TAP >/dev/null 2>&1"

Para cambiar el funcionamiento de hub a switch solo tenemos que eliminar la opción -hub de la llamada y guardar los cambios, y así la siguiente vez que arranquemos todos los switches funcionarán de la manera esperada

En próximos posts veréis como utilizamos esta herramienta, con alguna de las modificaciones que os acabamos de comentar, para demostrar un par de técnicas que nos vinieron a la cabeza al ver los retos de las Quals de la Defcon.