lunes, 19 de julio de 2010

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.

6 comentarios :

Yop dijo...

Me encantan este tipo de test pero soy demasiado novato para saber ni como empezar a hacerlo.

Se que dar más detalle te llevaría mucho curro pero con la serie de buffer overflow dejaste el nivel muy alto.

Jose Selvi dijo...

@Yop: No entendemos muy bien cual es tu duda:

A) ¿No entendiste los posts de los Buffer Overflow?

B) ¿Entendiste mejor los posts de Buffer Overflow que este de XST y nos pides más detalles en este?

Dinos por favor a que te refieres y te intentaremos complacer.

Saludos y gracias por el comentario ;)

Yop dijo...

@Jose Selvi. Entendí mejor los de buffer overflow, quizá porque los escribías para paletos como yo o porque quizá había más gente que preguntaba en los comentarios y me resolvían dudas que yo tb tenía.

José Miguel Holguín dijo...

Buenas @Yop,

José dejo el nivel muy alto didácticamente y técnicamente hablando en su posts sobre buffer overflow jejeje (igual que en el resto). De todo modos si concretas un poco qué parte no entiendes, que prueba no te ha salido, intentaremos ayudarte :).
Mis posts suelen ser menos didácticos .. :P

Gracias por los comentarios.

Augus1990 dijo...

Capas con algun complemento de Firefox se podria hacer que lance peticiones con Trace, pero no estoy seguro, porque no pude encontrar un complemento que lo haga.

Jose Selvi dijo...

@Augus1990: Lanzar peticiones con TRACE es sencillo, solo te hace falta un proxy intermedio, pero hacer que un navegador de un usuario sobre el que no tenemos control lance un trace... no es tan sencillo.

Yo estuve probando con formularios auto-enviables (con javascript) que empleaban TRACE como método, pero el navegador decía que ese método no lo conocía y que no enviaba nada.