PART 2: THE NEXT CHAPTER IN MY NASA BUG HUNTING JOURNEY 🚀

.

Hello, everyone!
My name is xabit , a cybersecurity researcher, first-year computer science student, and part-time bug hunter. Welcome back to the second part of my story! If you haven’t read the first part yet, go check it out to learn how I discovered an EXIF metadata vulnerability in NASA’s system, only to have it categorized as P5 (informational).

That P5 categorization left me frustrated. Imagine reporting something you believed could make an impact, only for it to be downgraded. But instead of giving up, I decided to channel my frustration into finding a bug they couldn’t refuse — a report that would leave no doubt about its significance.

Let’s dive in.

Starting Fresh: A New Mindset

I had already completed the recon phase earlier, so this time, I shifted my focus. My goal: find critical bugs related to sessions or login pages — the backbone of any secure system.

I tested the usual suspects:

• Account takeovers
• Cross-Site Request Forgery (CSRF)
• Stored XSS
• SQL Injection (SQLi)

But NASA’s defenses were solid, and none of these worked.

Next, I tried more advanced techniques:

• Server-Side Request Forgery (SSRF)
• Host Header Injection

Still nothing.

The Breakthrough: Weak Session Management

Then came a breakthrough! I shifted my attention to session management, a critical aspect of web application security. Let me explain how this works:

When you log in to a secure application, the system assigns you session cookies, which act as your identity for the duration of your session. These cookies should expire as soon as you log out. But here’s what I found:

1. I logged into my account and saved my session cookies using a cookie editor.
2. I logged out of my account and logged back in, expecting the old cookies to expire and new ones to be generated.
3. However, when I tried using the old cookies on another browser, I successfully logged in!

This was a serious flaw in session management. Old cookies should no longer work after logging out, but here, they were still valid.

Reporting the Vulnerability

Excited by this discovery, I carefully documented the issue and submitted the report. According to Bug crowd’s Vulnerability Rating Taxonomy (VRT), this type of flaw should fall under P3 or P4 severity.

NASA accepted the report, which was a small victory! But once again, they categorized it as P5 (informational). I was crushed. 😞

Pushing Forward: The Forget Password Attack

Determined to prove my worth, I decided to focus on an attack that could impact other users’ accounts.

Here’s what I did:

1. I identified a Forget Password page where user enumeration was possible.
2. The system also had a strict brute force protection mechanism.
3. Combining these, I enumerated several email addresses.
4. By intentionally triggering brute force protection multiple times, I caused accounts to get locked, and some even got suspended!

This was a clear security flaw, as it could disrupt user accounts. I reported the issue, confident it would be taken seriously.

But once again, the report was categorized as P5.

What I Learned

At this point, I realized NASA prioritizes its internal security over user-related issues. While I didn’t qualify for a Letter of Recognition (LoR) this time, the experience I gained was invaluable.

I’ve learned to:

• Stay calm under frustration.
• Keep improving my reporting skills.
• Be patient and persistent, even when results aren’t what you expect.

Looking Ahead

I may not have made it to NASA’s Hall of Fame yet, but I’m more motivated than ever. Stay consistent, work hard, and dream big! I’ll keep sharing my future findings, whether they’re with NASA or other websites, so we can help each other grow in this field.If you enjoyed this story, follow me for more content, and connect with me on Instagram: @xabittttt

Thank you for reading, and stay tuned for the next thrilling chapter! 🚀