Introduction

El Bandito, la nueva identidad del infame Jack el Explotador, ha irrumpido en el dominio de la Web3 con una estafa de tokens fraudulenta. Explotando la esencia descentralizada de la blockchain, creó y distribuyó tokens fraudulentos, engañando a los inversores y socavando la confianza fundamental del ecosistema DeFi de las finanzas descentralizadas.

Al embarcarnos en este nuevo desafío, queda claro que hay más en juego que nunca. Para tener éxito, debemos infiltrarnos en su red, descifrar sus estrategias y anticiparnos a sus movimientos antes de que pueda volver a atacar.

La misión ha evolucionado: ahora debemos capturar a El Bandito. Esto requiere sumergirnos en el submundo digital, utilizando astucia y habilidades técnicas para superarlo y restaurar la seguridad.

Getting the Flags

Reconocimiento Inicial

Lo primero que vamos a hacer es mirar qué puertos están abiertos, como siempre.

Después vamos a investigar sobre los puertos abiertos en profundidad.

Después de esto vamos con la enumeración de directorios.

Empezaremos con el puerto 80:

CAUTION: Debemos poner https al listar para el puerto 80, porque si no nos redirigirá y no será posible conectarse.

Ahora vamos a ver que hay en el proxy (8080):

Profundización

Vamos a ver que hay en la web. Vamos a arrancar BurpSuite para ir mapeando el sitio web.

Puerto 80

Nos encontramos con esto, pero si miramos el código fuente de la página:

Vamos a ver qué hay en esa ruta.

Es un documento JavaScript con varios endpoints y un par de nombres de usuario. Lo que conseguimos sacar en limpio del archivo es:

Endpoints:

• /getMessages
• /send_message

Usuarios:

• JACK
• OLIVER

Vamos ahora a mirar en los directorios que encontramos en este puerto.

El endpoint /ping parece un endpoint muerto.

En el endpoint /access hay un formulario de login, interesante.

Hemos acabado con lo descubierto en el puerto 80, vamos ahora con el 8080.

Puerto 8080

En la página inicial hay una página web.

Navegando por la página vemos que sólo hay dos endpoints:

• En Services tenemos /services.html. Interesante, posible SSRF.
• En Burn Token está /burn.html.

Si probamos la funcionalidad de /burn.html vemos que no hace nada, por lo que vamos a mirar el código fuente.

Vemos que no hace nada efectivamente, pero hay algo muy interesante y que debería de llamarnos la atención teniendo en cuenta que venimos de una unidad basada en Request Smuggling con contenido de WebSockets.

Vamos ahora a buscar en los directorios que encontramos antes. Empezando por /configprops ya que /assets está vacío.

Parece que sólo hay información sobre el framework. Si buscamos en internet "spring framework endpoints" llegamos a la página de la Documentación Oficial.

Puede que nos sea útil más adelante.

Vamos a continuar con /health.

Ahora vamos con /info.

Vamos con /mappings.json.

Acabamos de sacar el mapa de endpoints disponibles (aunque ahora no todos están disponibles para nosotros sabemos que existen). Los que hemos encontrado son:

• /admin-creds
• /admin-flag
• /token
• /isOnline
• /error
• /heapdump
• /autoconfig
• /trace
• /health
• /dump
• /configprops
• /env
• /metrics

Está claro que saltan a la vista /admin-creds y /admin-flag, pero vamos a seguir con nuestra rutina de escaneo.

Ahora nos toca /heapdump.

Parece que nos ofrece descargarlo en lugar de mostrarlo en web. Si lo descargamos e intentamos leerlo vemos que es un binario con muchísimos caracteres. Vamos a probar con strings. Si lo revisamos hay algunas líneas más largas que otras. Parece que hay peticiones, vamos a ver si alguna se ha hecho con credenciales.

Acabamos de encontrar unas credenciales, vamos a seguir. Ahora con /swagger-ui.html.

Primera Flag

