Fijación de sesión: Cookie (III)

Cuando la sesión se encuentra alojada en la cookie resulta mucho más difícil de explotar, debido a que cualquier navegador Web básico emplea la protección de mismo origen o “origin server”, donde un recurso web solo puede modificar atributos si ese recurso pertenece a su mismo dominio, puerto y protocolo, es decir, el servidor atacante no puede modificar la cookie del servidor víctima, y por tanto, no podrá fijar su sesión a la víctima.

Aún así existen distintas formas de intentar explotar una fijación de sesión almacenada en una cookie:

1. Si el servidor también es vulnerable a un XSS… ¿para qué voy a explotar un XSS para fijar una sesión cuando con explotar únicamente el XSS puedo obtener directamente la sesión empleada por la víctima?

2. Si puedo modificar el tráfico de red entre la víctima y el servidor vulnerable. Sinceramente ocurre lo mismo que en el caso anterior.

3. Pasar por GET la sesión y esperar un tratamiento incorrecto de la variable, ya que algunas aplicaciones Web si leen la variable de sesión por GET modifican la variable en la cookie.
4. Inyectando código HTML y JS en la cabecera del navegador, en especial “meta http-equiv” para intentar modificar la cookie. Esto funcionaba hace unos años, ahora mismo a mí no me ha dado buen resultado.

5. Intentado poner la cookie en la URL de tal forma que entre el recurso vulnerable y la cookie haya un salto de línea añadido “\r\n”, de modo que parezca que el servidor interprete la URL como URL más cabecera cookie. Era una vulnerabilidad relativamente antigua, tampoco me ha funcionado.

Por tanto, y desde mi punto de vista, intentar explotar una fijación de sesión por cookie es bastante difícil ya que se depende muchas veces de que el servidor, el navegador web de la víctima o la aplicación Web tenga alguna vulnerabilidad adicional.

Y ahora la pregunta que se estarán realizando, ¿por qué este post de una vulnerabilidad conocida y tanto interés en explotar la vulnerabilidad si la sesión va en una cookie? La respuesta es sencilla, en un viaje de vuelta en el tren me puse a jugar con una aplicación Web que sirve para practicar auditoría Web: DVWA. Como todas estas aplicaciones tienen una página de acceso al reto protegida por usuario y contraseña, la cual en principio no es vulnerable.

En caso de la DVWA creo que es vulnerable a fijación de sesión, ya que ésta no cambia antes y después de autenticarnos. Por precaución busqué si alguien había comentado algo previamente pero no he encontrado ningún comentario al respecto. Lógicamente esta aplicación no está enfocada a estar jamas en producción y su único propósito es docente. Aunque no tiene ningún tipo de criticidad puede servir como ejemplo.

Veámoslo en las siguientes dos capturas. Primero accedemos al recurso “login.php” sin estar autenticados, en la variable PHPSESSID vemos el valor de la sesión:

Una vez autenticamos el valor de la sesión continua siendo la misma:

Por desgracia al ir en la cookie la sesión me fue imposible explotar la vulnerabilidad. Para finalizar agradecer la ayuda proporcionada por Raúl Siles para intentar fijar la sesión en la cookie y recomendar esta presentación sobre fijación de sesión (PDF), a cuya charla en Barcelona tuve el placer de asistir. Nos vemos en la próxima entrada.


PD: entrada publicada para securityartwork.

Fijación de sesión: PoC (II)

Tal como se describió en la anterior entrada, la fijación de sesión es una vulnerabilidad debida a un tratamiento incorrecto en la gestión de sesiones por parte de una aplicación Web. En concreto la vulnerabilidad radica en que cuando se concede una sesión a un usuario no autenticado, y éste se autentica en dicha aplicación, el valor de la sesión no cambia. Por tanto, el vector de ataque para explotar la vulnerabilidad consiste en intentar que la víctima se autentique en la aplicación usando una sesión previamente conocida por el atacante, de tal forma que una vez el usuario se autentique, el atacante pueda acceder a la aplicación con el mismo rol que la víctima gracias a que conoce la sesión de ésta.

Para comprender de forma más sencilla el funcionamiento de la vulnerabilidad vamos a presentar una posible prueba de concepto, donde el recurso web “login.php” es vulnerable a la fijación de sesión en un escenario con un servidor web vulnerable, una víctima, un atacante y un servidor web del atacante. Veamos por paso el funcionamiento mediante un ejemplo:

1. El atacante envía un correo a la víctima haciéndose pasar por un compañero de trabajo y diciéndole que por favor consulte un dato de una aplicación, proporcionándole un enlace a la supuesta aplicación, cuando realmente el enlace apunta al servidor del atacante.
2. La víctima pincha en el enlace y por tanto accede al servidor del atacante.
3. El servidor del atacante al detectar la conexión de la víctima se conecta al servidor vulnerable para obtener una sesión valida.
4. Una vez obtenida la sesión, redirecciona a la víctima al servidor vulnerable pero forzándola a usar la sesión que el ha obtenido previamente.
5. La víctima se autentica en la aplicación vulnerable. Tened en cuenta que para la víctima el paso tres y cuatro son transparentes.
6. El atacante accede a la aplicación vulnerable con la sesión que le proporciono a la víctima.

