The Fun Story of My First NASA 🌏Hall of Fame…💥

Hello Hunters,

Here i share my fun story of My First NASA Hall of Fame, One fine day, I was exploring a NASA website as part of my routine bug hunting activities. As usual, I started with information gathering. I fired up DirBuster, a tool that’s quite popular among bug hunters for brute-forcing directories and files on web servers. Using a common wordlist, I set it to perform a recursive search to see what hidden gems I could find.

To my surprise, the tool uncovered two URLs that seemed to be related to the admin panel of the website after i analyzed the source code of the web pages and i found two more gems. ( it takes half a day But its worth it) The pages were:

• index.php
• config.php
• upgradenx.php
• sendstudia_functions.php

At first glance, these pages were blank when I visited them in the browser, but I knew better than to stop there. Understanding that these pages were probably part of the backend, I decided to check the source code of these pages. And that’s when things got interesting.

The Source Code

When I viewed the source code of the admin pages, I found something that was exposing Server Side Source Code. The code was exposing sensitive details that shouldn’t be visible to anyone accessing the site. My heart raced a little; I thought I had struck gold. Without hesitation, I prepared my bug report and submitted it to Bugcrowd, the platform NASA uses for its VDP.

The First Rejection

I eagerly awaited a response, confident that I had found something of value. But when the reply came, it wasn’t what I expected. The report was marked as “Not Applicable” with the following message: “In order to be a triaged issue, a submission must demonstrate an impact that can have an effect on the customer.”

I was taken aback that time i am sure that exposing source code of admin pages of a server-side page was a vulnerability. So, I did what any determined bug hunter would do — I turned to Google. A quick search showed that many bug bounty programs on platforms like HackerOne do indeed reward source code disclosure without requiring any specific impact beyond the fact that the code is exposed.

Armed with this knowledge, I decided to contest the decision. I filled out the “Request a Response” form on Bugcrowd, explaining why this is vulnerability and this issue should be triaged. Then, I waited.

Silence from Bugcrowd

A week went by, and I heard nothing. Frustrated, I did some more research and discovered that when a vulnerability is closed as “Not Applicable,” Bugcrowd often does not respond to further inquiries. This was disheartening, but I wasn’t ready to give up just yet.

Analyzing and Refining My Approach

I took a step back and decided to reanalyze the pages I had found. This time, I focused on clearly documenting the potential impact of the vulnerability. I realized that my initial report might have been too vague or not sufficiently persuasive. So, I reworked the report, adding specific details and screenshots showing the sensitive data exposed in the source code.

However, when I submitted this new report, it was rejected again. This time, the response was that the vulnerability was “Not Applicable.” This was puzzling and frustrating because I knew the vulnerability existed. Yet, it seemed like I wasn’t getting through to the triaging team.

The Breakthrough

At this point, I was determined to make my case. I decided to simplify my report even further. I focused on just one URL — the one that clearly exposed sensitive database information, including usernames and passwords. I crafted a new report with the following structure:

• Title: Sensitive Database Information Disclosure
• Description: Briefly described vulnerability
• Steps to Reproduce: Provided clear, step-by-step instructions with screenshots.
• Impact: Title of the impact

This time, I was cautiously optimistic. I submitted the report and waited for the “Not Applicable”

The Sweet Taste of Success

Finally, the response came. But it was different this time. The report was triaged! I had done it! The vulnerability was accepted, and I was awarded my first Hall of Fame recognition from NASA.

Here’s the fun fact: This was the same vulnerability I had reported twice but along with more possibilities of vulnerability with the same screenshot and my title was admin page server side source code disclosure. before. The only difference was in how I presented it. This experience taught me a valuable lesson about bug bounty reporting: clarity and precision are key.

Lessons Learned

Keep it Simple and Clear:

• Your report’s title should clearly define the vulnerability.
• The description should be concise, ideally just a couple of lines.
• Steps to Reproduce must be straightforward, leaving no room for doubt.
• The impact should focus on the most significant possible consequences.

Don’t Give Up:

• If your report is rejected, don’t take it personally. Analyze the feedback, refine your approach, and try again.

Final Thoughts

Earning a spot in NASA’s Hall of Fame was a huge milestone for me. It wasn’t just about finding a vulnerability; it was about learning how to communicate effectively and not giving up, even when things didn’t go my way. The experience taught me that every setback is an opportunity to improve, and every rejection is a step closer to success.

So, if you’re a bug hunter out there facing rejections, remember this story. Stay persistent, keep refining your reports, and never underestimate the power of clear communication. Your Hall of Fame moment might be just around the corner!

Happy Hacking…💣💥