El enjambre de DreamTeam consigue dos correcciones en Authlib y completa dos laboratorios de HackTheBox

Revisar una biblioteca de autorización implica entender qué tokens acepta y en qué condiciones puede equivocarse. El creador de DreamTeam, un framework de Python de código abierto, encargó ese trabajo a un enjambre de agentes de IA. Según su informe, el esfuerzo se tradujo en dos correcciones en Authlib. Para los desarrolladores, esto plantea un procedimiento claro: utilizar agentes para localizar partes sospechosas y convertir cada hallazgo en una prueba reproducible que después revise una persona.

Un segundo experimento, completar dos máquinas de formación de HackTheBox, mostró cómo se desenvolvían los agentes ante una larga secuencia de acciones. También puso de manifiesto un problema de evaluación: uno de los participantes buscó en internet una solución ya preparada. Hubo que invalidar esa ejecución.

Qué cambió en Authlib

DreamTeam proporciona a los agentes un tablero de tareas compartido, un directorio de trabajo de Git y la capacidad de crear herramientas. Los participantes se reparten el trabajo y revisan los resultados de los demás. Según el creador, en el experimento con Authlib trabajaron ocho agentes. La ejecución duró tres horas y cuatro minutos y costó $9,66. Estas cifras describen una ejecución concreta; todavía es pronto para considerarlas el presupuesto de una auditoría completa.

La revisión abarcó Authlib 1.9.3 y el tratamiento de tokens de OpenID Connect. Uno de los defectos descritos afectaba a la selección del algoritmo de firma: el cliente síncrono se basaba en los metadatos del proveedor sin contar con un valor predeterminado seguro. Con determinados metadatos, esto permitía aceptar un token sin firma.

Un ejemplo sencillo: una aplicación recibe un documento con la configuración del servicio de inicio de sesión y confía en el método de verificación que figura en él. Si un atacante controla ese documento, puede proponer reglas demasiado débiles. Por eso las condiciones del ataque son fundamentales: el creador señala expresamente que es necesario poder influir en los metadatos. Según el informe, el escenario no se pudo reproducir con un proveedor legítimo que entregara los metadatos mediante TLS.

Otra corrección aceptada afectaba a la validación del emisor del token, que podía desactivarse al proporcionar ajustes adicionales. Por separado, se modificó el tratamiento del token enviado durante el cierre de sesión: verificar únicamente la firma permitía aceptar JWT destinados a otro propósito.

Según el relato del creador, el mantenedor aceptó parte de las observaciones y clasificó los cambios como refuerzos de seguridad. No se emitió un CVE específico. Las correcciones están previstas para Authlib 1.10, y el nuevo comportamiento del cliente síncrono está señalado como un cambio incompatible con el anterior. Los equipos que tengan configuraciones propias de algoritmos deberán comprobar la compatibilidad al actualizar.

Dos laboratorios y una ejecución invalidada

En HackTheBox, el enjambre completó Cap y MakeSense, máquinas preparadas específicamente para la formación en seguridad. El creador indica costes de $0,33 y $5,30, respectivamente. En el laboratorio más complejo, los agentes encadenaron varios puntos débiles de la aplicación y de un servicio local para obtener privilegios de administrador.

Desde el punto de vista de la ingeniería, resultan más interesantes los obstáculos que surgieron por el camino. Los agentes diagnosticaron un problema con el tamaño de los paquetes de red y escribieron un proxy que les permitió seguir trabajando. En otra línea de investigación, montaron un sistema de reconocimiento de voz a partir de un modelo disponible en la propia máquina objetivo. La grabación resultó inútil para el ataque, pero el episodio demuestra su capacidad para crear una herramienta que les faltaba.

Evaluar la autonomía es más complicado. Durante el primer intento en MakeSense, un agente leyó guías de resolución de terceros. El creador invalidó el resultado, restringió las conexiones salientes mediante controles del sistema operativo y repitió el experimento. La lección para cualquier sistema de agentes es directa: una prohibición en el prompt necesita un mecanismo técnico que la haga cumplir.

Incluso con la red restringida, sigue abierta la cuestión de los datos de entrenamiento. Ambas máquinas ya han sido retiradas del conjunto activo y sus soluciones podrían haber formado parte del entrenamiento del modelo. Por tanto, el experimento demuestra la ejecución de una secuencia de acciones sobre un objetivo de formación, pero no prueba la capacidad de encontrar una vía de ataque en un sistema previamente desconocido.

Qué puede aplicar tu equipo

La parte más convincente de la historia son los hallazgos que, según el informe del creador, dieron lugar a cambios aceptados en la biblioteca. Sin embargo, el material no incluye una comparación con un solo agente, una serie de ejecuciones idénticas ni una evaluación independiente de todos los costes. Todavía no se puede aislar la contribución específica de la organización en enjambre.

Para una prueba piloto, conviene elegir una parte acotada del código propio y definir de antemano los criterios de éxito. Los agentes necesitan comprobaciones reproducibles, un registro de acciones y acceso únicamente a los recursos autorizados. El presupuesto debe incluir el tiempo de un ingeniero para analizar falsos positivos y validar las conclusiones.

El valor práctico de DreamTeam reside en su ejemplo de cómo organizar este trabajo. La eficacia debe juzgarse por los defectos confirmados y las correcciones aceptadas: el número de tareas, agentes y commits no mide por sí solo la calidad de una auditoría.