NASA - Rails Approval Bypass via Mass Assignment
Por @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/
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.
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}
