Saltarse un login: credenciales por defecto y bypass de autenticación

Un formulario de login es la pared con la que te encuentras en casi todas las máquinas web. La tentación es lanzar hydra con rockyou y esperar, y casi nunca es el camino. Antes hay media docena de pruebas que tardan un minuto y que, en Hack The Box, abren muchas más puertas que la fuerza bruta.

Esta guía es el orden en el que conviene hacerlas.

Requisitos

• Burp Suite (la versión Community basta) con el navegador configurado para pasar por él.
• SecLists en /usr/share/seclists (sudo apt install seclists).
• Hydra o ffuf para las pruebas en bloque.
• Para practicar: Jerry (Tomcat), Keeper (Request Tracker) y Previse (redirección que enseña la página).

Paso 1: qué aplicación es

Lo primero es saber qué producto hay detrás del login. Mira el título de la página, el pie, el favicon, las cabeceras y el código fuente:

whatweb http://10.10.10.95:8080
curl -sI http://10.10.10.95:8080/manager/html

HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm="Tomcat Manager Application"

Con el nombre y la versión, busca en Google "<producto>" default credentials y mira en SecLists:

ls /usr/share/seclists/Passwords/Default-Credentials/
grep -i tomcat /usr/share/seclists/Passwords/Default-Credentials/default-passwords.csv

Paso 2: credenciales de fábrica

Prueba a mano las de fábrica antes que nada. Estas son las que más se repiten en máquinas retiradas:

Si el producto no está en la tabla, prueba también admin:admin, admin:password, <producto>:<producto> y el nombre de la máquina como contraseña. Parece una tontería y funciona más de lo que crees (Driver, Traceback).

Paso 3: fuerza bruta acotada

Si hay una lista de credenciales por defecto para ese producto, pásala entera. Para la autenticación básica de Tomcat:

hydra -C /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt \
  -s 8080 10.10.10.95 http-get /manager/html

[8080][http-get] host: 10.10.10.95   login: tomcat   password: s3cret
1 of 1 target successfully completed, 1 valid password found

Para un formulario normal necesitas tres datos que sacas de Burp: la ruta, los parámetros y un texto que solo aparece cuando el login falla:

hydra -l admin -P /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt \
  10.10.10.10 http-post-form "/login.php:username=^USER^&password=^PASS^:F=Invalid credentials"

Paso 4: enumerar usuarios por los mensajes

Compara la respuesta con un usuario que seguro que existe (admin) y con uno inventado. Si el mensaje, el código de estado, el tamaño o el tiempo de respuesta cambian, puedes enumerar usuarios:

ffuf -u http://10.10.11.160:5000/login -X POST -d 'username=FUZZ&password=x' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -w /usr/share/seclists/Usernames/Names/names.txt -fr 'Invalid credentials'

En Noter la web responde Invalid credentials si el usuario no existe e Invalid login si existe. Con el usuario ya puedes centrar la fuerza bruta o falsificar su cookie.

Paso 5: inyecciones en el propio login

El formulario es una entrada más. Prueba en usuario y contraseña:

• SQL: admin'-- - y ' OR 1=1-- -. La explicación completa en la guía de inyección SQL. Lo tienes en Europa.
• NoSQL: en JSON, {"username":"admin","password":{"$ne":"x"}}. Detalles en inyección NoSQL y práctica en Shoppy.
• Comodines: un * como usuario o contraseña. En un filtro LDAP mal construido hace de comodín, y en Codify un script de bash que compara con == sin comillas acepta * como contraseña (y deja adivinar la real carácter a carácter con a*, ab*...).

Paso 6: type juggling en PHP

PHP compara con == de forma "flexible". Si el código hace if (strcmp($_POST['password'], $real) == 0), envía la contraseña como array:

username=admin&password[]=x

En PHP 7, strcmp con un array devuelve NULL y NULL == 0 es verdadero: entras. En PHP 8 da un error, así que esta prueba solo sirve en versiones antiguas.

La otra variante son los hashes mágicos: si la aplicación compara md5($pass) == $hash_guardado y el guardado empieza por 0e seguido solo de números, PHP lo trata como un número en notación científica (cero). Cualquier contraseña cuyo MD5 también sea 0e<números> entra, como 240610708.

Paso 7: la redirección que enseña la página

Algunas aplicaciones comprueban la sesión, mandan un 302 al login... y siguen enviando la página en el cuerpo de la respuesta. Se llama Execution After Redirect. En Burp, activa la interceptación de respuestas (Proxy > Options > Intercept Server Responses), pide la página protegida y cambia 302 Found por 200 OK.

HTTP/1.1 302 Found
Location: login.php
Content-Length: 2801

Un Content-Length grande en un 302 es la pista. Es la entrada de Previse y también aparece en Bank.

Paso 8: verbos, cabeceras y rutas

• Cambiar el método: si GET /admin da 401, prueba POST, PUT o un método inventado. En Wall la autenticación básica solo protege el GET.
• Cabeceras de proxy: algunas aplicaciones confían en X-Forwarded-For, X-Real-IP o X-Originating-IP para decidir si vienes de la red interna. En Control hay que hacerse pasar por una IP interna con una de ellas.
• Recuperar la contraseña: mira qué devuelve el "olvidé mi contraseña". En Silentium la respuesta incluye el objeto del usuario con el token de restablecimiento.
• CVE del producto: si tienes la versión exacta, busca un authentication bypass conocido, como en Bizness (Apache OFBiz). El método está en explotar un CVE público.

Errores típicos

• Hydra da decenas de contraseñas "válidas": el texto de fallo (F=) no está en la respuesta, por ejemplo porque el login redirige. Comprueba en Burp qué devuelve exactamente un intento fallido y elige otro texto, o usa S= con algo que solo salga al entrar.
• Ninguna prueba funciona y el formulario tiene un campo oculto csrf_token: hydra no lo renueva. Usa un script con requests que lea el token antes de cada intento.
• La cuenta se bloquea: hay una política de bloqueo. Para y piensa en otra vía; en Active Directory es más grave (ver password spraying en la enumeración de Active Directory).
• Entras pero la sesión no se guarda: la cookie se marca Secure y estás en HTTP, o el dominio de la cookie es un virtual host. Añade el nombre a /etc/hosts y entra por él.

Y después

Con acceso al panel, busca cómo ejecutar código: plantillas editables, plugins, subidas (subida de ficheros) o un WAR en Tomcat. Tienes estos puntos en la checklist web, en el apartado de autenticación.