Enumeración
En primer lugar, voy a realizar un escaneo de puertos con nmap:
Veo que se encuentran abiertos los puertos 22, 80, 8080 y 631.
Voy a ingresar en los puertos 80 y 8080 (el puerto 80 tiene la particularidad de que utiliza el protocolo HTTPS, mientras que el 8080 usa HTTP).
Ingresando al puerto 80 no encontré nada interesante de momento, simplemente un mensaje que dice “nothing to see”.
En el puerto 8080 me encontré con una página de una criptomoneda llamada “Bandit-Coin”.
También hay una sección /burn.html, la cual permite quemar tokens:
También intenté ingresar al puerto 631 para ver con que me encontraba y por lo que veo no tengo acceso:
Investigando un poco encontré que el puerto 631 es comúnmente usado para servicios CUPS, el cual es un servicio que proporciona una interfaz web para gestionar impresoras. A parte por lo que puedo ver en el título de la pestaña, está usando la versión 2.4.7. Probablemente este puerto me sirva para más adelante sacarle provecho.
Lo que voy a hacer ahora es una búsqueda de directorios ocultos para el puerto 8080:
Se encontraron una gran cantidad de directorios, de los cuales no puedo acceder a casi ninguno debido a un error 403, lo cual significa que no tengo permisos para acceder.
Voy a realizar lo mismo para el puerto 80:
Al ingresar en /Access me encuentro con un login:
A continuación lo que hice fue buscar todos los archivos que se encuentran en la IP, tanto para el puerto 80 como para el puerto 8080, lo hice con gobuster:
gobuster dir -u http://10.10.191.220:8080 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt -x php,txt,js,json
Y encontré que hay un archivo /services.html, que contiene los detalles del estado del ecosistema:
Explotación
Investigando el código fuente de la maquina note este fragmento de javascript:
const response = await fetch(`/isOnline?url=${serviceUrl}`, { method: 'GET' });
El cual puede llegar a representar una vulnerabilidad, ya que el navegador está enviando una petición al backend con una URL externa como parámetro. Esto nos habilita a poder enviar cualquier otra petición para probar y que sea interpretada como correcta, ya que la enviamos desde una url conocida.
Voy a interceptar la conexión con burpsuite para ver si le puedo montar un servidor propio y pasarlo como parámetro en la url.
El primer paso es montar un servidor con Python:
Python3 –m http.server 8000
Luego voy a pasar mi dirección IP junto con el puerto en la url desde burpsuit:
Lo que voy a hacer ahora es utilizar un payload que me permita realizar un bypass y así poder ingresar en las url que estaban bloqueadas. El payload es el siguiente:
import sys
from http.server import HTTPServer, BaseHTTPRequestHandler
if len(sys.argv)-1 != 1:
print("""
Usage: {}
""".format(sys.argv[0]))
sys.exit()
class Redirect(BaseHTTPRequestHandler):
def do_GET(self):
self.protocol_version = "HTTP/1.1"
self.send_response(101)
self.end_headers()
HTTPServer(("", int(sys.argv[1])), Redirect).serve_forever()
Lo voy a guardar bajo el nombre server.py y voy a dejarlo escuchando con el siguiente comando:
python3 server.py 5555
Para finalizar me dirijo a burpsuit y voy a pasar como parámetro de url mi dirección ip:5555, adicionalmente a la petición de burpsuit hay que agregarle ciertos valores para que el bypass se realice con éxito. Este es el payload que hice en burpsuite:
GET /check-url?server=http://10.10.11.155:5555 HTTP/1.1
Host: MACHINE_IP:8002
Sec-WebSocket-Version: 13
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: nf6dB8Pb/BLinZ7UexUXHg==
GET /flag HTTP/1.1
Host: MACHINE_IP:8002
¡Y es un éxito! Logre acceder a /env
Por lo que obtuve en /env me doy cuenta que estoy ante una aplicación “java spring boot”, por lo que me puse a buscar vulnerabilidades de java spring boot y encontré una vulnerabilidad que parece ser la mas conocida para este tipo de aplicaiones y es la de “Spring Boot Actuator Exposed“. Básicamente implica que la aplicación deja expuestos los endpoints.
Dejo acá el enlace del cual obtuve esta información:
https://github.com/pyn3rd/Spring-Boot-Vulnerability
Para este punto voy a realizar lo mismo que en el paso anterior solo que esta vez en lugar de /env voy a usar /mappings (este es un endpoints donde se almacenan todas las rutas).
Acá me encuentro con datos sumamente valiosos. Veo una ruta /admin-creds y otra ruta /admin-flag.
Al ingresar en /admin-creds obtengo unas credenciales: username:hAckLIEN password:YouCanCatchUsInYourDreams404
Y en admin-flag obtengo la primera bandera:
Lo que voy a hacer ahora es dirigirme a /Access del puerto 80 para probar esas credenciales que encontré:
Y así logro ingresar. Al realizar el login me lleva directamente a /messages. Es una aplicación para chatear y por lo que veo ya hay un chat iniciado en hakalien y Jack.
Analizando las solicitudes veo que en la pestaña “network” del inspector al enviar un mensaje se realiza una petición POST a /send_messages.
Además analizando el código fuente encontré un archivo /statics/messages.js en donde encontré otra ruta /getMessages.
Me voy a dirigir a burpsuit para analizar las tres solicitudes (/messages, /send_messages y /getMessages).
En /send_messages se me indica que la petición no es la correcta, ya que se trata de un GET y debería ser un POST, al modificarlo obtengo un mensaje de recibido.
Todas las solicitudes que realicé son HTTP/2, no hay muchas posibilidades de hacer smuggling en HTTP/2, a menos que podamos forzar al servidor a que use HTTP/1.1.
Voy a pasar la petición a HTTP/1.1 para ver si es compatible:
Y por lo visto si es compatible.
Lo que se me ocurre es que puede ser vulnerable a H2.CL, este es un ataque en donde el frontend recibe una petición HTTP/2 y el backend entiende solo HTTP/1.1. Si logro manipular el Content-Length, puedo hacer que el backend se descincronice e inyectar una petición que se ejecute con la sesión de otro usuario.
Me arrojo un error 503, lo que significa que logré desincronizar al backend, ahora me dirijo hacia /getMessages para ver si pude capturar algo.
¡Y así encuentro la última bandera!
Espero que este tutorial te haya ayudado!