NASA - Client-Side Auth Bypass via Match & Replace
Por @gorkaEl portal de admin del registry de contenedores de ORBITAL Systems Agency (OSA) confía en el código HTTP del login para decidir si redirigir al dashboard. Las credenciales por defecto `admin/admin` siguen reconocidas por el backend, que responde 401 pero emite la cookie de sesión administrativa. Bypassea con Burp Match & Replace y obtén acceso total al panel
Este hackeo se reportó sin recompensa
Aprende a encontrar este bug
Un hackeo real de Bugcrowd, reproducido para que lo practiques.
Crea tu cuenta y practica bugs reales que se pagaron. Descarga el entorno, encuéntralo y aprende la técnica exacta — tu camino a tu primer bounty.
hunters entrenando
labs de hackeos reales
completaciones
pagados por estos bugs
Acceso a todos los labs · sin permanencia · cancela cuando quieras
Hackers que lo han resuelto· 8
Objetivos
Logro que recibirás
Cuando resuelvas este lab desbloqueas este logro compartible
Writeups de la comunidad
La checklist que repaso en cada objetivo nuevo
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
OSA opera un registry OCI bautizado OrbitVault, alojado en registry.orbital.systems. El portal del registry expone una landing pública de "Mission Control" con métricas en vivo, un login en /account/sign-in, y, una vez autenticado, un dashboard al estilo Harbor con proyectos, repos, activity logs, operadores y una bóveda de secretos.
El equipo de plataforma migró su SSO a una nueva versión durante el ciclo 2025 (codename "Halley", release 2.3.1). El "v0 fallback" — un camino de auth heredado que respondía AUTH_001 con un 401 informativo para que los terminales de tierra antiguos pudieran re-disparar el handshake SSO — quedó enabled en auth.legacy.v0Fallback. La intención del desarrollador era: "si el backend ya no acepta admin/admin como credencial válida (devuelve 401), entonces es seguro dejar el branch".
Lo que el desarrollador no notó: aunque el handler devuelve 401, sigue ejecutando res.cookie(...) para que el "SSO bridge" pueda recoger la sesión iniciada. La cookie es la JWT firmada con el rol admin. Cuando esta respuesta llega al navegador, el navegador acepta la cookie (las cookies se procesan a partir de los headers, no del status) — solo el frontend, mirando res.status === 200, descarta el login.
Burp Match & Replace permite reescribir la línea de status antes de que el navegador la entregue al SPA. El SPA cree que el login fue exitoso, redirige a /dashboard, y la cookie ya está presente: pleno acceso administrativo.
La asimetría sutil — que solo admin/admin produce cookie en el 401 — es la "puerta trasera" que el atacante debe descubrir. Pistas distribuidas (un comentario JSX/HTML en la landing, una nota interna en robots.txt, y un comentario "internal note" en /.well-known/security.txt) apuntan a la combinación.
La flag vive en GET /api/v1/secrets/master-tokens, accesible solo con cookie de admin. Se muestra dramáticamente en /system/secrets como "Master Registry API Token" con un glow ámbar y badge "EXPOSED · OPERATIONAL".
