Mostrando entradas con la etiqueta DefCon. Mostrar todas las entradas
Mostrando entradas con la etiqueta DefCon. Mostrar todas las entradas

martes, 26 de enero de 2016

Herramientas de ayuda para Delorean

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean
[7] Otros ataques
[8] Herramientas de ayuda

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

Por fin hemos llegado al último post de esta serie sobre Delorean. Llegados a este punto, hemos hablando de los ataques que probamos, sobre la herramienta, y muchas otra cosas. Sin embargo, si prestáis atención al repositorio de Deloran, veréis que hay un par de scripts python de los que no habíamos hablado antes. Son pequeñas herramientas que desarrollé porque necesitaba una funcionalidad concreta pero que no tenía sentido integrarlas con Delorean, así que lo mantuve como herramientas separadas.

La primera herramienta es hsts_catcher.py, que es una herramienta muy sencilla que conecta a un website y te devuelve su configuración HSTS. Nada que no puedas hacer con curl y grep:

$ ./hsts_catcher.py -U https://accounts.google.com -A "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"
max-age=10893354; includeSubDomains

La segunda herramienta es crl_checker.py, que en bastante más interesante que la anterior. Mientras estuve buscando certificados para usar para mis ataques, me encontré con un problema: Algunos certificados que había encontrado tenían problemas de validez en su cadena, por ejemplo, su root CA había expirado. Lamentablemente, comprobar la validez de cada cadena de forma manual era una putada un proceso muy largo y tedioso, así que la manera más cómoda era usar el propio navegador para comprobar si aceptaba la cadena  no. Sin embargo, hay otro problema con esto: Los servidores web necesitan tanto el certificado como la clave privada, y encontrar este clave privada sin saber si luego el certificado te valdrá o no... es un proceso excesivamente costoso como para hacerlo a ciegas. El problema era un circulo vicioso.

Por eso decidí desarrollar esta herramienta. col_checker.py implementa las primeras etapas de SSL, donde no se requiere en realidad el uso de la clave privada, pero sí se realiza la fase de validación del certificado, con lo que podemos comprobar su validez. Solo tenemos que lanzar la herramienta usando este comando y visitar el puerto con el navegador:

$ ./crl_checker.py -p 10443 -c /etc/apache2/ssl/ietf.crt


A veces hace falta refrescar varias veces para que aparezca este mensaje. Probablemente mi implementación del hanshake d SSL está demasiado hardcodada, pero no me he metido a fondo a mirarlo ya que la herramienta sigue siendo útil.

Un mensaje como el de arriba significa que el certificado es perfecto para nuestro ataque. Salen algunos mensajes de advertencia sobre el nombre del hosts o la fecha, pero estos son lógicos y no nos preocupan, ya que estamos corriendo el servidor en una IP local y la fecha... es algo que podemos solucionar con Delorean.


Si tienes mala suerte, verás otros mensaje de advertencia, como por ejemplo "the issuer certificate is unknown" que quiere decir que la CA que firma l certificado probablemente ha sido eliminada de la lista de confianza del navegador, o algún otro problema similar, así que mejor buscar otra víctima.

lunes, 25 de enero de 2016

Otros ataques usando Delorean

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean
[7] Otros ataques
[8] Herramientas de ayuda

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

Los ataques que hemos estado viendo en los artículos anteriores son los que considero que son más probables y que tienen un mayor impacto. Sin embargo, también estuve probando otras opciones utilizando ataques de sincronización. Algunos de ellos funcionaros,  pesar de ser poco probables, y otros de ellos no funcionaron en absoluto.

Uno de los ataques que funcionó fue un ataque contra el planificador de taras de Windows. Como probablemente sepáis, hay un servicio que corre en las máquinas Windows que se encarga de ejecutar ciertas tareas de mantenimiento en segundo plano, como por ejemplo la propia tareas de sincronización de hora.


El planificador de tareas guarda la información de la última vez que una tarea se ejecutó, y la siguiente vez que lo hará. Estos campos son importantes porque, depende de como se haya configurado la tarea, el "Next Run Time" a veces se calcula en base al "Last Run Time", lo cual nos da la oportunidad de manipular la siguiente ejecución de la tarea si conseguimos manipular al reloj usando Delorean.

No todas las tareas calculan la hora de la siguiente ejecución de esta manera, pero hay algunas tareas interesantes que sí que lo hacen, como por ejemplo el servicio de actualizaciones automáticas de Windows.


