Vacaciones 2010 en Pentester.Es

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)

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

28

TRACE / HTTP/1.1

Host: 192.168.0.16

0

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

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

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!!