Cómo conseguí el LoR de la NASA explotando un Authentication Bypass

Hace unos meses veía gente reportando vulnerabilidades a la NASA y sinceramente me parecía una locura pensar que algún día iba a encontrar algo ahí. Después de bastante aprendizaje, práctica y prueba-error, terminé encontrando un Authentication Bypass válido y consiguiendo el LoR (Letter of Recognition).

Contexto

Si bien encontrar la vulnerabilidad me llevó una semana, detrás de eso hubo varios meses aprendiendo, practicando y entendiendo cómo funcionan las aplicaciones web.

Con bases de Linux, redes, programación, bases de datos y ciberseguridad, empecé a interesarme cada vez más por el mundo del hacking ético, especialmente todo lo relacionado con aplicaciones web.

En octubre de 2025, cuando escuché que se podía hackear a la NASA de forma ética y que además lo recompensaban con un LoR, no dudé ni un segundo en que yo también quería hacerlo.

Así fue como, sin mucha práctica, en un fin de semana encontré un Information Disclosure en la NASA haciendo Google Dorking. Consistía en que un subdominio de la NASA referenciaba una carpeta de Google Drive con permisos excesivos, permitiendo modificar, agregar o eliminar la información que había dentro.

Si bien resultó en un P5 (Informational), me sirvió para darme cuenta de que este tipo de reportes (si no tienen un impacto real) es mejor no reportarlos, y que es mejor centrar el tiempo en vulnerabilidades que realmente puedan comprometer la seguridad de la aplicación.

Gracias a eso, me centré mucho más en vulnerabilidades críticas y en entender mejor cómo explotar aplicaciones web correctamente.

Análisis de la superficie de ataque

Scope

Lo primero que hice fue leer y tomar apuntes del scope de la NASA. Esto es algo fundamental porque te permite entender dónde podés buscar vulnerabilidades, qué cosas están permitidas y qué cosas no deberías hacer ni reportar.

CheatSheet

Me hice una guía según las distintas fases (reconocimiento, enumeración, explotación...), para saber qué cosas analizar, probar, qué herramientas eran útiles en qué caso y demás.

De todas formas, más que seguirla al pie de la letra, la fui usando como referencia, porque sobre la marcha terminé cambiando varias cosas, probando enfoques distintos y modificando el orden en que hacía las pruebas. Aun así, esta primera experiencia en bug bounty me sirvió muchísimo para mejorar esa cheatsheet y dejarla mucho más útil para futuros targets.

Reconocimiento y Enumeración

Antes había leído en un montón de lugares "la clave está en el reconocimiento" o cosas del estilo, pero nunca pensé que de verdad fuera tan así.

Si bien el recon es una de las partes más automatizables, decidí hacerlo de una forma más manual, ya que se trataba de mi primera vulnerabilidad y quería entender qué cosas realmente me servían antes de automatizarlas.

Herramientas que utilicé para la enumeración de subdominios:

subfinder -d dominio.com -o sub_subfinder.txt
assetfinder --subs-only dominio.com > sub_assetfinder.txt
amass enum -passive -d dominio.com -o sub_amass_passive.txt
findomain -t dominio.com -q -u sub_findomain.txt
sublist3r -d dominio.com -n -o sub_sublist3r.txt

# Combino y unifico todos los resultados
cat sub_*.txt | sort -u > all_subdomains.txt

Con httpx revisé cuáles subdominios tenían servicios HTTP/HTTPS activos y luego utilicé gowitness para automatizar la toma de screenshots de cada web, y así acelerar el análisis de sus interfaces y tecnologías.

gowitness scan file -f all_subdomains.txt -t 20 --write-db
gowitness report server

A partir de ahí, fui revisando subdominio por subdominio para entender y tomar nota de qué hacía cada aplicación, qué funcionalidades tenía y qué cosas me llamaban la atención (inputs de búsqueda, funcionalidades de subida de archivos, formularios con inputs poco comunes, aplicaciones legacy, integraciones con terceros, etc).

Si bien en algunos casos me detenía a probar cosas específicas, personalmente recomiendo NO hacerlo. Es mucho mejor primero analizar todos los subdominios y, recién después, priorizar los que parezcan más interesantes o tengan mayor superficie de ataque.