¿Qué ocurre entonces si manipulamos el reloj usando Delorean, tal y como vimos en anteriores artículos, y la tarea de actualizaciones automáticas es ejecutada? Pues que el "Last Run Time" se ejecutará con la fecha manipulada (por ejemplo, 2020), así que la siguiente ejecución de la tarea se calculará en base a esta fecha, es decir, ocurrirá en algún momento de 2020. Esto no debería ser un problema siempre y cuando el equipo se mantenga con la fecha manipulada para siempre, pero si en algún momento el equipo vuelve a la fecha original... la siguiente ejecución del servicio de actualizaciones automáticas no se ejecutará en los próximos 4 años, con lo que el usuario no será advertido de la existencia de nuevas actualizaciones y parches de seguridad si no lo comprueba manualmente.

En realidad, este es un ataque poco problema, ya que Windows es la plataforma en la que es más complicado realizar un ataque con Delorean, y porque al menos yo no encontré una manera de devolver el reloj a su hora original sin la intervención del usuario. Sin embargo, otras tareas y otras plataformas (como cron en Linux, por ejemplo) podrían también ser manipuladas de una manera similar.

miércoles, 4 de noviembre de 2015

Atacando la Infraestructura de Clave Pública

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean
[7] Otros ataques
[8] Herramientas de ayuda

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

Descargo de responsabilidad (2): En este artículo hablo de certificados, claves SSL, etc. En ocasiones diré cosas como "la clave privada del certificado", ya que es la manera en la que normalmente me expreso, aunque probablemente no sea el término más correcto. Debería decir cosas como "la clave privada de la clave pública del certificado", pero creo que resulta más sencillo de entender si lo simplifico un poco. En cualquier caso, si algo no se entiende bien solo tenéis que mandarme un correo o dejar un comentario e intentaré aclararlo.

De los ataques en los que he estado trabajando desde que empecé con esta investigación, el ataque contra PKI es mi favorito. Es algo que me vino a la cabeza cuando me paré a pensar que más servicios o protocols podrían funcionar mal si conseguía manipular el reloj de un equipo.

Como probablemente sepáis, un certificado SSL es válido bajo las siguientes condiciones:
  • Ha sido firmado por una entidad de certificación de confianza (CA) o por una CA intermedia que a su vez a sido firmada por una CA de confianza.
  • El "Common name" del certificado coincide con el hostname del servidor (los comodines están permitidos).
  • La fecha actual está entre las fechas "Not valid before" y "Not valid after".
Cuando un certificado SSL expire necesitamos uno nuevo, y del viejo normalmente nos olvidamos, ya que éste sería inválido (3er caso). Sin embargo, con Delorean esto no es completamente cierto, ya que podemos manipular la hora del reloj y hacer que el equipo crea que el certificado viejo aún es válido.


Para poder usar un certificado de esta manera, necesitamos que éste cumpla una serie de condiciones:
  • Tenemos que reconstruir la antigua cadena de certificados: Esto no es un problema, ya que los certificados de las CAs normalmente tiene periodos de valicez muy largos, así que probablemente la cadena de certificados actual también funcionará con el certificado antiguo. Sino, es fácil encontrar los certificados buscando el "Issuer name" del certificado en Internet.
  • La root CA (la que empieza una cadena de certificados) tiene que ser ua CA de confianza para el sistema operativo/navegador: Si la root CA expira y se elimina de la base de datos del navegador, éste no será capaz de validad la cadena de certificados. Este problema solo ocurre con la root CA, que es la que debe estar instalada en el navegador. Cualquier otra CA intermedia se pude usar a pesar de que se encuentre expirada.
  • Tenemos que encontrar certificados viejos de hosts: Esto es más difícil de lo que parece. Lo veremos un poco más abajo.
  • Tenemos que poder obtener la clave privada deel certificado de host: Esta es la única clave privada que necesitamos obtener. Al ser un certificado viejo, su clave debería ser más fácil de obtener que en un certificado actual. Hablaremos de esto más adelante también.
Pero... ¿De donde sacamos estos certificados viejos? Si hace 10 años lo hubira sabido, hubiera hecho un crawling de Internet y me hubiera guardado los certificados SSL, pero como no lo hice... necesitamos tirar de alguna base de datos pública, cuanto más vieja mejor. Invertí mucho tiempo buscandola, y lo mejor que encontré fue The SSL Observatory de EFF, que cuentan con una base de datos de certificados SSL de 2010.


Ahora que ya tenemos una base de datos de certificados SSL viejos, podemos empezar a buscar a ver cuales de ellos tienen pinta de que los vamos a poder romper. Por ejemplo, algo que me vino a la cabeza fue FREAK. Como parte de est ataque, los investigadores crackeron un RSA-512 en unas pocas horas, usando un cluster de máquinas en Amazon EC2, así que no vi porque no podríamos hacr nosotros algo similar con las claves RSA-512 presentes en nuestra base de datos.

