DEV Community: arturo melgarejo

Orquestacion multiagente con Openclaw dockerizada.

arturo melgarejo — Fri, 17 Apr 2026 19:50:22 +0000

Orquestacion multiagente con Openclaw dockerizada.

Enlace a GitHub

— Un panel de control que gestiona agentes con OpenClaw separados en contenedores Docker por "departamentos", les deja delegarse tareas entre ellos, y mantiene un contexto compartido persistido en base de datos para que no se pierdan en la conversación. En este post enseño como funciona el panel y un poco la logica:

La idea

Cuando OpenClaw estaba todavía en pañales y Paperclip ni existía, se me ocurrió una idea que no me dejaba tranquilo: ¿y si los agentes pudieran hablarse entre ellos de forma estandarizada, con un contexto compartido, como si fueran un equipo de verdad?

De ahí salió este último repo que acabo de subir a GitHub. En resumen, es un software que orquesta agentes, los separa en contenedores Docker y les da una capa de comunicación + delegación de tareas con contexto común. En este post te enseño de lo que es capaz.

El Control Room

Asumiendo que ya lo tienes todo configurado y corriendo — mínimo uno o más contenedores de AGENTE_MCP_API_V2 (sí, horrible el nombre de la carpeta, lo asumo) y un servidor — al entrar te recibe esto:

Te dejo una mini leyenda para que te orientes:

🔴 En rojo — el indicador de si el panel se está comunicando con la API. Si pone CONECTADO, todo ok (o minimo la conexion con el contenedor de la api)
🔵 En azul — un preview en tiempo real de los agentes que están trabajando. Ojo al detalle: si a un agente se le ilumina la cabeza con una lucecita, es que está procesando algo (tiene tareas pendientes).
🟡 En amarillo — el contador de agentes y de departamentos que tienes activos.

Consejo de uso: lo ideal es levantar varias instancias de AGENTE_MCP_API_V2, una por departamento. Así cada grupo de agentes vive en su propia burbuja y no se lían entre ellos pisándose tareas o contexto. Es justo para lo que está pensada la aplicación.

Live Floor

Si pulsas en Live Floor, ves básicamente lo mismo que tienes en la barra de abajo, pero un pelín más fancy: le monté unas mesas a los agentes para que cada departamento tenga su espacio bien separado. Es más escaparate que funcionalidad, pero queda resultón y se entiende de un vistazo quién curra con quién.

Agentes:

En la pestaña de Agentes tienes una vista más detallada de cada uno, y lo importante: aquí puedes gestionar sus contactos.

Y ojo, porque los contactos son vitales: los agentes los leen automáticamente y, en base a eso, saben con quién pueden hablar y con quién no. Por si acaso, también está capado a nivel de API, así que no es solo una barrera "visual".

¿Por qué tanto lío con los contactos?

Para respetar el principio de modularidad del que hablábamos al principio. Imagínate que tienes un developer en un departamento y otro developer en otro: no quieres que se pongan a hablar entre ellos directamente y se monten su propio mundo paralelo.

Lo que quieres es que, si hay que coordinar algo entre departamentos, se comuniquen los CEOs de cada uno — y que ellos ya bajen la información a su gente.

Es la misma lógica que en una empresa real: las jerarquías y los canales de comunicación existen por algo.

Tareas

En Tareas puedes ver todo lo que se está cociendo ahora mismo. Si le das a Cargar historial de tareas completadas, también te aparece la lista completa de lo que se ha ejecutado hasta el momento. Es también el sitio desde el que puedes crear tareas nuevas a mano — útil si no quieres lanzarlas desde Telegram, por ejemplo.

Aviso con la creación: por diseño está un poco "cutre" — hay que indicar que el padre es el mismo que el hijo, pero funciona perfectamente. Nota mental para v2 😅.

Ejemplo de delegación

Para que se entienda, un caso sencillo: creamos una tarea nueva para Alfa pidiéndole que Beta nos prepare un informe. Ahí ya tienes un caso de delegación — Alfa no hace el informe, se lo pasa a Beta, y luego nos devuelve los resultados.

La parte que más mola: el contexto compartido

Aquí viene una de las cosas que más me gustan del proyecto: puedes ver el contexto de la tarea de forma totalmente transparente.

El software integra un sistema de contexto compartido que vive en sesiones y se persiste en la base de datos (los agentes siempre tienen que incluir un resumen, es obligatorio). Y la gracia es esta:

Todas las tareas hijas de una misma tarea padre, y las que estas generen a su vez, comparten el mismo contexto.

Es decir, el "hilo" de conversación entre agentes no se rompe por mucho que la tarea se ramifique.

Aquí un ejemplo real del contexto compartido en acción:

Se ve clarísimo cómo Alfa delega a Beta, Beta completa el reporte, y luego Alfa recoge el resultado — todo dentro del mismo contexto compartido de la tarea. Esta parte me gustó muchísimo desarrollarla, precisamente por lo visual que queda ver a los agentes "hablando" entre ellos.

Reportes

Y para cerrar, la pestaña de Reportes. Cuando una tarea padre (la que tú lanzas desde fuera) termina, el agente detecta que era el origen de la cadena y te genera automáticamente un reporte con lo que ha pasado — o con lo que tú le hayas pedido que te reporte, si lo especificaste. En este caso puedes ver el reporte de la tarea del ejemplo anterior.

¿Y ahora qué?

Esto es una pre pre ante supra beta jajaja, así que sí: tiene rough edges, cosas por pulir y funcionalidades que me gustaría llevar más lejos en una v2. Pero funciona, y creo que la idea de separar agentes en contenedores + contexto compartido persistido + delegación con trazabilidad tiene recorrido.

No se si sere capaz con tantas cosas por hacer de continuarla, pero te animo a ti a que le eches un vistazo, unas horas en entenderlo y aprender, y la mejores!

Si te pica la curiosidad, te animo a echarle un ojo al repo, probarlo y romperlo un rato — cualquier feedback, issue o PR es bienvenido.

Y si te ha gustado el post, sígueme por aquí o en LinkedIn para ver cómo evoluciona el proyecto. 🙌

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.