This blog post will be focusing on how to improve the overall quality of your reports, where to look for bugs in companies that have a bug bounty programme, and the steps to take regarding responsible disclosure of bugs that are eligible for bounty.
This is not a guide on how to find bugs in a technical sense, but rather a case of tactics you can use to find bugs that aren’t already previously reported by someone else – in this post I will be assuming you already have pentesting knowledge and are capable of finding your own bugs, therefore I will not be explaining how to test for vulnerabilities, but rather where to test for them and how to structure the reports once bugs have been identified. This is mainly just a general overview of how someone would map out a target site and efficiently perform reconnaissance to gain as much info on the site as possible before actually beginning their audit.
Other than recon, I won’t be getting into any stuff about methods for actually finding specific vulns themselves, although in the near future I plan on releasing a bunch of tutorials based around identifying and exploiting different kinds of web-based vulns.
What you need to remember about bug bounty programmes is that there is a lot of competition. This isn’t the same as a regular audit for a conventional client, as when performing an audit for a client you’re competing only against the security of the site you’re auditing – when you’re taking part in a bug bounty programme, you’re competing against both the security of the site running the program, and also competing against hundreds or thousands of other people who are taking part in the programme. For this reason, it’s important to think outside the box (as most researchers who have their reports constantly marked as dupes will know). This is why passive and active reconnaissance is especially important for bounty programmes, as you need to look a lot deeper than you would in a regular pentest (to avoid dupes or stuff that’s out of scope)
Which programme to choose:
I’m probably stating the obvious here, but some bug bounty programmes are way easier than others – Ideally you’re going to be wanting to choose a programme that has a wide scope. For example, I see lots of people having success with Yahoo’s bug bounty programme because the entire *.yahoo.com domain is within scope rather than the bounty being limited only to specific subdomains. You’re also ideally going to be wanting to look for a bounty programme that has a wider range of vulnerabilities within scope (for example, many BBP’s would consider stuff such as Open Redirects or Logout CSRF out of scope, whereas other bounties may accept these as valid submissions and even give payouts for more minor stuff i.e. enabled directory listings or missing security headers in HTTP) – the wider attack surface for the bounty programme, and the wider range of vulnerabilities considered valid, then the higher the chance would be of getting a valid payout. Companies that have a large amount of acquisitions within scope are also a good choice (more on this later).
You should also be aware of restrictions with bug bounty programme’s (for example the ability/inability to pay out based on which country you’re in – many bounty programmes will refuse to pay out to people living in certain countries)
Sites like HackerOne and Bugcrowd are a good starting point for deciding which bounty programme you want to partake in (also you’ll probably find yourself getting invites to private bounties after you’ve made a few valid submissions) – xssposed.org is also a unique concept in the sense that anyone can potentially reward you for your work, it doesn’t necessarily have to even be the admin of the site and the site doesn’t necessarily even have to have a bug bounty programme (the admin could see your report, then choose an acceptable reward at their own discretion). Ideally what you’ll want to be working towards is access to private bounties (via bugcrowd after reputation is gained, or via sites such as synack.com) as if the bounty is private, the chances of your submissions being marked as dupes are greatly diminished. There are also sites that have bounty programmes but don’t openly advertise this (vmware.com being one example that comes to mind).
After choosing which bounty programme you’re going to attempt, the next logical step would be to map out your attack surface.
Mapping out an attack surface:
First off, ensure that you have properly read the terms for the bounty and clearly understand which domains are in scope and which forms of vulnerabilities are considered valid reports – one of the worst things you can do is submit things that aren’t within scope of the bounty programme, this tells the people running the programme that you haven’t properly read the terms, and it will lead to them not taking your future reports seriously.
To efficiently begin testing for a bounty programme, you’re going to first have to perform as much passive/active recon as possible in order to effectively map out the site and give yourself an idea of how everything is structured
The larger the potential attack surface, the higher the chance of finding a bug. Assuming all subdomains are within scope, then one of the first steps would be to enumerate valid subdomains (using recon-ng or an online subdomain scanner), the scanner which I will be using is found here https://pentest-tools.com/information-gathering/find-subdomains-of-domain – if you’re using this then be sure to select the ‘include subdomain details’ option because that will allow you to get an idea of how their network is mapped out (In addition to giving you the subdomains that you can begin to start testing on)
Here is an example output of the online subdomain scanner listed above:
Some companies will have entire IP address ranges dedicated to them, for example by looking at the output above, one could assume (not necessarily fact, just an assumption) that the 77.238.184.* range is owned by Yahoo, therefore one could start performing port scans on that range (which brings me to my next pont)
After mapping out the valid subdomains you’re going to want to perform port scans on each of the individual IP addresses associated with said domains, the most efficient way to do this is via nmap from the command line, a simple command will generally suffice:
nmap -T4 -A -v calendar.yahoo.com
use the -Pn flag if the host is blocking your ping probes
It would be best to set something up to automate this, but ideally you want to be scanning each individual IP address associated with their subdomains and having the output saved to a file, after this look for any services running on unusual ports or any service running on default ports which could be vulnerable (i.e. FTPd, SSHd, etc). You’re also going to want to probe for the version info on services running in order to determine whether anything is outdated and potentially vulnerable.
Another thing that should be taken into consideration when doing these scans is that reverse proxies such as cloudflare or similar services may active, in which case it would be necessary to resolve the backend IP addresses (this can actually lead to some nice findings, as companies will assume that since their backend IP isn’t public therefore they won’t worry so much about locking down all of the services (i.e. only ports 80 and 443 opened), determining the backend IP and then scanning could definitely yield some interesting results (i.e. vuln/oudated services running on an open port)
For a site with a large attack surface, you’re really going to be wanting to make notes of everything during the reconnaissance stage to avoid confusion. Take them in whatever manner you want, but since participation in bug bounty programmes involves mainly blackbox testing, it is really important to get a feel of how the site is structured and to map it all out in order to be able to efficiently find bugs.
I’m sure any bug hunters reading this are more than capable of scanning for open ports/services and subdomains, I’m just reiterating it to stress its importance when trying to map out an attack surface on a large site. When looking for bounties, any low-hanging fruits you find are almost undoubtedly duplicates (that being said, they’re still worth reporting just incase), therefore its a good idea to have the network mapped out and to look into any obscure services running on unusual ports.
In addition to this, it’s a good thing to see which security measures are in place before actually carrying out your pentest. By this I mean checking the headers to see which security options are in place, for example looking for presence of X-XSS-Protection: 1; mode=block or X-Frame-Options: deny – knowing what security measures are in place means you know your limitations, which is very helpful when trying to find something eligible for a bounty payout (allows you to be more time-efficient etc). It should also be noted that some bounty programmes even give you a payout for letting them know that certain security headers are missing, so if you see headers missing then that is worth looking into (although for most bounty programmes this will not be eligible).
Checking what security measures are in place also means determining the presence of a WAF, an effective way to do this would be to use WafW00f which can be found here – this will allow you automatically perform fingerprinting to determine whether they have a WAF in place, and if so, what kind of WAF it is (assuming its a commercial WAF).
You’re also going to want to take note of the directory listings and use something like dirbuster to map out the possible contents of those directories assuming they are HTTP 403’d (use robots.txt to determine the directories which may contain useful info, look for the disallow rules).
Once this is done, you should have some notes somewhere with the name of each subdomain, and the following information:
- Backend IP address
- Open Ports / Services running
- Service version info (if applicable)
- server banners
- directory listings
- presence (or lack of) security headers
- presence (or lack of) WAF (+ WAF type)
After this, you’re going to want to build upon these notes with more information (you can either do this all at the start, or you can test each subdomain one at a time and add the info then). You’re going to need to take note of all forms of accepted user inputs (GET/POST/COOKIES) so that you can probe these to check whether your inputs are properly escaped when it comes to actually testing for the vulnerabilities – to automate this just use burp suite or something similar (as long as it doesn’t violate the terms of the bounty, more on this later)
In addition to this, since you’re primarily going to be blackbox testing, it’s a good idea to use OSINT to your advantage to build upon the notes. You need to gain as much information as possible about the backend technologies used by the target site.
First off, Google is your friend – I see a lot of people referring to those who use Google dorks as ‘skids’ or whatever, but if you’re using TARGETED dorks then Google is an invaluable tool for when it comes to pentesting.
For example, lets say that the site you’re testing for the bug bounty programme has all domains in scope, except for their ‘development’ subdomain and their content delivery network – You want to perform more recon to see what kind of technologies that they are running on the domains that are in scope, you could do something like so:
site:example.com filetype:php -development.example.com -cdn.example.com
while changing the filetype: value as appropriate to see which technologies are actually running on the site (this is also very useful during the stage of actually finding vulns, i.e. by adding inurl:search to then test all search boxes for XSS)
Another good way of determining which kind of technologies are used on the site is by looking for employment positions available – you can look for tech-related positions that are available in the company and generally it will tell you what skills are required (naming specific programming languages and frameworks that are presumably in use), here is a current employment position available with Yahoo that i’m going to use as an example:
From this job advertisement, you can tell that node.js is being used, hadoop server clusters are in use, etc etc. All of this information is purely passive recon available through OSINT. Obviously nothing serious, this one is just for example purposes but i’ve literally seen job advertisements for corporations in the past disclosing the exact MySQL version.
Make sure to spend as much time as possible performing recon, until you have a pretty good feel of how the site operates – there are even occasions where passive recon can lead to having the ability to whitebox, i.e. searching github or pastebin for the company name and stumbling across some random source that ended up online after some sloppy dev wrote it.
It’s also good to use OSINT to harvest emails/usernames associated with the target company, because you could put it together as part of a PoC for something related to auth bypass or bruteforcing (some bounty programmes accept ‘the ability to bruteforce’ as a valid submission – don’t ever try to bruteforce their live systems though)
Another important point is to check if any acquisitions are within scope of the bug bounty, because these are often written in a different manner (since a different dev team would have wrote a bunch of the code before it actually became an acquisition of the company in question) – this means they can be less secure in many instances, and while the payouts are generally lower for acquisitions, the vulns will be easier to identify and there’s also the bonus of still getting HoF. Just check for any recent acquisitions then use the steps detailed above to map it out like you did with the subdomains.
Finding the bugs:
In this section I will explain a few practises that should be followed when looking for bugs in a bug bounty programme (not an explanation of how to find them, but rather an explanation of what to do when finding them)
You’re going to be wanting to go through each section of the notes gathered while performing the recon, and checking off each domain one at a time as you test it for vulnerabilities (also don’t think the likes of XSS and SQLi will suffice, you need to be testing for all manner of vulns, even the uncommon ones – obviously it depends on the context in which you are testing and the technologies which you are testing against)
Avoid scanners. Port scanning, subdomain scanning or any form of scanning related to basic recon is fine. Using commercial vulnerability scanners such as Acunetix isn’t fine. I mean it should be obvious that the company themselves will probably routinely scan their own systems for vulnerabilities which they can patch pre-emptively, but if that isn’t obvious and you decide to use a scanner anyway, you’re going to be dealing with the issue of countless false-positives, any submission you do find is guaranteed to be a duplicate almost, and in addition to that there are many companies that will disqualify you from their programme if they have reason to believe you’re using a vuln scanner (which will be obvious to them in the headers, scanners are noisy). In most cases something like burp suite for mapping all user inputs will be fine and won’t breach any terms of the bounty.
In order to narrow down the kind of vulnerabilities you’re going to be looking for, it’s always a good idea to read up on past reports relating to the company where people have had payouts, look at what bypass methods they’ve used (if any) and just gain an understanding of how exactly they exploited the vuln – if you get lucky maybe the same dev working for the company has made the same mistakes in different scripts on different pages and maybe it hasn’t been patched there. Another good reason for reading up on past reports relating to the company is that you can then look at the patch that was implemented to fix the issue, and see if there are any ways to bypass the patch and recreate the issue in order to get your payout.
Also, it’s best not to just instantly report a vulnerability the moment you find it, as there is a chance that you could possibly pivot into something more serious. For example if you were to find an LFI and reported it as just LFI, you’d get a lower payout than finding the LFI, figuring out how it could be turned into RCE and then making the report. The same thing applies with other vulns such as XXE and SSRF, it’s best to do some testing to see how far you can take the vulnerability before making the report (in order to ensure the max payout) – by this I mean see what the potential of the vulnerability is, not exploit the vulnerability and compromise the server (this will get you disqualified for sure)
You also need to remember to do your testing in a responsible manner (to avoid breaching bounty terms) – For example if you thought you’d found a potential RCE, in order to verify it you should use some harmless command like whoami then check the output to see whether the command was successfully executed (as opposed to doing something like rm -rf /). Also when making your reports there’s no need to disclose potentially sensitive information (even if via private communications to the company), for example it would make a lot more sense to display the output of /etc/hosts as proof of file inclusion as opposed to the output of /etc/shadow.
Another point to remember is that if you see a vulnerability being blocked by a WAF, don’t assume it can’t be exploited – if you manage to bypass the WAF and get a working PoC to exploit the vulnerability then you’ll still get a payout (and probably also a payout or some swag from the WAF company too). Don’t think they’ll just be like “oh yeah that WAF wasn’t coded by us so we’re not paying you” because regardless of whether the WAF is present, the issue remains in the vulnerable code to begin with. The WAF is just an extra layer of protection.
Making the report:
If you find something that is valid, you really need to make your report stand out (but don’t overdo it), you want to explain the risk to the fullest extent, and you want to do so in a clear and concise manner.
Don’t just paste the links to the vulnerability and give an explanation of its risks, but instead show them the risks. For example if you were to find an XSS Vulnerable page then show first the URL alterting document.domain as opposed to a typical PoC of alert(0) to first show them exactly which domain is vulnerable (and to verify that it isn’t sandboxed), then maybe send a second URL below this with a crafted fake login page and explain to them it’s a demonstration of the potential phishing risk posed by the vulnerability.
Some companies appreciate video PoC’s, others (google is an example) tell you to keep your PoC as short as possible if you do make one and suggest that you just explain it via text instead. If you think a video PoC will better convey your report than words will, then go for it. It will probably tell you their personal preferences in their terms, but certain companies would much prefer a video PoC and they would assume it to be a more professional report.
One thing that almost all companies will want to read in a submission is numbered, step-by-step instructions on how exactly to reproduce the vulnerability, this needs to be clear to read and easy to follow.
Also, be thoughtful of the email address you use to make your PoC, it’s best to use your real name instead of your leet hacker handle (lol) – they’ll take your report way more seriously. It should also be noted that if you’ve made previous reports to the company that have been valid, then it’s best to contact them via the same email address if more vulnerabilities are found, most companies running bounties will definitely prioritize the reporters so that those who have consistently made valid reports will be seen to first (this is also especially applicable with crowdsourced bug-bounty sites such as hackerone and bugcrowd)
Ensure that your report isn’t too short or too long, and that spelling and grammar is accurate and it gets to the point, describing in exact detail the severity of the vulnerability and the steps to reproduce.
When you’re waiting on hearing the outcome of your report, make sure not to disclose the vulnerability to anyone and definitely not to post it online anywhere, you’ll instantly lose any chance of receiving a payout. Even if the vulnerability you disclose is out of scope, and you had other valid submissions which were in scope that you didn’t disclose, there’s still the risk of losing the entire payout due to violation of bounty terms.
Bug reporting can be hard. It can be time consuming, and while you can assume time = money, sometimes you can work for months on a submission only to find out it’s a duplicate of something that’s been previously reported. Other times you can make thousands of dollars for 10 minutes work.
Expect to be disappointed often, sometimes you will put in a lot of hard work only to end up with nothing. Other times you will get the easy cash payouts that you’ve been waiting for. You can also expect to hear the word ‘duplicate’. A lot. That being said, it’s a good learning curve, it can be fun, and you can make a lot of money if you get good at it.
If you come from a blackhat background, or even have a background as a pentester who does audits for companies, then you’re going to find bug bounties harder than what you were previously doing. The main reasons for this are due to the limited scope. In order to perform a successful attack against a normal target, you could use a variety of methods (targeting employees, targeting the DNS provider, etc), the limited scope of the bounty programme will prevent you from being able to do this, you will have to look for a vulnerability that is within scope on a domain that is also within scope. That being said, it’s way more rewarding (at least while staying on the right side of the law).
I’ll be doing a series of posts soon which will go in-depth into the actual techniques used while testing for vulns, rather than just the recon aspect of it.
Good luck and happy hunting