Desafortunadamente, los objtivos más importantes (Google, Facebook, etc) ya no usaban RSA-512 en 2010. Quizá si tuvieramos una base de datos más antigua... En cualquier caso, encontré algunos certificados interesantes y algunos bastante divertidos, como por ejemplo una página de Disney (no la página principal).

Descargo de responsabilidad (3): Cuando hago una demo con Deloran y uso una página web, NO estoy atacando esa página. La página NO es vulnerable. Estoy atacando un clinte vulnerable, que es mi propia máquina de pruebas, así que me estoy atacando a mi mismo, no a la página web.

No voy a contar paso por paso como crackear un RSA-512 porque sería un artículo (o varios) en si mismo, y porque tampoco es un tema en el que yo sea un experto. Si tenéis interés, os dejo algunos enlaces [1][2][3][4]. Resumiento, tuve 4 máquinas en EC2 corriendo durante 3 días (si no recuerdo mal) y al final costó al rededor de $150 en total.


Una vez que has factorizado la clave tienes los dos números primos que se usaron para generar las claves pública y privada, así que solo necesitas generarlas de nuevo (private-from-pq.c) para obtener la clave privada, y ver si funciona:


¡Funciona! La cadena de certificados es válida y tenemos la clave privada, así que podemos engañar al navegador e impersonar la página ¡Genial!

Por lo que he podido leer (no soy un experto), los Gobiernos y otros organismos con suficientes recursos podrían crackear RSA-1024 en un tiempo razonable. Ésto es aún más interesante que mi demo, porque RSA-512 en estos momentos está baneado en la mayoría de navegadores, así que estos rechazarían la cadena de certificados, aunque ésta sea válida. Hice esta demo usando un RSA-512 porque en este momento yo no dispongo de la capacidad computacional para crackear RSA-1024, y porque el proceso es exactamente el mismo, con lo que podríamos hacer lo mismo con un RSA-1014 en un navegador completamente actualizado si dispusieramos de esta potencia.

Ésta no es la única debilidad que podemos usar:n use:
Pero hay algo que probablemente estaréis pensando ¿Qué pasa con la revocación? No sería un problema para claves crackeadas, porque nunca fueron revocadas, pero los certificados robados, obtenidos con heartbled, afectados por le bug de debian prng, ... todos esos certificados deberían haber sido revocados cuando se generaron los nuvos.


Una lista de revocación de certificados (CRL) es una base de datos donde se guardan los certificados que han sido revocados. Los navegadores se la descargan (o la consultan online) y comprueban si el certificado que les proporciona un servicio ha sido revocado o no. Si lo está, entonces rechazan la comunicación aunque la cadena de certificados sea válida..

Cuando me encontré con este problema, la pregunta que vino a mi cabeza fue: ¿Esas CRLs guardan TODOS los certificados revocados? ¿Desde el principio de los tiempos? Eso haría que el fichero fuera ENORME, lo cual podría afectar al rendimiento. Bien, no puedo estar 100% seguro de esto, pero hice unas rápidas pruebas para ver si las CAs purgan sus CRLs cuando los certificados revocados caducan.


Me centré en una prueba muy sencilla. Abri varias páginas muy conocidas con mi navegador y me bajé el certificado de la CA que lo firmaba. También me bajé la CRL que estaba referenciada en dicho certificado y busqué grandes diferencias entre la fecha de creación de la CA y la fecha de revocación más antigua de la CRL. Por ejemplo, si una CA fue creada en 2008, pero el primer certificado que se revocó fue en 2012, y el siguiente en 2014... es un poco extraño. Mi humilde opinión es que estas CAs están purgando los certificados expirados porque éstos son inválidos en cualquier caso, estén revocados o no. Esto es 100% cierto, pero nos permite utilizar nuestro ataque contra estos certificados, aunque debieran estar revocados.

OCSP no resulta muy útil contra estos ataques, ya que la mayoría de los navegadores están configurados para aceptar los certificados cuando no pueden validar si están revocados o no, con lo que un atacante únicamente tiene que bloquear las conexiones contra OCSP para que sus certificados revocados sean aceptados. Más informacion AQUÍ.

De la lista de antes, me decidí a buscar certificados generados con el bug de Debian PRNG. El problema era que ésto ocurrió en 2008, mientras que la base de datos de la que disponemos era 2010, así que todas las páginas web interesantes habían cambiado ya su certificado antes de 2010.

