Here’s another dose of bug bounty tips from the bug hunting community on Twitter, sharing knowledge for all of us to help us find more vulnerabilities and collect bug bounties.
This is the 5th part and in each part we are publishing 10 or more tips. Here we go..
- 1. Top 25 server-side request forgery (SSRF) parameters
- 2. Sensitive data leakage using .json
- 3. HTTP recon automation with httpx
- 4. Easy wins with Shodan dorks
- 5. How to find authentication bypass vulnerabilities
- 6. Simple ffuf bash one-liner helper
- 7. Find access tokens with ffuf and gau
- 8. GitHub dorks for finding secrets
- 9. Use Google cache to find sensitive data
- 10. Trick to find more IDOR vulnerabilities
- 11. Valid email addresses with evil payloads
- 12. Search for interesting parameters with gf
- 13. XSS payload as an image filename
- 14. How to become a bug hunter
- Conclusion
1. Top 25 server-side request forgery (SSRF) parameters
By @trbughunters
Source: link
Here are the top 25 parameters that could be vulnerable to server-side request forgery (SSRF) vulnerability:
?dest={target}
?redirect={target}
?uri={target}
?path={target}
?continue={target}
?url={target}
?window={target}
?next={target}
?data={target}
?reference={target}
?site={target}
?html={target}
?val={target}
?validate={target}
?domain={target}
?callback={target}
?return={target}
?page={target}
?feed={target}
?host={target}
?port={target}
?to={target}
?out={target}
?view={target}
?dir={target}
Next time you encounter such parameters in an URL, get notice because SSRF is a critical vulnerability that may allow you to:
- Access services on the loopback interface of the remote server
- Scan internal network an potentially interact with internal services
- Read local files on the server using file:// protocol handler
- Move laterally / pivoting into the internal environment
2. Sensitive data leakage using .json
By @SalahHasoneh1
Source: link
Here’s a tip to achieve sensitive data leak using .json extension.
- Request:
GET /ResetPassword HTTP/1.1
{"email":"[email protected]"}
Response:HTTP/1.1 200 OK
Now let’s try this instead:
- Request:
GET /ResetPassword.json HTTP/1.1
{"email":"[email protected]"}
Response:HTTP/1.1 200 OK
{"success":"true","token":"596a96-cc7bf-9108c-d896f-33c44a-edc8a"}
Notice the added .json extension in our request which resulted in obtaining the secret token!
3. HTTP recon automation with httpx
Did you know that you can use httpx tool to request any URL path and see the status code and length and other details on the go, filter, or even perform exact matching on them?
Here’s an example:
cat domains.txt | httpx -path /swagger-api/ -status-code -content-length
Very useful, not only for visual analysis. Get the latest release from here:
4. Easy wins with Shodan dorks
By @manas_hunter
Source: link
Here is a list of 7 awesome SHODAN dorks for easy wins:
- “default password” org:orgName
- “230 login successful” port:21 org:orgName
- vsftpd 2.3.4 port:21 org:orgName
- 230 ‘anonymous@’ login ok org:orgName
- guest login ok org:orgName
- country:EU port 21 -530 +230 org:orgName
- country:IN port:80 title:protected org:orgName
With these dorks we are looking for access credentials and credentials related to FTP, perhaps in a log file exposed online or elsewhere, and also for protected areas such as administrative consoles related to our target organization.
5. How to find authentication bypass vulnerabilities
By @jae_hak99
Source: link
This is an interesting tip that can help you find authentication bypass vulnerabilities:
- Request:
GET /delete?user=test HTTP/1.1
Response:HTTP/1.1 401 Unauthorized
Now let’s try this instead:
- Request:
GET /delete?user=test HTTP/1.1
X-Custom-IP-Authorization: 127.0.0.1
Response:HTTP/1.1 302 Found
This might work in cases when the added custom HTTP header (X-Custom-IP-Authorization) is used by the front end – e.g. when it is used to identify the original IP address of the client connecting to the web server through a load balancer.
By identifying ourselves as 127.0.0.1, we might circumvent the access controls of the web application and perform privileged operations.
6. Simple ffuf bash one-liner helper
By @naglinagli
Source: link
Here’s a useful bash function one-liner made by @naglinagli to sort out all your directory searching needs. Simply add this into your ~/.bashrc:
ffufr() {
ffuf -c -w "/path/to/SecLists/Discovery/Web-Content/$1" -u "$2/FUZZ" -recursion
}
Also make sure you have the latest https://github.com/danielmiessler/SecLists and the correct path in the function above.
Now you can perform recursive directory searching (dirbusting) of your target domain easily like this:
ffufr WORDLISTNAME.txt DOMAIN.com
Use this with any of the wordlist that is in the ‘SecLists/Discovery/Web-Content/’ directory. Here’s an example using the ‘tomcat.txt’ wordlist:
Really handy! Get everything from here:
7. Find access tokens with ffuf and gau
Here’s another useful bug bounty tip involving ffuf and also gau. This can help you find access tokens to various service APIs:
- Gather all links of your target:
cat hosts | sed 's/https\?:\/\///' | gau > urls.txt
- Filter out javascript urls:
cat urls.txt | grep -P "\w+\.js(\?|$)" | sort -u > jsurls.txt
- Use ffuf to get only valid links and send them right into Burp:
ffuf -mc 200 w jsurls.txt:HFUZZ -u HFUZZ -replay-proxy http://127.0.0.1:8080
- Use Scan Check Builder Burp extension, add passive profile to extract “accessToken” or “access_token”.
- In Burp run passive scan on those javascript links.
- Extract found tokens and validate them before reporting.
Bonus: How to validate found access tokens? Use KeyHacks to identify particular API keys, how can they be used and how to check if they are valid.
Protip: Make sure to also try to extract other file types such as .php, .json etc. (Step 2).
Here’s all the things you need for this tip:
8. GitHub dorks for finding secrets
By @impratikdabhi
Source: link
Here’s a list of 10 Github dorks to find secret and access tokens:
- “target.com” send_keys
- “target.com” password
- “target.com” api_key
- “target.com” apikey
- “target.com” jira_password
- “target.com” root_password
- “target.com” access_token
- “target.com” config
- “target.com” client_secret
- “target.com” user auth
With these dorks we can identify all kinds of secrets. As in the previous tip, use KeyHacks to identify and validate found secrets.
9. Use Google cache to find sensitive data
Here’s how @pry0cc was able to find credentials through Google cache for one of his targets:
- Google dorked target site.
- Found open HTTP directory.
- Navigated there – it was patched.
- Viewed Google cache, Error log path was exposed.
- Copied the same path to the / of the site, downloaded 300 MB of web error logs.
- Parsed the error logs, found credentials in plaintext.
Instant win!
This is why it’s crucial to always perform a thorough OSINT analysis. In this case @pry0cc would have never been able to enumerate it nor find it through bruteforcing. It was there, for a split second, and got indexed in google.
10. Trick to find more IDOR vulnerabilities
Here’s a neat trick that could allow you to find more IDOR vulnerabilities.
Let’s say you identified the following endpoint:
/api/getUser
Now do some fuzzing on it (/api/getUser$FUZZ$). Chances are that you will find other endpoints such as these:
/api/getUserV1
/api/getUserV2
/api/getUserBeta
Chances are that these new (old) endpoints are different and potentially vulnerable to IDOR.
In case you are wondering what IDOR vulnerability is – it stands for “Insecure Direct Object Reference” and it allows you to access, edit or delete information belonging to other users.
This is typically achieved by arbitrarily changing (guessing or incrementally increasing) values such as:
- id
- uid
- pid
- name
If the web application doesn’t properly validate the access rights, you may be able to access other users’ data. IDORs are critical vulnerabilities, so it’s definitely worth paying special attention to.
Protip: Use the following wordlist for identifying different endpoint versions (use with ffuf or Burp Intruder):
11. Valid email addresses with evil payloads
One not-so-well-known attack vector when testing web applications with email address fields is to use the comment section of an email address. This is a feature of email addresses defined in RFC822 specification.
This means that we can provide an arbitrary comment as part of an email address and it is still going to be a perfectly valid email address. Here is how it may look:
- “payload”@domain.com
- name@”payload”domain.com
- name(payload)@domain.com
- name@(payload)domain.com
- [email protected](payload)
These are all valid email addresses (you check them in an email address validator, e.g. here). As a payload, we can provide something interesting like SQLi, XSS or even a RCE payload.
Protip: Check this bug bounty tip for some good payload examples.
12. Search for interesting parameters with gf
By @HackersOnDemand
Source: link
Do you have a large list of URLs outputted from another tool?
Use the gf tool (made by @tomnomnom) to search for interesting parameters, potentially vulnerable to open redirects, SSRF etc.
cat url-list.txt | gf redirects
Now we could focus on these URLs and test them in detail for open redirection vulnerabilities.
Note that for this tip you will need additional patterns for gf (made by @1ndianl33t) which you can get from here:
Make sure to copy all those .json files into your ~/.gf/ directory so that gf can find them.
Protip: While you are at it, grab also gf-secrets patterns (made by @dwisiswant0) which can identify various API keys, secrets and access tokens:
13. XSS payload as an image filename
If you find a file upload function for an image, try introducing an image with XSS (Cross-Site Scripting) payload in the filename, like so:
<img src=x onerror=alert('XSS')>.png
"><img src=x onerror=alert('XSS')>.png
"><svg onmouseover=alert(1)>.svg
<<script>alert('xss')<!--a-->a.png
Note that this may only work on UNIX-based systems, because of the special characters not accepted as a filename on Windows. However, as a reflected XSS it should work universally.
14. How to become a bug hunter
By @kenanistaken
Source: link
Here’s a tip how to become a bug hunter and things to keep in mind while doing bug bounties:
- Sleep well
- Learn vulnerability types (owasp)
- Focus on 1 each time
- Read & practice
- Learn how to find and exploit
- Understand how to analyse website
- See how others do (reports)
- Learn 1 programming language
- Make your own scripts
- Don’t rush
Certainly a very prudent advice!
Conclusion
That’s it for this part of the bug bounty tips.
Big thanks to all the authors for sharing their tips:
- @trbughunters
- @SalahHasoneh1
- @pdnuclei
- @manas_hunter
- @jae_hak99
- @naglinagli
- @Haoneses
- @impratikdabhi
- @pry0cc
- @m4ll0k2
- @HackersOnDemand
- @h4x0r_dz
- @kenanistaken
Make sure to follow them on Twitter to stay ahead of the bug bounty game.
SHARE THIS