Contenido del lab

Escenario

Kanbia es un clon de Trello: organizas el trabajo del equipo en tableros con listas y tarjetas. La organización Nébula Studio tiene una clave maestra (rota API keys, SCIM y exports) que solo debería ver un administrador, en Ajustes de la organización › Seguridad. Esa clave es la flag.

Tú eres un miembro normal: attacker@kanbia.local / password123. Tu objetivo es leer esa clave maestra sin ser administrador.

Qué tienes

• Tu cuenta de miembro, con acceso a los tableros del equipo (punto de partida, no es el fallo).
• El panel de organización con tres pestañas: General, Miembros y Seguridad (bloqueada para ti).

Guía paso a paso

1. Recon. Entra en Ajustes › Seguridad: te dice "Solo administradores". El servidor decide tu rol; no basta con tocar el cliente. Mira ahora en el proxy/Network las peticiones que lanza la app al arrancar: entre ellas hay una a GET /api/config.

2. Tu sesión es un JWT. Coge tu token (cookie kb_token o localStorage.kb_token) y decodifícalo (jwt.io). El payload trae role: "member". Si solo cambias member→admin y reenvías, el servidor responde 401: la firma ya no cuadra. La firma sí se valida; te falta la clave para firmar tú.

3. La fuga. Abre la respuesta de GET /api/config. Junto a datos inocuos (nombre de app, flags de features) viaja auth.signingKey: la clave con la que el servidor firma los JWT. No debería salir nunca del servidor.

4. Forja el token. Reconstruye tu JWT con role: "admin" y fírmalo con HS256 usando esa signingKey (en jwt.io pega la clave en "your-256-bit-secret", o con un script). Obtienes un token admin con firma válida.

5. Captura la flag. Envía GET /api/org/settings con Authorization: Bearer <token_admin> (o guarda el token en kb_token y abre Seguridad): ahora responde 200 y muestra la clave maestra de la organización: FLAG{…}.

Canales de feedback (no vuelas a ciegas)

• El panel bloqueado nombra explícitamente el requisito ("Solo administradores") → el rol es lo que importa.
• Cambiar el role sin re-firmar da 401 → la firma se valida de verdad; necesitas el secreto.
• /api/config devuelve la signingKey en claro → confirmas la fuga al instante.
• Con el token admin, /api/org/settings pasa de 403 a 200 con masterKey → sabes que escalaste.

Decoys (descártalos por razonamiento)

• El control de rol no está roto: requireAdmin valida bien y un token mal firmado se rechaza. El fallo es que el secreto se filtra, no la verificación.
• La pestaña Miembros (/api/org/members) lista a todo el equipo, pero no contiene la clave maestra: no es la vía.
• El resto de /api/config (features, límites de subida) es ruido verosímil: el único campo peligroso es auth.signingKey.

La falla del laboratorio

Clases: uso de credencial/secreto expuesto (CWE-798), verificación de firma inefectiva por secreto comprometido (CWE-347) y escalada por control de acceso roto (CWE-285), con divulgación de información sensible (CWE-200). OWASP A01:2021 (Broken Access Control) + A02:2021 (Cryptographic Failures) + A05:2021 (Security Misconfiguration).

La raíz es una sola: un secreto de servidor viaja al cliente. El endpoint de configuración mezcla datos públicos con la clave de firma de los JWT; a partir de ahí toda la criptografía de sesión es papel mojado, porque cualquiera puede emitir tokens válidos con el rol que quiera. La verificación de firma —correcta en sí misma— deja de proteger. La defensa: los secretos de firma viven solo en el servidor (secret manager), se rotan, y un endpoint que consume el cliente jamás debe incluirlos; como defensa en profundidad, no derivar autorización sensible únicamente del role del token sin revalidar contra la base de datos.

Laboratorio basado en la reproducción anonimizada (empresa ficticia Kanbia) de una técnica real de bug bounty: escalada de privilegios por filtración de la clave de firma de sesión.