Buscando por Internet encontré CodeFromThe70s. Esta gente desarrolló un plugin para Firefox que detectaba los certificados vulnerables y se los enviaba. Ellos mantenían una blacklist genial en su página que nos podémos descargar y usar para ver si aún estarán revocados o no.

El siguiente paso fue obtener la clave privada. No fue tan fácil como pensaba, porque las listas pre-generadas que publicó HD Moore eran para SSH, así que tuve que generarme las mias propias para HTTPS. Lo que hice fue usar el "getpid.so" parcheado original y el entorno "ubunturoot" (el enlace original está roto, así que yo me lo bajé de aquí), y desarrollé un par de scripts en shell para generar todas las posibles claves SSL y comprobar si era la que estaba buscando:

$ cat keyfind.sh
#!/bin/bash

TARGET=0123456789abcdef0123456789abcdef

for PID in `seq 1 32768`
do
    chroot . /generate.sh $PID &>/dev/null

    openssl rsa -in private.pem -noout -modulus | openssl md5 | awk '{print $2}' | grep "$TARGET"
    if [ $? -eq 0 ]
    then
        cp private.pem found.pem
        echo "FOUND!"
        exit
    fi
    rm -f private.pem
    echo $PID   
done


$ generate.sh
#!/bin/bash

export MAGICPID=$1
export LD_PRELOAD=/getpid.so
/usr/bin/openssl genrsa -out private.pem 1024 &>/dev/null


En unas pocas horas tenía la clav privada. Quizá hubiera sido más eficiente de otro modo, pero funcionó al fin y al cabo. Veamos la demo:


Mi charla de DEF CON ( 7 de Agosto de 2015) está online, así que también le podéis pegar un ojo. También presenté la charla en Español en RootedCON (Marzo 2015) y NavajaNegra/ConectaCON (Octubre 2015),pero los videos aún no han sido publicados:

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.

martes, 22 de junio de 2010

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.

martes, 25 de mayo de 2010

Defcon18 CTF PreQuals: WriteUps (Soluciones)

Tanto si has participado como si no, siempre es interesante ver las soluciones de otros, como han resuelto aquello en lo que te quedaste enganchado, o simplemente intentar pensar si lo hubieras podido resolver si hubieras participado (aunque para este caso siempre somos un poco "sobrados", cuando otro nos dice la solución siempre parece muy fácil :P

Bueno, el caso es que las PreQuals del CTF de la Defcon18 acabaron ayer a las 04:00 de la mañana, y en estos momentos llevamos unas cuantas horas que diversos participantes están publicando sus soluciones, así que me ha parecido interesante hacer una pequeña recopilación que iremos completando según vayan saliendo soluciones. Por supuesto, dejad comentarios si veis más soluciones que merece la pena incluir :)

Allá vamos, por categorías, que como ya sabeis están puntuadas de 100 a 500 en función de la dificultad:
También se han publicado algunos videos.

Si alguien encuentra por ahí algún WriteUp para los que faltan, o una solución mejor o mejor explicada a los que hay aquí, que ponga un comentario y lo cambiamos.

Gracias también a todas las personas a las que sigo en Twitter, y a Google, sin cuya colaboración este post no sería posible :P A ver si lo conseguimos completar entre todos.

Desde Pentester.Es, enhorabuena a aquellos equipos que se han clasificado para la final en Las Vegas.
Mucha suerte!

martes, 28 de abril de 2009

Fast-Track: Pentesting a la velocidad de la luz

Todos los que nos dedicamos a la seguridad y más concretamente a hacer Pentesting sabemos del poco tiempo que disponemos cuando nos ponemos a auditar la red de una empresa, todos acabamos haciendonos nuestros scripts o nuestros programitas (en la medida de lo posible) para conseguir automátizar cuantas más cosas mejor, para así disponer de más tiempo para aquellas que requieren sencillamente pararse a pensar y echarle imaginación.

Parace que lo mismo le ha sucedido a David Kennedy, ex-NSA, actualmente trabajando en la empresa SecureState, que ha desarrollado un script en python llamado Fast-Track que pretende automatizar algunas tareas muy interesantes a la hora de realizar un test de intrusión (de hecho fijaros en el nombre de la web, parecido al de esta).

Este script está ya en las manos de los usuarios de BackTrack, ya que Dave es colaborador habitual de esta distribución. Para utilizarlo sólo es necesario entrar en el directorio /pentest/exploits y lanzarlo con las opciones deseadas "-i" para modo interactivo por linea de comandos, "-g 80" para lanzar un servidor web al que conectar a http://localhost y seleccionar las opciones deseadas de forma gráfica.