Para obtener la primera flag parece que vamos a tener que usar la técnica de los WebSockets para conseguir un Request Smuggling junto con un SSRF para sobrepasar un proxy seguro, como hicimos en los puntos 2 y 3 de la lección de WebSockets (THM -> 1. Career -> 3. Web Application Pentesting -> 5. HTTP Request Smuggling -> 3. Request Smuggling - WebSockets).

Ahora sí que abrimos BurpSuite, con todo lo que hemos hecho debería estar mapeado.

Vamos a escoger la de /isOnline porque necesitamos saber que funciona el SSRF antes de proceder.

Para ello la mandamos al repetidor y cambiamos la URL por la del servidor que montaremos.

Ahora vamos a levantar el servidor. Para ello vamos a usar un simple nc por ahora, sólo queremos asegurarnos de que funciona.

Mandamos la petición.

Funciona, hay SSRF.

Ahora vamos a probar a ver si una simple funciona, pero esta vez vamos a utilizar python, para no tener que estar levantando el servidor todo el rato.

Ahora sí, vamos al lío. Vamos a mandar una petición de WebSocket Upgrade a la URL nuestra (SSRF).

CAUTION: Recuerda desactivar la opción de Update Content-Lenth y de dejar siempre dos líneas por debajo de la petición.

Parece que nos hemos topado con el mismo problema que el el punto 3 de la lección de WebSockets. Sabemos esto porque el "403 Forbidden" que vemos no viene del servidor, sino del proxy, Nginx.

Para solucionar esto tenemos que hacer que nuestro servidor al que apunta el SSRF devuelva el código 101 Switching Protocols para que el proxy piense que de verdad hemos migrado el protocolo hacia WebSockets.

Para conseguir esto vamos a usar el siguiente código de Python:

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 guardamos y ejecutamos:

Volvemos a probar a mandar la petición.

Ahora sí que ha funcionado, vamos a obtener las credenciales del administrador, recordemos el endpoint /admin-creds:

Son las mismas credenciales que obtuvimos con el archivo descargado desde /heapdump.

Vamos ahora a ver la flag del admin.

Segunda Flag

Para la segunda flag vamos a empezar entrando al /access que nos encontramos en el puerto 80 utilizando las credenciales obtenidas durante la obtención de la primera flag.

Una vez dentro nos encontramos con esto:

Además, podemos obtener acceso también al endpoint /getMessages gracias a la cookie de sesión verificada obtenida al iniciar sesión.

Vamos a probar a mandar un mensaje.

Se actualiza tanto en la pestaña del chat como en la de /getMessages.

Como está reflejada, se me asemeja a una técnica de request smuggling, vamos a probar.

Abrimos de nuevo BurpSuite y miramos el mapa.

Esto es lo que nos interesa.

Lo mandamos al repetidor y lo vamos a modificar un poco. Primero lo vamos a dejar así:

Y ahora vamos a hacer el smuggling de la segunda petición. La dejamos así:

Vamos a mandarla hasta que se quede "colgado".

Hemos conseguido hacer smuggling de una petición pero no ha sido suficiente longitud para leer la flag, si es que está aquí.

Vamos a probar con más longitud: 800.

Parece que tampoco ha sido suficiente.

Después de mucho rato intentándolo y que no saliera me frustré y pensé igual no lo está mandando todo el rato el login, así que me puse a escribir mensajes de Content-Length: 100 y salió este patrón.

Después de muchísimos intentos conseguimos la flag. Resulta que el número más consistente para obtener respuesta fue 730. Aunque hay una parte que está encodeada en unicode.

El último paso sería convertirla por ejemplo con CyberChef.

Conclusión

La primera parte fue muy divertida de encontrar y explotar. Sin embargo, la segunda flag fue mucho más difícil hasta que me di cuenta de que lo que tenía que hacer era encontrar el número bueno para que no se quedase colgado.

Sea como sea hemos conseguido obtener ambas, completando así nuestra primera máquina de dificultad difícil y dejando muy claro que nunca hay que rendirse (no exagero si digo que he estado más de 3h sólo para la segunda flag).