Para ver la prueba de concepto de forma práctica he creado un pequeño script en python, llamado “sessionFixation.py” (), que hace las funciones del servidor atacante de forma automatizada. Éste acepta dos argumentos: el recurso vulnerable y el nombre de la variable de sesión. Al ejecutar el script se levanta en el puerto 80 un servidor web a la espera de recibir peticiones GET, y por tanto, a la espera de una víctima. Cuando la víctima se conecta al servidor, este de forma automática obtiene una sesión valida del servidor vulnerable y redirecciona a la víctima forzándole a usar por GET la sesión previamente fijada por el atacante.

En nuestro caso, el atacante será 192.168.67.130 y el servidor vulnerable 192.168.67.129. Situaremos un proxy Web delante del navegador de la víctima para ver los pasos que realiza su navegador y ejecutaremos elscript del servidor teniendo en cuenta que en nuestro caso el recurso vulnerable es “login.php” y la variable de sesión es “PHPSESSID”, por tanto para ejecutarlo se haría de la siguiente forma:

# ./sessionFixation.py “192.168.67.129/login.php” PHPSESSID

La víctima, cuya IP es 192.168.67.1, pinchará sobre el enlace que apunta al servidor del atacante (http://192.168.67.130) realizando una petición como la siguiente:

GET / HTTP/1.1
Host: 192.168.67.130 (servidor atacante)

Al conectarse la victima al servidor atacante, éste realiza una consulta al recurso vulnerable y obtiene de su respuesta una sesión válida. A continuación, mediante código JavaScript, redireccionará a la víctima al recurso “login.php” pero forzando a usar la sesión previamente obtenida:

GET /login.php?PHPSESSID=25imduuvgq8kbtrl1bl8mfg8b1 HTTP/1.1
Host: 192.168.67.129 (Servidor vulnerable)
Referer: http://192.168.67.130/ (redireccionados por servidor atacante)

Este proceso es totalmente invisible para el usuario víctima, puesto que lo único que vera es que el enlace le ha llevado al recurso legítimo de “login.php”, tal como se muestra en la siguiente captura de pantalla, donde podemos ver el log del servidor atacante en la parte superior y el navegador de la víctima en la parte inferior, después de explotar la vulnerabilidad:

Como vemos, el script fija la sesión por GET, pero en caso que fuera necesario fijarla por POST habría que cambiar un par de líneas para responder a la víctima con un formulario en vez de con un “document.location”. Es relativamente sencillo realizar esta operación.

¿Pero qué ocurre cuando la sesión se encuentra en la cookie? Lo veremos en la próxima entrada.

PD: entrada publicada para securityartwork

Fijación de sesión (I)

El protocolo HTTP fue diseñado para cumplir unos requisitos muy limitados, sin tener en cuenta muchas de las necesidades de la actualidad; por ejemplo, el protocolo no es capaz inicialmente de proporcionar o restringir visibilidad sobre sus recursos dependiendo de qué usuario los solicite.

Cuando un usuario accede a un servidor web éste realiza el saludo a tres bandas, solicita un recurso al servidor mediante HTTP, el servidor le devuelve el recurso solicitado y se cierra la conexión, por lo que si pinchamos en un enlace de la web, el servidor lo vería como una petición nueva y desconocerá que somos el mismo usuario. Por ello fue necesaria la creación del concepto de sesión, de tal forma que el servidor web sepa que somos el mismo usuario y en función de la sesión, proporcione visibilidad sobre unos recursos y con un determinado formato.

Esta sesión es un valor que debe ser aleatorio, difícil de adivinar y con una caducidad temporal. Normalmente la sesión irá como parámetro de la URL, en las cookies o en métodos POST; la sesión será generada y proporcionada por el servidor, mientras que el cliente web tendrá la obligación de añadir la sesión en sus peticiones para que el servidor tenga constancia de quién está realizando la solicitud. Por ejemplo, imagínese que usted se autentica en su webmail de tal forma que se le permita leer su correo electrónico y por algún tipo de vulnerabilidad, por ejemplo un XSS, alguien tiene acceso a su sesión. Este atacante podrá tener las mismas funcionalidades en el recurso web que tiene usted. Su usuario y contraseña solo le sirvieron para indicarle al servidor Web que conceda a su sesión visibilidad sobre su correo.

Por ello existen multitud de posibles vectores de ataque para que un potencial atacante intente obtener su sesión y, por tanto, sea capaz de suplantar a su usuario; principalmente estos se centran en los siguientes tres tipos:

1. Sesión predecible: Si la generación de la sesión no es aleatoria un atacante puede predecirla y suplantar al usuario.

2. Lectura de la sesión: La sesión puede ser accedida cuando hay alguna vulnerabilidad en la aplicación web, como un cross site scripting, o por emplear protocolos sin cifrado en entornos donde un potencial atacante podría leer el tráfico de red. Así se entiende el riesgo que supone acceder a un recurso web donde el proceso de autenticación es cifrado (HTTPS), pero una vez autenticados, navegamos sin cifrar (HTTP) y por tanto nuestra sesión también lo hace en texto en claro.

3. Fijación de sesión. Si una aplicación web, sin estar autenticados en el entorno, nos concede un identificador de sesión, y al autenticarnos el valor de esta sesión no cambia, estaremos ante una vulnerabilidad de fijación de sesión.

En la siguiente entrada documentaremos con mayor extensión cómo funciona la fijación de sesión, proporcionando una prueba de concepto real sobre esta vulnerabilidad.

PD1: entrada publicada también para securityartwork.es.
PD2: siento el vacio de Septiembre pero entre la mudanza y la preparación del GWAPT me ha sido imposible escribir nada. Por cierto, ¡ya soy GWAPT! :P