# cd /pentest/exploits
# ./fast-track.py -g 80

(en otra ventana)
# firefox http://localhost

Además, en la web de Fast-Track existen excelentes tutoriales de demostración en video que muestran como utilizar cada una de las opciones de esta herramienta.

De entre todas ellas, a mi hay dos que me resultan especialmente interesantes, ya que realiza de forma automática la detección del sistema, selección de los exploits que le podrían afectar, y los prueba, lo que ahorra mucho tiempo:
  • Fast-Track Autopwnage: Esta opción realiza de forma automática un escaneo de puertos con NMAP para posteriormente utilizar Metasploit, seleccionando únicamente los exploits adecuados a los puertos que se han descubierto como abiertos. Una forma muy rápida de encontrar agujeros directamente explotables a través de Metasploit.
  • Fast-Track Mass Client Attack: Levanta un servidor web que, tras realizar un ataque MitM que deberemos realizar de forma manual, (otro día escribiré algo sobre eso) realiza una detección de la versión del navegador utilzada por el cliente y le develve en la contestación a su petición los exploits que podrían explotar vulnerabilidades de su navegador. En el ejemplo vemos como explota una vulnerabilidad y obtiene un acceso mediante VNC.
Para más videos y posibilidades, os invito a visitar la web de la herramienta.
Sin duda una herramienta excepcional, que nos va a permitir agilizar mucho nuestro trabajo.
A disfrutarla!

jueves, 25 de septiembre de 2008

Marathon Tool & Heavy Querys

Otra herramienta de las utilizadas en la DEFCON de este año es Marathon Tool, una herramienta para auditoría web basada en inyecciones de código SQL "pesado".

La inyección SQL, como todos sabemos, es una vulnerabilidad causada por una mala comprobación de los parámetros de entrada que finalmente se traducen en una solicitud SQL a base de datos diferente de la que la aplicación web está pensada para hacer.

Generalmente, si escogemos una página web aleatoriamente en todo Internet, buscamos un campo formulario y escribimos una comilla simple (') nos encontraremos algo como esto:


Encontrarnos un error de la base de datos o incluso una sentencia SQL completa como en este caso es un claro signo de que el campo formulario que hemos encontrado sufre de una vulnerabilidad de Inyección SQL.

Este es el caso más fácil, que nos muestre claramente la web algo como esto, pero no siempre esto es posible, en ocasiones está filtrada este tipo de salida, o simplemente la salida de la sentencia SQL no es utilizada para mostrar ningún contenido en la web, por lo que para detectar si la web es vulnerable o no y para intentar explotarlo tendremos que recurrir a un Blind SQL Injection, que como su propio nombre indican son "ciegas", o mejor dicho "no evidentes", puesto que obtenemos igualmente información aunque sea por otros medios.

De entre todas las técnicas de Blind SQL Injection que existen, la herramienta Marathon Tool utiliza una técnica basada en querys SQL pesadas, ¿que quiere decir esto exactamente?, pues bien, imaginaros que una aplicación SQL normal tiene una query que es ejecutada y ofrece una respuesta en un tiempo de X segundos, tiempo que podemos apreciar más o menos observando la respuesta de la página (en función también un poco de la latencia de la red, claro). ¿Que pasa si intentamos inyectar un código que en caso de funcionar correctamente realice una consulta sin ninguna intención específica de obtener información pero que sabemos que va a tener un coste para la base de datos de 1000X segundos?. Pues en el caso de que no funcione el tiempo de carga de la web será el habitual, mientras que si funciona observaremos que el tiempo de carga es muy superior al habitual.

A partir de ahí, podemos usar esta Query para ir "haciendo preguntas" a la base de datos que tengan como respuesta sí o no y comprobando mediante ese timing cual es la respuesta que nos da la base de datos, y así de esta manera ir obteniendo información de tablas, contenidos de tablas (usuarios y contraseñas) y un largo etcetera.

Sin duda alguna, menos cómodo que obtener el listado de usuarios y passwords mostrados directamente en el contenido de la web, pero igualmente factible con un poco más de trabajo.

Aquí es donde entra esta herramienta tan interesante, tras ser configurada adecuadamente permite automátizar el proceso de búsqueda de tablas y usuarios de tal manera que no tenemos que ir realizando esas preguntas que comentabamos de forma manual, sino que es la herramienta la encargada de realizar cuantas consultas sean necesarias e ir obteniendo esta información.


Una gran herramienta, sin duda.