Forem: arturo melgarejo

Baby-Cached WriteUp

arturo melgarejo — Thu, 12 Feb 2026 15:10:46 +0000

El challenge consiste en un Side-Server Request Forgery, y alguna cosa mas que hay que resolver antes de poder conseguir la flag.
Es un reto de la categoría Web en HackTheBox, siendo su dificultad Facil , pero originalmente catalogado como Medio. Esta retirado, por lo que no hay problemas en hacer writeups.

El funcionamiento de la pagina es el siguiente: Le pasas una URL y el te devuelve una screenshot de la misma.

Explotación
No haría ni falta ver el codigo, ya que analizandolo con Burp y inspeccionando la web nos damos cuenta que no hay apis escondidas, ni nada mas.

El único input que podemos explotar entonces es la pagina web. No obstante aunque sepamos que es un SSRF, necesitamos ver como explotarlo y que grado de severidad tiene, para eso inspeccionamos el codigo. Observamos que dentro de las rutas disponibles hay una que carga una imagen flag.png. No hay mas preguntas señoria. Ese es nuestro objetivo. Pero solamente se puede acceder si url origen es 127.0.0.1.

Vemos una llamada a una función cachear_web

Como curiosidad, aunque no nos va a hacer falta para nuestro reto, no nos deja usar FTP o GOPHER en vez de HTTP en la url para poder pivotar a otros servicios. No es relevante. Además vemos que se realiza una comprobación de si el hostname REAL que le hemos pasado es localhost o alguna forma de llegar directamente hacia el mismo.
Esto provoca que el exploit no sea tan sencillo de poner simplemente http://127.0.0.1/flag por ejemplo.

Entonces ¿Como lo explotamos?. Aunque no lo he mencionado, usa Selenium, para cargar la web y posteriormente una vez cargada o pasados 10 segundos, lo que antes ocurra, hace una screenshot.

La clave esta en saber que es selenium. Selenium es un webdriver que tiene librerías disponibles en varios lenguajes de programacion. Esencialmente permite la automatización de paginas web humanizando el proceso, es decir, abre el navegador literalmente en la maquina como si fueras tu mismo. Vamos a bypassear por tanto los filtros con nuestra propia pagina web.
La idea es muy simple: Crear una pagina web que cargue contenidos de una url de la misma maquina (127.0.0.1), de esta forma no le pasamos directamente un 127.0.0.1, si no que le pasamos un html que carga contenidos de esa web deseada.

En un principio me complique y empece a hacerlo con javascript, cosa que hubiera funcionado y es totalmente legitima… ¿lo es?
No, no lo era xd, por alguna extraña razon (ya que es mas complejo que la segunda solucion), habían deshabilitado javascript. Puede ser por seguridad. No lo vi.

Vamos a hacerlo mucho mas sencillo. Los pasos son los siguientes:

Crearemos una web con Flask que cargue una imagen desde 127.0.0.1
Bypassearemos los firewalls de nuestra casa con un proxy inverso del estilo ngrok o en mi caso el de cloudfare.
Finalmente, enviaremos a la web vulnerable la url de la nuestra.

Codigo del servidor:

app.py

from flask import Flask, send_file, request, jsonify, render_template
from werkzeug.utils import secure_filename

aplicacion = Flask

app = Flask(__name__)
@app.route('/upload', methods=['POST'])
def upload_reenviada():
 if 'archivo' in request.files:
  archivo = request.files['archivo']
  filename = archivo.filename
  archivo.save(os.path.join('upload', secure_filename(filename)))
  return "ok"
 return "error"

@app.route('/1', methods=['GET'])
def pagina_principal():
 return render_template('prueba.html')

if __name__ == "__main__":
 app.run('0.0.0.0', 80)

La ruta upload es un extra para usar javascript y enviar el archivo desde el cliente.

prueba.html

<html>
<body>

<img src="http://localhost/flag">

</body>
</html>

Comandos bash reverse proxy — Cloudfare y setup servidor

python3 app.py
./cloudflared-linux-amd64 -url http://localhost:80

La url que devuelva cloudfare, se la pasamos a la web vulnerable con la ruta /1.

