NASA - Client-Side Auth Bypass via Match & Replace
By @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
Learn to find this bug
A real Bugcrowd report, reproduced for you to practice.
Create your account and practice real bugs that got paid. Download the environment, find it and learn the exact technique — your path to your first bounty.
- hunters training
- 650
- labs from real reports
- 50
- completions
- 380
- in bounties practiced
- $200,000
hunters training
labs from real reports
completions
in bounties practiced
Access to all labs · no commitment · cancel anytime
Hunters who solved it· 8
Objectives
Achievement you'll earn
Solve this lab to unlock this shareable achievement
NASA - Client-Side Auth Bypass via Match & Replace
Community writeups
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".