Hijacking de cookies HTTP-Only con XSS usando TRACE

La verdad es que la técnica tiene ya unos años, pero he querido dedicarle una entrada en el blog a este ataque porque hay mucha gente que me ha preguntado "¿Por qué FOCA busca el método TRACE en la búsqueda de métodos inseguros?". Pues bien, la respuesta es muy sencilla: La culpa la tiene Jeremiah Grossman, que es quién descubrió este ataque. Vamos un poco con los antecedentes.

Allá por los principios del siglo XXI, las aplicaciones web adolecían de múltiples vulnerabilidades en el código que les hacían propensas a muchas ataques. Entre los fallos de seguridad más populares, si hoy son aún demasiado comunes, entonces también lo eran y mucho más, los fallos de XSS (Cross-Site Scripting). Sin embargo, aún sólo se estaba empezando a bosquejar lo que podrían suponer los ataques Client-Side, es decir, atacar al usuario en lugar de a los servidores.

Una de las técnicas más comunes para atacar al usuario era robarle la sesión, es decir, hacer un Hijacking - como en el ejemplo del XSS de Tuenti que permitía hacer hijacking -. Hacerlo con XSS era tarea sencilla. Bastaba (y aún basta) con injectar un Javascript que accediese a la cookie para enviarla a un servidor controlado, o dejarla en una ubicación accesible remotamente.

Como arreglar todas las vulnerabilidades de XSS era una tarea inabordable, la industria decidió aplicar medidas de fortificación, con lo que a la cookie se la empezó a poder poner flags como Secure, para que fuera solo bajo conexiones HTTP-s o HTPPOnly, para que no fuera accesible por código script, y sólo se enviara en conexiones HTTP.

Y ahí viene el asunto del método TRACE y el ataque que descubrió Jeremiah Grossman. ¿Cómo podría robarse una cookie marcada con HTTPOnly mediante un ataque XSS? Pues la idea es curiosa, vamos a verla.

Supongamos un servidor web como el del Club Atlético Osasuna en la que, haciendo uso del método OPTIONS se puede ver que tiene habilitado el método TRACE. 

Figura 1: El método OPTIONS devuelve que el método TRACE está habilitado

El método TRACE lo único que hace es devolver una respuesta 200 en la que se copia lo que se le ha enviado por el método TRACE. Hay que decir que, en muchos servidores aparece en la respuesta de OPTIONS que está habilitado, pero luego cuando se hace la prueba devuelve un mensaje 403 de Forbidden o un 501 de Not Implemented, por lo que es necesario probarlo.

En el caso de la web del Osasuna se puede ver que sí que está implementado, y que cuando se envia una petición TRACE en la respuesta tenemos un 200 y en el cuerpo del mismo está la misma cabecera TRACE.

Figura 2: El método TRACE funciona y devuelve lo que se envía

Si esto es así, y existe un bug XSS en una aplicación web que corra sobre ese servidor que pueda ser utilizado para generar una petición TRACE, entonces se podrá robar la cookie aunque esté marcada como HTTPOnly.

La idea es tan simple como que el navegador no va a permitir acceder por medio de código script a la cookie, pero cuando se realice una petición HTTP será él mismo quien añada la cookie de la sesión a la petición. Como la petición es un método TRACE, en la respuesta, ya no como una cookie sino como un cuerpo de mensaje podrá leerse el valor de la cookie que entonces sí será accesible por Javascript.

Figura 3: Si se envía una cookie en la petición TRACE vuelve en el código

Es por eso que, si no se está haciendo uso del método TRACE por parte de ningún software en concreto, en las auditorías de seguridad recomendamos deshabilitarlo o prohibirlo, para evitar que alguien pueda hacer uso de él si se dan todo el resto de condicionantes... - que no son pocos -.

Saludos Malignos!