En los distintos subdominios probaba cosas como:

• enumeración de directorios (ffuf, gobuster)
• detección de tecnologías (Wappalyzer, whatweb)
• identificación de firewalls (wafw00f)
• análisis automatizado de posibles vulnerabilidades como XSS, SQLi, IDOR, entre otras, para descartar rápidamente los casos más evidentes.

Más adelante, para enfocarme específicamente en registros y logins, creé una plantilla personalizada de nuclei que buscaba palabras clave como username, password, sign up, login y similares.

Y sinceramente, esto es probablemente de lo que más recomiendo hacer. Si lográs bypassear algo relacionado con autenticación, permisos o registros, el impacto suele subir muchísimo.

Después de bastante prueba-error y muchos subdominios revisados, llegué a uno que aparentaba ser una aplicación interna de la NASA, con una apariencia bastante legacy.

Como tenía un apartado de registro, lo primero que pensé fue: “registro dos cuentas (víctima y atacante) e intento hacer un ATO (Account Takeover)”.

Pero al completar el registro apareció el siguiente mensaje:

"The site administrator will review your registration and get the necessary security approvals".

Por obvias razones, el administrador nunca iba a aprobar mi cuenta 😔.

Así que tocaba cambiar de estrategia.

Pensándolo un poco mejor, el hecho de que el registro necesitara aprobación manual significaba que no cualquier persona podía acceder a esa herramienta. Y justamente eso hacía que un posible bypass tuviera más impacto.

Entonces el objetivo pasó a ser otro: lograr registrarme sin necesidad de que un administrador aprobara la cuenta.

Explotación

Analizando las solicitudes de registro en el HTTP history de Burp Suite, en una de las pruebas cambié los headers Origin y Host, lo que hizo que el servidor respondiera con un código de estado 422 Unprocessable Entity.

Investigando un poco, vi que ese comportamiento era típico de aplicaciones desarrolladas en Ruby on Rails, especialmente relacionado con sus validaciones y mecanismos de protección como CSRF. Además, si estaba mal configurado, podía ser vulnerable a un Mass Assignment Attack.

Entonces probé inyectar los siguientes parámetros en la solicitud de registro:

&user[role]=admin&user[is_admin]=1&user[admin]=true

La idea era simple: si la aplicación era vulnerable a Mass Assignment, podría modificar atributos internos del usuario y registrarme directamente como admin.

Pero nuevamente, no funcionó.

Entonces, volviendo un poco para atrás: la cuenta necesitaba ser aprobada por un administrador para quedar activa.

Entonces pensé: ¿y si en lugar de intentar registrarme como admin, modificamos directamente el parámetro que controla si la cuenta está aprobada o activa en el backend?

Volví a inyectar parámetros en la request, pero esta vez probando cosas como:

&user[approved]=true&user[approved]=1&user[active]=true

Yyyyy... funcionó!!!!

Después de enviar la petición, el servidor respondió con un 200 OK, permitiendo que la cuenta quedara activa y dando acceso a funcionalidades restringidas de la plataforma sin necesidad de aprobación manual.

Probamos iniciar sesión:

Triaje y Resolución

Me habían comentado que normalmente tardaban entre uno y tres días en dar una respuesta inicial. En mi caso, después de 13 días sin novedades, volví a probar la vulnerabilidad y me encontré con que el bypass de registro ya no funcionaba. Además, las cuentas que había creado tampoco podían iniciar sesión 💀💀💀.

Ahí les aclaré que la vulnerabilidad ya no era reproducible, lo que probablemente indicaba que había sido corregida o mitigada después del reporte inicial.

Aun así, continuaron con el triage. Más adelante, la NASA explicó el impacto de la vulnerabilidad y Bugcrowd terminó clasificando el hallazgo como un P3 (Medium).

Resultado:

Recomendaciones

Para los que estén buscando su primer bug, les recomiendo arrancar por la NASA o alguna empresa grande. Desde mi experiencia, el scope es gigante y, aunque ya llevan más de 12 mil vulnerabilidades reportadas (hasta la fecha de hoy), todavía queda muchísimo por descubrir.

