Bug Bounty: How I found my first bug
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 - 8.9 (High) or 9.0 - 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 third and final goal is to make more than $10,000 in bug bounty.
Goals Overview
- Find a valid bug with a CVSS rating between 7.0 - 8.9 (High) and 9.0 - 10.0 (Critical) on the HackerOne bug bounty platform, triaged by the team.
- Earn more than $1 in bounties, regardless of the amount.
- Achieve a total of more than $10,000 in bug bounty earnings.
Following a Methodology
As evidenced by my MSc research dissertation project I believe the best way to find success in bug bounty is to use your own custom hacking methodology. Methodologies provide us (the tester) a structured approach to testing, ensure comprehensive coverage of applications, assets, content and networks, and the identification of security risks and vulnerabilities. Methodologies ensure consistency, ensure that the tester doesn't repeat themselves unintentionally and helps 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.
Movitvation & Inspiration
The reason for choosing the United States Department of Defence 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 are in use because perhaps the developer thinks as this is just a testing environment it doesn't need to be as secure as production 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 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 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 Bombals 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 to 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 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 servers to perform large scale scanning and with this, in mind, I set out to rent a digital ocean droplet and started scanning the DoD '.mil' top-level domains (TLD) for known vulnerabilities using vulnerability scanners such as nuclei.
Department of Defence - DoD
To meet my first goal of discovering my first bug on 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 so finding common low-hanging vulnerabilities using a standard methodology of Google Dorking '.mil' domains, poking around, scanning and trying to exploit common vulnerabilities (SQLi, XSS, LFI/RFI, File Uploads, CSRF, SSRF, IDOR, Authorisation and Authentication) 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 NahamSec YouTube video where he talks about paying for features in an 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, 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
This was going to be the start of my methodology where I sought to root out the low-hanging fruit vulnerabilities first in the background while digging deeper into other assets however while testing I received a notification using notify to my Discord that nuclei had already found a high severity/impact vulnerability, at this point I got excited and went to validate the bug to ensure it was not a false positive and to ensure I could create a proof-of-concept for my bug bounty report.
Although the methodology I followed was successful in finding my first bug in the future I will employ a more application analysis-focused methodology which will focus on going deep into an application/API instead of going wide where I did here although recon is the most important (and boring) step in any methodology there are mainly two approaches to bug bounty hunting which is going wide and diving deep and then going deep and diving deeper into an application and it's functionality.
Key Takeaways
For me to achieve my goal of finding at least one bug on a bug bounty program I knew I had to do something that other hackers weren't doing. If we all use the same tools, techniques and methods we are all going to find the same bugs however if we can change some aspects even a little bit we immediately separate ourselves from the competition and open up new avenues for ourselves to discover vulnerabilities on assets that may not even be discovered yet. The key here for me was doing something others weren't doing. It's not like I chose a quiet program to hack on, the DoD is a very busy VDP program and I thought because of this I wasn't going to be able to find bugs but with a little bit of research and with some outside the box thinking I achieved my first goal of finding a bug in bug bounty!
UPDATE: The bug report has now been publicly disclosed and can be read here.