En el artículo de hoy, vamos a ver el reto VulnLawyers.
Se nos proporciona la siguiente dirección y tenemos que encontrar 6 flags.
Lo primero de todo es inspeccionar la web:
Lo único que vemos es una imagen y un par de frases. No hay ningún botón, ningún formulario…
Podemos inspeccionar el código fuente de la web:
Y tampoco hay ninguna pista, no vemos ni comentarios ni nada.
Por tanto, podemos intentar encontrar directorios potenciales en la web. Para ello vamos a usar la herramienta ffuf.
Lógicamente, tenemos que emplear un diccionario para ir comprobando cada una de las rutas que aparecen en él. En este caso, vamos a utilizar el content.txt. Además, tenemos que indicar el tiempo de espera por cada petición (según las normas del reto debe ser de 0.1 segundos), los hilos (según las normas del reto debe ser de 1 hilo) y la cookie ctfchallenge que nos proporciona el reto. Estos parámetros son obligatorios.
Si intentamos acceder a una ruta que no existe, por ejemplo:
http://www.vulnlawyers.co.uk/diegoaltf4
podemos ver que nos devuelve el mensaje «page not found!»:
Si miramos el código de estado de la petición podemos ver que es 404 (recurso no encontrado):
Por lo que podemos filtrar o por el mensaje «page not found!», o por el código de estado, eliminando todos los resultados que contengan un código 404.
Finalmente, podemos tener las siguientes opciones:
* Filtrando por «page not found!»:
* Filtrando por el código de estado:
La salida que obtenemos es:
Por tanto, hemos encontrado 5 posibles rutas. Vamos a empezar a investigar:
Si miramos en /denied encontramos lo siguiente:
Si entramos a /login vemos que hace una redirección, ya que tiene un código de estado 302. Esta información ya la teníamos de nuestro escaneo con ffuf:
Primera flag
Solución 1
Para encontrar la primera flag podemos sencillamente analizar la petición que se hace a /login y en la respuesta podemos ver la flag y un mensaje «Access to this portal can now be found here»
Solución 2
Como vemos que hace una redirección, podemos analizar la petición con burp y tratar de modificar el código de estado 302 por un 200. Esta técnica se conoce como Bypass 302.
Lo primero que tenemos que hacer es ir a burpsuite y seleccionar la opción de «capturar respuestas» para ello iremos a Proxy-Options-Intercept Server Reponses y marcaremos la casilla «Intercept responses based on the following rules»:
Intentamos acceder al endpoint /login:
Le damos a forward y es aquí cuando veremos la respuesta:
Modificamos el 302 por un 200:
Le damos a forward y si miramos en nuestro navegador, veremos el contenido de /login:
¡¡Ya tenemos la primera flag!!
Si intentamos acceder a /lawyers-only podemos ver que hace una redirección a /lawyers-only-login
Esto podemos verlo con burp de la siguiente forma:
Capturamos la petición a /lawyers-only:
Y capturamos la respuesta, como se puede observar tenemos un código de estado 302 (redirección) y si miramos el campo «location» podemos ver que redirige a /lawyers-only-login:
Lo podemos comprobar continuando con la ejecución de peticiones. Se envía un get a /lawyers-only-login:
Y obtenemos una respuesta con código de estado 200:
La página que se nos muestra contiene un panel de login:
Tras intentar varios ataques de fuerza bruta sobre el usuario y contraseña sin éxito, decidí buscar posibles subdominios:
Segunda flag
Para enumerar subdominios mediante fuerza bruta, recomiendo usar una herramienta llamada «dnsrecon». Su funcionamiento es bastante sencillo:
- con el parámetro -d le indicamos el dominio que queremos enumerar
- con el parámetro -D le indicamos el wordlist que vamos a utilizar
- con el parámetro -t le indicamos el tipo de enumeración que queremos efectuar. En este caso, bruteforce (brt)
para más información sobre el uso de dnsrecon recomiendo visitar el manual:
Podemos ver que hemos encontrado un subdominio interesante «data.vulnlawyers.co.uk». Vamos a ver qué tiene:
Tercera flag
Ahora que hemos encontrado un nuevo subdominio, podemos empezar a enumerar directorios potenciales:
Encontramos una ruta potencial (users), vamos a echarle un ojo:
Al final del json podemos ver la tercera flag.
Cuarta flag
Si analizamos el contenido del json podemos ver que hay una lista de nombres y de correos, ¡qué curioso!
¿En qué sitio habíamos visto un panel de login?
Efectivamente, anteriormente habíamos encontrado un panel de login, pero no habíamos conseguido acceder a él. Con esta nueva información podemos intentar un ataque de fuerza bruta:
Lo primero va a ser guardar los emails que hemos encontrado en un archivo. Seguidamente, tenemos que ver qué información se envía cuando intentamos acceder:
Podemos ver que hay un campo «email» y un campo «password». Con toda esta información, podemos empezar con nuestro ataque de fuerza bruta:
¡Bingo! Hemos conseguido unas credenciales válidas
jaskaran.lowe@vulnlawyers.co.uk:summer
Vamos a intentar acceder:
Hemos conseguido acceder y ya tenemos la cuarta flag.
Quinta flag
Si nos fijamos en la captura de arriba, podemos ver que se indica que solo el case manager (Shayne Cairns) puede hacer cambios en el caso.
Además, hay un botón «Profile» que nos lleva a «/lawyers-only-profile», pero si intentamos actualizar el perfil nos salta el siguiente mensaje de error: «Updates are currently disabled»
Vamos a mirar el código fuente:
Podemos ver un endpoit bastante curioso: /lawyers-only-profile-details/4
Vamos a ver qué información esconde:
Tal y como se puede ver, podemos ver la contraseña del usuario y hay un ID. Esto tiene pinta de IDOR (Insecure direct object reference).
Si ponemos ID 5 obtenemos la información de Marsha Blankenship:
Y si ponemos ID 2 encontramos la información de Shayne Cairns (la manager):
¡Ya tenemos la quinta flag!
Sexta flag
Vamos a acceder con las credenciales que hemos conseguido.
Vemos que sale un botón «Delete Case», vamos a darle:
Sorprendentemente, conseguimos la sexta flag. No es necesario hacer nada más.
Con esto terminamos el reto. Espero que os haya gustado y, lo más importante, que hayáis aprendido.
Que la Fuerza os acompañe
DiegoAltF4
Inicio
Deja una respuesta