Flag

CandyVault - WriteUp

arturo melgarejo — Thu, 12 Feb 2026 15:00:42 +0000

Este es el primer WriteUp que escribo en la pagina de dev.to. La razon principal de empezar a crear estos writeups es porque considero que el documentar que es una buena forma de medir y guardar el progreso, asi como contribuir y ayudar en el aprendizaje de otros.

Introducción
Este reto pertenece a la categoría very-easy de los challenges Web de HackTheBox. Cuando tengo poco tiempo realizo este tipo de retos, ya que solo sueles tener que romper la lógica, o vulnerar una vez, no tienes que encadenar varios fallos de diseño o vulnerabilidades.
Este reto consiste en explotar una vulnerabilidad de NOSQL injection, mas especificamente, usa MONGODB.

Fase de reconocimiento y búsqueda de vulnerabilidades

Sin necesidad de replicar la instancia del proyecto en Docker, descargamos el archivo de proyecto y navegamos hasta ./challenge/application.

Al editar el archivo app.py, reconocemos que el servidor usa como framework Flask. Normalmente se suele usar Django para aplicaciones web con python, pero en este caso usan Flask que es mas para pequeñas webs, aplicaciones en desarrollo que requieren de un servidor web, y en general para pruebas sobre proyectos. Por esa razon se suele obviar cambiar el modo de Debug a Producción. No obstante nuestro servidor usa en run.py:

debug=False

Ademas, vemos que la aplicacion usa MongoDB. Para conectarse usa una clave que la coge a través de config.py, y el mismo hace una llamada a una variable de entorno que no podríamos leer. Por tanto (parece) que a menos que podamos leer las variables de entorno o un objeto que queramos, no podríamos acceder a la BD.

Sin mucho mas analizar el archivo, que es muy sencillo y no tiene mas módulos que app.py, nos damos cuenta que cuando nos autentiquemos nos devolverá la flag.

user = users_collection.find_one({"email": email, "password": password})

if user:
    return render_template("candy.html", flag=open("flag.txt").read())

Fijémonos que a demas de decirnos que es lo que tenemos que hacer, ya nos da una gran pista sobre que rumbo tomar para explotar la aplicación:

if content_type == "application/x-www-form-urlencoded":
    email = request.form.get("email")
    password = request.form.get("password")

elif content_type == "application/json":
    data = request.get_json()
    email = data.get("email")
    password = data.get("password")

hmm… Curioso ¿Porqué una aplicacion querria aceptar tanto json como POST normal? Obviamente porque quieren que lo veamos y vayamos directos al grano. Aqui ocurre una especie de error parecido al de deserialización con PHP para usar objetos y conseguir explotación remota. Solo que en nuestro caso, lo usaremos para hacer una injección a mongodb.
Sabemos que una petición “normal” en json seria

{
  "email": "ejemplo@medium.us",
  "password": "2024miperro"
}

Y tambien sabemos que la aplicacion usa data.get(), lo cual nos permite poder crear un objeto diferente a una string, ya que en python las variables se les define el tipo/objeto en tiempo real

Además (Estamos cooking), con un poco de investigacion, vemos que la función find_one, toma operadores como $eq, $gt, $lt, y $ne.

Estos fitros se le pasan a la función find_one en forma de objetos de los campos, como

{"password": {"$lt": 5}}
/
variable["password"]["lt"] = 5

Bueno pues podemos usar $ne=null para que nos devuelva cualquiera que no sea nulo. Con esto y un bizcocho en teoría habríamos vulnerado la aplicacion.

Ahora solo falta explotarla

Explotación
Para la fase de explotación, realizaremos lo siguiente:

Interceptaremos la petición post de un login normal en BURP.
Cambiaremos el valor de los campos user y password a los de (en formato json) a “password/login”:”$ne”:null, con su sintaxis adecuada.
Además, para que la aplicacion acepte el json, cambiaremos el header de … url-encoded … a application/json. Consecuentemente dejaremos una linea de espacio entre los header de http y el inicio de nuestro nuevo JSON.
Disfrutar de nuestra flag.