Vulnerabilidad de 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 victima 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” (descargar), 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 el script 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.

Comments

  1. Me resulta un tanto complicado pensar que un desarrollador caiga en la trampa de forma tan sencilla, lo peor que los procesos son transparentes por lo cual no se levanta sospecha alguna. Ahora supongo que el caso del cookie agrava la situación, mejor dicho, la facilita al atacante.