This guide focuses entirely on the exploitation phase of a bug bounty hunt. While the preceding phases—reconnaissance and fingerprinting—are crucial preparation, the exploitation phase is where the true hacking occurs.
To succeed in this phase, it’s vital to have deep knowledge of two main areas:
- Technology Stacks: Understanding the vulnerabilities and misconfigurations that impact a wide array of technologies. For example, knowing about GitHub is important when searching for hardcoded passwords or other sensitive information, as security failures can occur when companies use it improperly.
- Web Application Vulnerabilities: Since the vast majority of a company’s public-facing assets are web applications, you must know, at a minimum, the OWASP Top 10 vulnerabilities. The more vulnerabilities you know how to exploit, the better your chances of finding a successful one.
Basic Hacking: Exploiting Known Vulnerabilities
Introduction
One of the first things learned in hacker training is how to identify and exploit known vulnerabilities. This might seem simple, but many people surprisingly skip this foundational phase of the exploitation cycle.
The methodology for exploiting known vulnerabilities generally follows these steps:
- Visit the target application and attempt to determine what software it’s running.
- Once you find the software and version, search on Google and other resources to see if it has vulnerabilities or CVEs (Common Vulnerabilities and Exposures).
- Search for the exploit code.
- Run the exploit code against the target.
Focusing on 1-Days: The Race Against the Patch
Another version of this technique focuses on 1-days (zero-day exploits that have been publicly disclosed for one day).
In this cycle, time is the most important aspect:
- Start by looking at threat feeds such as ExploitDB and Twitter for new exploits and CVEs that have just been dropped. These are known as 1-days.
- When a new exploit is released, you must quickly find a POC (Proof of Concept) for it.
- Immediately begin mass scanning all your targets for that specific vulnerability before defenders have a chance to patch their systems.
Both methodologies are very similar: one starts with a target and searches for known vulnerabilities, and the other starts with a newly released exploit and searches for targets to exploit.
Identifying Technologies
Introduction
When attempting to exploit a target with a known vulnerability, you could blindly launch every exploit available and hope for success, or you can take a smarter approach. Identifying the target technology stack is essential because it helps you narrow down and find the precise exploits impacting that stack. Not knowing this information will leave you blind and guessing which exploits might work.
Wappalyzer
The best place to start when attempting to discover the technologies running on a website is Wappalyzer.
- An alternative is builtwith.com, but Wappalyzer is preferred by many.
- The Wappalyzer browser plugin is excellent for easily determining an endpoint’s tech stack while browsing their website. It can identify technologies like “Ruby on Rails,” “Jquery 3.5.0,” “Backbone.js 1.4.0,” and more .
- A command-line tool version of Wappalyzer is useful for scanning multiple websites at once, which is handy for scanning hundreds or thousands of sites.
Powered By and Manual Checks
Wappalyzer is powerful, but it won’t identify everything. Wappalyzer relies on regexes (regular expressions) in its database, so if a specific technology’s signature isn’t present, it won’t be identified.
For instance, Wappalyzer might come back mostly blank. However, if you look at the footer at the bottom of the page, you might see the words “Powered by Gila CMS.” You can then conclude that this site is running Gila CMS, an important detail that would have been missed if only Wappalyzer was used.
Summary
You need to know the technology stack your target is running to find associated exploits. While there are several ways to determine the technologies an endpoint is running, Wappalyzer is a highly recommended starting point. If Wappalyzer fails, remember that other techniques (like checking the footer or source code) exist to find an endpoint’s technology stack.
Identifying the Vulnerabilities
Introduction
Once you know what software your target is running, the next crucial step is to determine its vulnerabilities. The entire purpose of learning a target’s technology stack is to use that information to find associated security flaws.
Google Search
The first and best resource for answering any question, including security questions, is Google. Try typing the technology name along with search queries like:
[Technology Name] vulnerabilities[Technology Name] exploits
This will often uncover a wealth of information, including SQL injection exploits, LFI (Local File Inclusion) exploits, and much more. It’s recommended to click on the first few links, but don’t be afraid to search deeper, as interesting vulnerabilities can sometimes be buried in a blog post several pages down.
ExploitDB
ExploitDB is an excellent resource for searching and downloading exploit code. It is one of the favorite resources for finding vulnerabilities related to a technology stack.
- You can access the website directly: https://www.exploit-db.com/
- ExploitDB offers a command-line tool called
searchsploit, which you can download from GitHub: https://github.com/offensive-security/exploitdb - You can use it as follows:
./searchsploit “name of technology”
ExploitDB is highly valuable because it often provides the Proof of Concept (POC) code along with the vulnerability details, allowing you to skip the step of having to search for the exploit code separately.
CVE: Common Vulnerabilities and Exposures
The Common Vulnerabilities and Exposures (CVE) system provides a reference method for publicly known information-security vulnerabilities and exposures. If you are looking to find what CVEs a technology stack has, the best place to search is NIST (National Institute of Standards and Technology).
- The NVD (National Vulnerability Database) is hosted by NIST: https://nvd.nist.gov/vuln/search
Searching for something like “Gila CMS” might yield 17 CVEs. Generally, the newer the CVE, the better, as there is a higher chance the target hasn’t patched their systems yet.
Note: Just because you find a CVE doesn’t automatically mean you can exploit it. To successfully exploit a CVE, you need the Proof of Concept (POC) exploit code; without it, exploitation is significantly more challenging.
Summary
Locating the vulnerabilities impacting a technology stack is relatively easy. By combining searches across Google, ExploitDB, and NIST, you should be able to find all the necessary vulnerability information.
Finding the POC (Proof of Concept)
Introduction
You’ve identified that the target application contains vulnerabilities, but to exploit them, you need the Proof of Concept (POC) exploit code. If you don’t have the exploit code, your only remaining option is to create it yourself, which is typically outside the scope of basic bug hunting.
GitHub
One of the best places to find exploit code is GitHub. GitHub is an American multinational corporation providing hosting for software development and version control using Git. Because developers use it extensively for collaboration and version control, hackers also leverage it to share POCs.
- You can easily search for a CVE on GitHub . If a public POC exists, you will most likely find it there.
Note: BE AWARE OF FAKE POCs. These exploits are generally not vetted and come from untrusted third parties. Always test a POC against a vulnerable, controlled machine first before using it on a live target.
ExploitDB
As previously mentioned, ExploitDB is a fantastic resource that often bundles the POC code with the vulnerability details:
Summary
Nine times out of ten, you will find the exploit code you’re looking for on GitHub or ExploitDB. If it’s not in one of those locations, it may not exist publicly, and you may need to consider creating your own POC. However, always search thoroughly; sometimes, the POC code can be buried deep in a blog post after several pages of Google results.
Exploitation
Once you have a working POC, you are ready to test it against your target.
Always recommend setting up a vulnerable machine to test the exploit against first. This allows you to understand the exploit’s behavior and what a successful result looks like before targeting a real environment.
When ready, simply run the exploit on your target and review the results to determine if the system is vulnerable.
Conclusion
Exploiting known vulnerabilities is one of the oldest, yet still most effective, methodologies for securing quick, easy wins in a bug bounty program.
This approach boils down to three simple steps:
- Determine your target’s tech stack.
- Search for any known vulnerabilities impacting that tech stack.
- Run the exploits against the target.
