The Goal

Getting a letter of recognition from NASA's Vulnerability Disclosure Program is an accolade that many security engineers and students pursue. Any valid, non-duplicate security vulnerability gets you the letter. I'll walk through the exact strategy I used to find one.

What I Tried First

I started with recon and enumeration. I mapped out NASA’s in-scope assets and started manual pentesting looking for common vulnerabilities.

After a few days, I had nothing meaningful to report. Most of NASA’s web presence is educational and public-facing: games for kids, public datasets, educational portals, static websites. These systems lack sensitive data or sensitive features that would make vulnerabilities impactful and more common.

Because of this, I was left looking for infrastructure-level bugs, but everyone scans their infrastructure and this doesn’t change that often. NASA is one of the most heavily submitted programs on BugCrowd, so there are a lot of eyes on these assets.

Finding What Actually Works

I shifted to research. I read blog posts from people who got NASA letters and talked to other researchers who had done it.

I spotted a pattern of exposed secrets and default credentials.

Many of the successful reports were API keys pushed to public repos, database credentials in source code, default admin credentials, and other leaked information.

NASA works with a lot of PhD students who work on open source projects, Jupyter notebooks, and systems without always focusing on operational security.

These bugs are pretty easy to find, and this is enough for the letter.

Google Dorking

I started Google dorking for exposed secrets on nasa.gov domains and GitHub repositories. I created my dorks based on what I saw in past successful reports. If people were finding exposed API keys, I searched for API keys. If they found secrets, I searched for secrets.

Here are some Google dorks you can use to search for potentially sensitive data on NASA domains:

site:nasa.gov ("api_key" | "apikey" | "api_secret" | "access_token" | "secret_key")
site:nasa.gov (filetype:env | filetype:config | filetype:ini | filetype:yml) ("password" | "secret" | "api_key")
site:nasa.gov ("aws_access_key_id" | "aws_secret_access_key" | "AKIA" | "S3_BUCKET")
site:nasa.gov ("DB_PASSWORD" | "DB_HOST" | "DB_USER" | "connection string" | "mysql://" | "mongodb://")
site:nasa.gov (filetype:pem | filetype:key | "BEGIN RSA PRIVATE KEY" | "BEGIN PRIVATE KEY")
site:nasa.gov (filetype:bak | filetype:backup | filetype:old | inurl:backup)
site:nasa.gov (filetype:env | filetype:config | filetype:yml) ("password" | "api_key" | "secret" | "token" | "apikey")
site:nasa.gov (inurl:admin | inurl:config | inurl:backup) (filetype:env | filetype:config | filetype:log) ("password" | "api_key")

I found several exposures and submitted reports.

Every single one came back as a duplicate.

But this validated my approach. The methodology worked. The problem was timing. These bugs aren't hard to find, NASA has lots of these issues, and other people are actively looking for them.

The Solution: Timing

I needed to be first. If I couldn't be first to find old exposures, I needed to catch new ones as soon as Google indexed them.

My strategy became a daily routine. Every day at 6 PM, I ran the same Google dorks with the filter set to the past 24 hours. In Google search: Tools > Any Time > Past 24 Hours.

I committed to this every day for a month. Most days I found nothing at all. I knew this would work. I just had to be first to find and report something valid.

Day 28

On day 28, something new appeared.

A nasa.gov domain had fresh content indexed. PhD students had pushed code that included paid API keys to a public repository.

I found exposed API keys and verified them immediately. I identified the services by googling the product names, confirmed the keys were still active, and assessed the potential impact. These were paid API keys connected to active accounts, not trial keys.

I documented the exposure and submitted my report within 30 minutes.

This led to two accepted medium-severity findings and the NASA letter of recognition.

Additional Dorks

Don’t stop with just Google dorking. Use your dorks to find where code lives, then search directly there. GitHub and public Bitbucket repos have native search that’s more powerful for digging through code.

org:example-org "api_key" extension:py
org:example-org "password" filename:.env
org:example-org pushed:>2024-01-01 "secret"
repo:example-org/example-repo "token" extension:json

Once you find active repos, track them. New pull requests and merges are when mistakes get pushed.

Final Thoughts

This method is replicable and easy to do. I knew exposed secrets were being found regularly. I just needed better timing.

You can automate this workflow but for my goal of just getting the letter it wasn’t worth it.

Set aside the time, run your searches, and eventually you’ll catch something fresh.

Good luck with getting your NASA letter of recognition.