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/
This hack was reported with no reward
Learn to find this bug
A real Bugcrowd hack, 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
labs from real hacks
completions
paid out for these bugs
Access to all labs · no commitment · cancel anytime
Hackers who solved it· 8
Objectives
Achievement you'll earn
Solve this lab to unlock this shareable achievement
Community writeups
The checklist I run on every new target
47 checks ordered by cost: first what can get you in trouble, then the cheap stuff, and finally the expensive stuff — which is where the big bounties are. I'll send it to your inbox right now.
Unsubscribe in one click, from any email.
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}
