Contenido del lab

Escenario

Nimbex es una inference cloud: una plataforma SaaS donde los clientes ejecutan modelos de IA a través de una API autenticada por API key. Eres pentester con acceso a la consola de desarrolladores de un cliente. El equipo de seguridad de la organización ya endureció tu API key con una policy (org-hardening) que deniega la lectura del vault de secretos.

Tu misión: demostrar que ese endurecimiento no basta y exfiltrar el secreto de provisioning de la organización (la flag).

Qué tienes

• Una cuenta de consola de demostración: attacker@nimbex.local / password123 — es tu punto de partida, no es en sí la vulnerabilidad.
• Una API key nbx-… restringida, que puedes revelar desde el panel.
• Un plano de API documentado bajo /api/v1 (modelos, inferencia, auditoría y el vault).

Guía paso a paso

1. Recon del control. Revela tu API key y úsala como Authorization: Bearer …. Lee el vault documentado (GET /api/v1/vault). Recibes un 403 que te dice exactamente qué te bloquea: la acción vault:Read, denegada por la policy org-hardening. Conclusión: la key es correcta; es la acción la que está denegada.
2. Introspección de tu policy. Mira el documento de policy adjunto a tu key (panel del dashboard o GET /api/v1/keys/me). Además de las acciones del plano documentado, tu key tiene concedido un namespace de acciones que la navegación de la consola nunca menciona. Cada acción declara el recurso sobre el que aplica.
3. Localiza la superficie oculta. Ese namespace implica un segundo plano de API. Encuéntralo por los rastros que la propia app te da: el visor de auditoría en modo bruto muestra actividad de un origen distinto, con su ruta base; y las cabeceras de respuesta enumeran los planos disponibles.
4. Razona la brecha. El Deny de tu organización enumera una acción concreta. La misma capacidad (leer el vault) existe en el plano paralelo bajo otra acción, con otro nombre, que ese Deny nunca listó. La denegación funciona… pero no cubre esa superficie equivalente.
5. Explota la ruta alternativa. Repite la lectura del vault contra el plano paralelo con la misma key restringida. Esta vez responde 200 y te entrega el vault de la organización, con el secreto de provisioning: la flag.
6. Confirma el punto ciego. Comprueba que esa lectura sensible no aparece en la vista de auditoría por defecto — solo en el modo bruto. El plano paralelo también escapa a la detección documentada.

Canales de feedback (no vuelas a ciegas)

• El 403 del vault documentado te nombra la acción y la policy exactas.
• El panel de policy te enseña qué acciones concede tu key sin que las adivines.
• El visor de auditoría (modo por defecto vs bruto) confirma tu progreso y evidencia la brecha de logging.

Decoys (descártalos por razonamiento acotado)

• Rotar la key no ayuda: la nueva key trae la misma policy — el bypass sobrevive a la rotación.
• El endpoint de diagnóstico ecoa un path pero no lo resuelve (no es SSRF ni path traversal).
• El plano paralelo no es tierra sin ley: una de sus acciones internas está correctamente denegada. El bug es de cobertura, no un motor de policy roto.

La falla del laboratorio

Clase: Broken Access Control por protección incompleta de una ruta alternativa (CWE-424, Improper Protection of Alternate Path), con autorización incorrecta (CWE-863) y logging insuficiente (CWE-778). OWASP A01:2021 (Broken Access Control) + A09:2021 (Security Logging and Monitoring Failures).

El motor de policy es correcto: evalúa Deny sobre Allow con default-deny, y funciona perfectamente en el plano documentado (por eso GET /api/v1/vault da 403). El fallo no está en el código del motor, sino en la cobertura del control:

• La organización desplegó Deny: vault:Read siguiendo la guía de hardening del proveedor.
• Pero existe un segundo plano de API (un "gateway de compatibilidad" heredado) que acepta la misma API key y declara sus permisos con un namespace de acciones propio (…:VaultRead en lugar de vault:Read).
• El Deny del cliente enumera la acción del plano documentado, no la equivalente del plano paralelo → el mismo secreto queda accesible por la ruta alternativa.
• Además, la actividad del plano paralelo registra su atestación en otro campo del evento de auditoría, así que la detección construida sobre el campo documentado no la ve.

Lección: endurecer una credencial por nombre de acción solo protege las superficies cuyos nombres el control enumera. Cualquier plano o ruta alternativa que acepte la misma credencial con otro namespace escapa al control. La defensa correcta es denegar por capacidad/recurso (o cubrir explícitamente todos los planos que aceptan la credencial) y unificar la telemetría de todas las superficies.

Laboratorio basado en la reproducción anonimizada (empresa ficticia Nimbex) de una técnica real de bug bounty sobre un plano de inferencia paralelo no documentado.