Bypassing logins & malicious cookies en una web insegura

En cualquier auditoría de seguridad de aplicaciones web, es imposible evitar poner una comilla, dejándola caer como el que no quiere la cosa, sobre un campo de login para ver si la auditoría va a ser "rápida" o no. Si el resultado es el buscado inevitablemente toca colocar un 'or '1'='1. Si aún con esas no hemos conseguido nuestro objetivo, tocará hacer más pruebas, como probar passwords suprayectivas o la fuerza bruta para ver si la ofensa que indirectamente nos lanza el - por ahora -astuto sistema de logins de la aplicación web en cuestión lo va a soportar o no, mientras la observaremos con recelo en todo momento que nos tenga en jaque.

Figura 1: Login de acceso

Hace ya tiempo, mientras auditaba uno de esos sitios en los que no se encuentran más que páginas estáticas y pocas variables de las que aprovecharse, un panel de login se interpuso en mi camino. Sería él por supuesto, el que me daría paso mediante un SQL Injection para abrirme la puerta a toda la base de datos. Lo primero en estos entornos es saber cómo funciona, así que enviamos un usuario y contraseña al azar, para ver como trata la aplicación las peticiones.

En este entorno que reproduce una situación análoga a lo que os cuento, esa petición POST se encargará de validar mis datos de acceso mediante las variables user= y pass= con una aplicación PHP que, como es lógico, me re-direccionará a una página de error.

Figura 2: Análisis de la petición POST usando Burp Suite

Como anteriormente ya habían sido sometidas esas variables a torturas con mis jeringuillas cargadas de SQL y el famoso Intruder de Burp Suite, se me ocurrió valerme de un login similar en otro dominio, desde el que había conseguido un acceso con SQLi y así ver la forma en que la aplicación trataba a las cookies. Entre las variables de una sesión de login que conseguí se encontraban:

PHPSESSID=(Sesión Cifrada)
user_tipo=(Un dígito que define el Rol)
id_usuario=(Identificador de usuario)
user_user=(Usuario en texto claro)
id=(Identificación no utilizada)
user=(Usuario en texto claro)
pass=(Hash de la contraseña)

Sobra decir que las malas formas de gestionar las cookies saltan a primera vista, ya que el usuario y hash puedan verse en cada petición y por tanto compromete gravemente la seguridad de los usuarios administrativos ante ataques de sniffing.

Capturando la siguiente petición, la página me echaría fuera del acceso ya que introduje un login erroneo, pero mediante los campos nombrados anteriormente pude abrirme paso saltando directamente al nombre de un PHP interno de aplicación, agregando como valores tres campos importantes.

Figura 3: Petición modificada

La variable del tipo de usuario “user_tipo=1”, mostraría a la aplicación que mi cookie pertenece a un usuario con número 1 de rol, que coincide con el que utilizaría un administrador. La segunda variable y no menos importante, sería “id_usuario=1”. Sin esta variable la aplicación no nos daría acceso ya que buenamente comprueba el número de usuario de la base de datos. Es decir, que basta con manipular las cookies y no hace falta autenticarte ni nada.

Por último, “user_user=admin” es una variable no tan necesaria para el proceso de login, aunque evitaríamos errores en la página de administración y nos da juego para explotar una inyección Cross Site Scripting (XSS), ya que la aplicación lee el valor de la cookie y lo muestra directamente en la página sin filtrar caracteres extraños.

Figura 4: SQL Injection en un PHP interno gracias a la evasión del login con las cookies

Ya estamos dentro pero… ¿y el login y la password? Aprovechando que muchas aplicaciones administrativas  suelen estar mal desarrolladas - que ya hemos visto muchas cosas en el SOCtano .... - bajo premisas de "¡Total! ¡Qué más dará! ¡Si todo queda adentro!", con la facilidad de la inyección, no  hubo más que buscar en Google las passwords crackeadas que estas eran más facilonas que las del Kapital ;)

Con el acceso en mano ya solo queda trastear, ¿que pasaría si ponemos un Cross Site Scripting  (XSS) Persistente en una cookie? Una vez que escribes en la página algo con el nombre de usuario modificado, al quedar reflejado en la base de datos, éste se rescataría y se ejecutaría en el equipo de todos los usuarios.

Figura 4: XSS en la cookie

Un entorno perfecto para hacer un poco de Black SEO, distribución de malware, ataques de phising, etc..., que gracias a la auditoría ya no es vulnerable a ninguno de estos ataques. Si es que hay que hacer bien las aplicaciones web y si no... auditarlas antes de ponerlas online.

Antes de terminar - y visto que todo esto es por hacer una mala gestión de las cookies de una sesión - no podía acabar este artículo sin recomendar el Session Management Cheat-Sheet de Raúl Siles para la gestión segura de cookies de sesión y el libro del boss y Enrique Rando sobre SQL Injection.

Autor: Germán Sánchez "Un tal 4n0nym0us en el PC"
Consultor de Auditoría Web en Informática 64