I often get asked ‘how do I find my first bug’ on the Hacker101 Discord channel. This article is an answer to that question.
At this point I assume you’ve been studying the basics of ethical hacking. If you have no background in IT I would recommend reading “The Web Application Hacker’s Handbook”; though those with prior IT experience might choose to skip that and jump directly to the Web Security Academy. This is the go-to educational material for people new to ethical hacking.
But how to actually find your first bug? Which program should you hack on, and what kind of bugs should you focus on? Many say you should hack on private programs where there’s less competition, but in order to actually get invited to private programs you’ll often need a few valid bugs first.
I’d recommend a big program with lots of subdomains as your first program. On HackerOne this would be the US Department of Defense (DoD). This program has more than a million subdomains. A similar program on BugCrowd is Comcast.
For a program of this size it is important to do good recon. You’ll want to find which of the million+ servers are online, and what they’re running.
Recon can roughly be broken down into 4 steps:
1) Find subdomains
2) Check which are alive
3) Check what they’re running
4) Check for vulnerabilities
For the fist step you can use findomain and amass. Findomain is great for quickly getting a list of subdomains, and amass is used for brute forcing even more subdomains. It is important to run those tools regularly as new subdomains are often created.
Next use httprobe to check your list of subdomains and see which are alive. As with the above tools, you should run this regularly. I run it weekly and usually get 20-50 new subdomains that just came alive. As you can imagine, if you’re the first hacker to check these chances are great that you’ll find a bug.
To find out what’s running on these servers you can use ffuf and a good wordlist. A wordlist is something personal that includes paths to vulnerabilities you’ve previously exploited. As a beginner you can base your wordlist on raft from Seclists, as well as wordlists shared by other hackers. In time, you’ll be able to create your own wordlist.
Another very useful tool that I’ve started to use is nuclei. This is a scanner that can be used to identify running services and even find vulnerabilities directly. I’d recommend you to get familiar with it, as it is very powerful.
So now that you have a huge list of servers and know what they’re running, how should you proceed? What kind of bug should you look for? Common wisdom is to look for the 3 ‘easy’ bug types: XSS, IDOR and Business Logic. However, on a program the size of DoD and Comcast I don’t believe this is the way forward for a complete beginner; it is too easy to get lost in the huge amount of subdomains and not spend enough time on one subdomain to find those kinds of bugs. In my opinion, a more ‘top down’ approach is better.
By ‘top down’ I mean look for the low hanging fruit using the tools you’re already using. Look for exposed phpinfo files and server-status, see if there’s a forgotten .git repo that includes admin credentials. I’ve personally found and reported all these mentioned bugs, and they took maybe 15 minutes to find.
This approach works on these programs because they are so big that there’ll always be easy bugs to find. Since they don’t pay bounties more experienced hackers usually don’t waste their time on them; they’re practically a beginner’s playground.
An even more fruitful approach is to go for CVEs. CVE stands for Common Vulnerabilities and Exposures and is basically a known vulnerability that affects a large subset of systems. Some of those are incredibly easy to exploit, and if you look for them early (usually within a few days of publication) it’s possible to find a good number of vulnerable systems. The recently released CVE-2020-3187 is a good example: an exploit was released for it in July and vulnerability could be proved just by fetching to paths. I’d recommend you to keep an eye on Twitter where exploits are often published.
Let’s say you’ve discovered an exploit for a brand new CVE on Jira systems. How do you quickly find which servers are vulnerable? This is where your prior recon work pays off, as by now you should have a database of subdomains and what is running on them, thanks to ffuf and nuclei. So all you have to do it grep for Jira or a common Jira path in your recon files, check if it’s vulnerable and write a report.
In time you’ll want to automate most of this. I’ve made a simple recon automation framework using bash here that I run once a week. It alerts me when new subdomains come alive and does a basic nuclei scan on them, looking for low hanging bugs. In the few months I’ve used it it has helped me find several valid bugs.
Hopefully this article will help you find your first few bugs that’ll lead you to some private invites. Good luck!