Bug Bounty: How I Found My First Bug (Part 1)
UPDATE: The bug report has now been publicly disclosed and can be read here.
I have always set myself three personal goals when it comes to bug bounty. My first goal was to find a valid bug with a CVSS rating between 7.0 and 8.9 (High) or 9.0 and 10.0 (Critical) on the HackerOne bug bounty platform. The bug doesn't have to be rewarded with a bounty. However, it must be valid, and it has to be triaged by the triage team. It wouldn't count if it was closed as informational, N/A, or as a duplicate bug. My second goal in bug bounty is to make more than $1 in bounties. The actual figure of the reward does not matter as long as it exceeds $1, and my final goal is to make $10,000 in bounties (total).
Goals Overview
- Part 1: Find a valid bug with a CVSS rating between 7.0 - 8.9 (High) or 9.0 - 10.0 (Critical) on the HackerOne bug bounty platform, triaged by the team.
- Part 2: Earn more than $1 in bounties.
- Part 3: Achieve a total of $10,000 in bug bounty earnings.
Following a Methodology
I believe the best way to find success in bug bounty is to use your own custom hacking methodology. Methodologies provide us (the testers) a structured approach to testing, ensure comprehensive coverage of applications, assets, content, and networks, and identify security risks and vulnerabilities. Methodologies ensure consistency, ensure that the tester doesn't repeat themselves unintentionally, and help the tester keep detailed notes throughout the engagement.
A good structure to start a methodology should include the following:
- Reconnaissance (Recon)
- Enumeration/Content Discovery/Scanning
- Discovery of Vulnerabilities
- Exploitation - POC
- Reporting (Prove impact!)
Methodologies change depending on what and who we are testing, but the structure remains similarly the same. In this blog, we followed a cloud recon methodology to discover vulnerabilities in the DoD VDP bug bounty program, focusing on their cloud infrastructure.
Motivation
The reason for choosing the United States Department of Defense and choosing to hack on their cloud infrastructure is motivated for a few reasons:
- A. Infrastructure hosted in the cloud commonly is used for testing and development, which means that software might not be configured properly, authentication may be lacking, or default/guessable credentials may be in use because perhaps the developer thinks, as this is just a testing environment, it doesn't need to be as secure as the production environment, and/or because since development infrastructure won't be listed anywhere publicly, perhaps it cannot be found (security through obscurity).
- B. Development environments frequently contain software that is under construction, which may not be adequately configured. This can lead to the inadvertent exposure of API keys, passwords, tokens, and other sensitive information.
- C. Test environments may run outdated software, rendering them more susceptible to exploitation.
The core reason behind wanting to hack on the DoD program is because... It's cool, and who doesn't want to be able to say that they hacked the U.S. military?
Cloud Recon
The cloud recon methodology was inspired by a prominent security professional, Jason Haddix, who gained prominence for developing the bug hunters methodology for both application analysis and recon. Jason was a guest on David Bombal's YouTube channel in a video they both did where, at the end, Jason demonstrated how to perform cloud recon and the advantages it can have for a bug bounty hunter.
We can imagine that this methodology has since been used a lot in the BBP space. However, I'm not sure it has been used as much in the VDP space (as of the time of writing this post), largely because in VDP programs you don't often get rewarded with a bounty ($$$) for your research, and as such hackers may not invest in server infrastructure (VPS) to perform large-scale scanning.
With this in mind, I set out to rent a DigitalOcean droplet and started scanning the DoD '.mil' top-level domains (TLD) for known vulnerabilities using vulnerability scanners such as nuclei.
Department of Defense - DoD
To meet my first goal of discovering my first bug in a bug bounty program, I set about looking at the many different programs that exist on the HackerOne platform.
The American U.S. Dept. of Defense stood out to me because the DoD program had (at the time of writing) way over 20,000 resolved submissions, which means that many hackers are actively hacking on this program, which means competition is going to be high.
Finding common low-hanging vulnerabilities using a standard methodology of Google Dorking '.mil' domains, poking around, scanning, stuffing payloads into input forms, and trying to exploit common vulnerabilities (e.g., SQLi, XSS, LFI/RFI, CSRF, SSRF, IDOR, etc.) probably wasn't going to work as well or as easily and will most likely take up a lot of time trying to do what everyone else is already doing.
The trick here is to do what others are either not willing to do or have not thought of doing yet. This approach is emphasised in the NahamSec YouTube video where he talks about paying for features in applications to unlock more functionality for further testing, as many hackers may not be as willing to financially invest in hacking on a program.
Discovering My First Bug
What I did was download all of the TLS certificate data for Amazon (AWS), Google (GCP), DigitalOcean, Microsoft (Azure), and Oracle Cloud, then output them all into one big file and parse out the domains with the TLD '.mil' into a separate file, which I then used to vulnerability scan against using nuclei.
grep -oP '\[([^]]+)\]' main.txt | sed 's/\[//;s/\]//' | tr ' ' '\n' | grep -i '\.mil$' | sed 's/^\*\.//' | sort | uniq >> military_domains.txt
Following the methodology displayed in Figure 3, I was able to scan en masse the cloud infrastructure for the Department of Defense and identify a high-severity vulnerability (see Figure 4).
Closing Thoughts
I set out with a very clear goal of wanting to find my first bug in a bug bounty program. I began doing what I believe most people do: Google dork vulnerable endpoints and parameters, stuff payloads blindly, and pray I'm able to exploit something.
This approach unsurprisingly didn't work very well, was very inefficient, and wasted a lot of time, as everyone else who is trying to find their first bug is doing the same thing, and it is more of a spray-and-pray approach with limited thought and skill involved, which ultimately means you aren't learning anything.
Instead I researched successful bug bounty hunters, learnt the tools they use, and the methodologies they follow (Jhaddix & Zseano), adapted it, and applied the methodology against a target with a lot of digital assets to find my first bug!