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.