NASA - Rails Approval Bypass via Mass Assignment
By @gorkaPortal ficticio de aplicación a programas de investigación de la agencia espacial AURORA. El backend, escrito como Rails 7, procesa el registro vía `params.require(:user).permit(...)`. La whitelist incluye accidentalmente los flags internos `approved` y `active`, lo que permite a cualquier solicitante crearse una cuenta pre-aprobada y obtener acceso al área restringida en un solo POST Autora del Fallo:https://www.linkedin.com/in/isabela-l1ghtn1ng/
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 - Rails Approval Bypass via Mass Assignment
Community writeups
AURORA Mission Research Gateway es un programa ficticio de la agencia espacial AURORA cuyo objetivo declarado es coordinar el acceso de investigadores externos a datasets restringidos, mission briefs y canales de curaduría. El portal es la cara pública del programa: investigadores institucionales rellenan un formulario, justifican su solicitud y quedan en una cola de revisión que el equipo de Curator Operations procesa en 2-4 semanas.
El portal está construido sobre un stack Ruby on Rails 7 con Passenger como upstream, nginx como reverse proxy y un set de cabeceras canónicas (X-Runtime, X-Request-Id, Set-Cookie: _aurora_session=…; HttpOnly; SameSite=Lax). Los formularios incluyen el típico <meta name="csrf-token"> y un hidden <input name="authenticity_token"> HMAC-signed con TTL de 1 hora — el backend valida ambos.
Internamente, el controlador UsersController#create recibe los parámetros bajo el namespace user[…] clásico de Rails y los filtra con params.require(:user).permit(...). Esta whitelist se comparte con un flujo interno de "partner onboarding" que el equipo usa para crear cuentas pre-aprobadas para instituciones aliadas, y por eso incluye los campos approved, active y role además de los visibles en el formulario público. Nunca se separaron las dos rutas; ambos casos pegan al mismo endpoint con la misma whitelist.
Las cuentas creadas por el formulario público arrancan con approved=false, active=false porque el HTML no envía esos campos, y los valores por defecto del modelo son false. Pero un atacante que inspeccione /api/me ve los nombres exactos (approved, active) en la respuesta JSON — y al re-emitir el POST de registro añadiendo esos parámetros, la whitelist los acepta tal cual y la cuenta queda creada ya aprobada y activa, saltándose por completo la cola de curaduría.
La flag vive en el campo classified_token del archive AUR-RA-003 ("Operation Blackpoint — Restricted Research Token") dentro de la sección "Restricted Archives" del dashboard interno, accesible solo bajo approved=1 AND active=1.
Flag
$ ./flag/verify.sh
FLAG{0ce371287c7f4067db1a7ac6f46da93d}
# o directamente:
$ printf '%s' 'aurora::rails::mass_assignment::approved_flag_internal_token' | md5sum
0ce371287c7f4067db1a7ac6f46da93d -
Preimagen: aurora::rails::mass_assignment::approved_flag_internal_token
Algoritmo: MD5 · Flag: FLAG{0ce371287c7f4067db1a7ac6f46da93d}