Como academia estructurada y en español, recomiendo Hack4u. Aunque aclaro que, por más guiado que sea el contenido, vas a tener que investigar por tu cuenta constantemente, ya que eso es parte del bug bounty y de la ciberseguridad en general. Yo personalmente hice el curso de introducción al hacking, que para entender cómo funcionan y se explotan las vulnerabilidades del OWASP Top 10 (entre otras), viene muy bien 👌.

Hack4u también tiene un curso específico de hacking web que no puedo recomendar porque no lo hice. En mi caso, preferí estudiar la parte teórica con PortSwigger Academy e ir resolviendo los laborartorios. Que por cierto, según sus creadores, muchos de esos labs están basados en vulnerabilidades encontradas en aplicaciones reales.

También recomiendo entrar en una comunidad. En mi caso, entré a la comunidad de Gorka el Bochi Morillo, en la cual hay hunters muuuy 🔝. Sirve muchísimo para aprender de reportes ajenos, pedir opiniones, resolver dudas y colaborar con otras personas en bug bounty.

Además, Gorka lanzó su plataforma BBLABS, que cuenta con laboratorios basados en vulnerabilidades reales. Es de lo mejor que hay para practicar escenarios que te vas a encontrar afuera en programas de verdad.

Otra recomendación importante: descansar. Cuando estás muy saturado, empezás a perder capacidad de análisis y llega un punto en el que probás cosas sin sentido. En cambio, cuando te alejás un rato o volvés al día siguiente, volvés a pensar con más claridad y eso te ayuda a detectar cosas que antes no estabas viendo.

Por último (y uno de los consejos más importantes): leer reportes de otros hunters de forma consciente. No solo leer cómo explotaron la vulnerabilidad, sino analizar cómo pensaban, cómo llegaron a la idea, qué metodología siguieron, qué patrones identificaron y cómo conectaban conceptos. Ya que eso es lo que de verdad importa.

En mi caso, me armé una base de datos en Notion con resúmenes de reportes, incluyendo impactos, metodologías, PoCs y apuntes reutilizables para otros escenarios.

Acá muestro un ejemplo de cómo organicé mi BD (dentro de cada página tengo el paso a paso, PoCs y notas reutilizables):

Conclusiones

Automatizar el reconocimiento y la enumeración puede ahorrar muchísimo tiempo, pero al final lo más importante sigue siendo entender cómo funciona la aplicación y pensar de forma creativa ("Think outside the box"). Personalmente, esto es algo que pienso seguir mejorando y optimizando.

No esperes que tu recorrido sea igual al mío o al de otros hunters, cada uno construye el suyo. Así que no pienses que esta publicación la vas a poder aplicar al pie de la letra. Tal vez te toque un entorno similar, pero lo más probable es que no. Esto te puede servir como guía para conocer herramientas, formas de pensar, metodologías, técnicas y entender que cada uno termina creando su propia forma de hacer bug bounty con la práctica.

Esperá N/A, P5 y duplicados. Y cuando te toquen, no te desilusiones, porque también son señal de que estás progresando.

Te aseguro que es divertido, aunque no voy a negar que a veces puede ser un poco estresante. Pero si realmente te gusta, lo vas a disfrutar. Y cuando menos lo esperes, te va a llegar ese email diciendo que aceptaron tu reporte, y ahí te vas a dar cuenta de que todas esas horas aprendiendo y probando cosas valieron totalmente la pena.

Ahora dejá de leer y andá a aplicar lo aprendido, que esos bugs no se encuentran solos!!!

Timeline

• 28 de marzo de 2026: Comienza mi búsqueda de vulnerabilidades en la NASA.
• 4 de abril de 2026: Descubro y reporto a través de Bugcrowd una vulnerabilidad.
• 17 de abril de 2026: Vuelvo a probar la vulnerabilidad. Descubro que ya no era reproducible y que las cuentas utilizadas en las pruebas habían sido deshabilitadas.
• 23 de abril de 2026: La NASA proporcionó información sobre el impacto de la vulnerabilidad.
• 27 de abril de 2026: Bugcrowd clasificó el hallazgo con severidad P3, marcando el reporte como “Triaged”.
• 28 de abril de 2026: La NASA cambió el estado del reporte a “Resolved”, confirmando que la vulnerabilidad había sido solucionada, y me envió la Letter of Recognition (LoR).