Beginner Bug Bounty Guide - Part 3

Previous : Beginner Bug Bounty Guide - Part 2

Next : Beginner Bug Bounty Guide — Part 4

Note: These articles are my take (opinion) on “How to start Bug Bounty”, inspired by security community. These details will be updated as an when I learn new insights. These articles are for ethical and educational purposes only

This article mainly focuses on problems and how I approached them. These are my ways of approaching it, please dont accept them blindly, only use them if they make sense to you.

Questions

1. Lots of cookie parameters

“On capturing the http request I found lots of cookie parameters like _ga, _gid, etc…and different urls have different sets of parameters. Do we need to test each of them?”

• For beginners, only focus on those parameters whose names make sense to your. Like if there is a parameter in URL named “path” for “location” or “q” or “query” or “id”, etc (you can get this list of interesting parameters in GitHub repositories). As you progress you will read new bug bounty writeups and bug bounty tips, you will know more.
• Look for what values are stored in them, if a parameter is having a weird name but it has value pointing to a website, then that parameter is interesting. Example, https://website.com/action?weirdrandomname=www.google.com
• In burpsuite, in Proxy History or Logger++, there is a column named “Param”, filter out those request that have only parameter or some kind of input.

2. Lots of pages and subdomain.

“Reading articles and blogs I came to know that the more endpoints/webpages/links you find for a webiste, more are the chances of finding a bug. Seeing these many subdomains and paths in burpsuite sitemap overwhelm me on how to start.”

• One of the goal of bug bounty process is to find as many subdomain and endpoints (pages) as possible. Now the next thing is which pages/subdomains are interesting.
• You can use regex as a string searching criteria to find interesting pages, like /login or /admin or .php pages (these are only a few of them) from this complete list of URL and subdomain. First try to test these interesting pages and then you can test on the remaining ones.
• Create separate lists. Like I create a list of all interesting URL and inputs. Example, URLs that have a inurl parameter which has with value pointing to a website, https://website.com/action?link=www.google.com. or, URLs that have file path inurl parameters, https://website.com/action?path=/images/image1.png
• Then use these list as input to different attacks.

3. I have a list of wordlist but how to check if success or failure

“While learning I have created a wordlist, as I learned I added different payloads in it. But now while testing on a live website, I have this huge payload list, with different techniques of the attack, how can I know if the exploit worked or not.”

• Make DNS out-of-band version of every payload. In this way if XSS is successful you will get a hit on burp collaborator. (But this is not a proper approach)

4. Am I wasting time, is it correct?

“Am I wasting time trying attack (like XSS) on every single page where there is a parameter either in URL or in body -> sending it to repeater/intruder -> trying all the wordlist? It seems it will take forever to complete all attacks. While learning, it was very obvious to find the vulnerability, as we got some hints.”

• We need to identify which attacks are automation friendly.
• Does automation will cover all test cases? No, but there are some attacks that you can automated. I have written an article on my opinion on it.
• Irrespective of whether the tool is a burpsuite plugin or a open source tool in Linux, understand the tool working, see what input it takes and what output it gives. Is the tool is aligned with your thinking process or approach. Can you customize the tool at a very enough granularity that makes the tool work as you like it to work. Example take a custom wordlist, check additional string in the response, etc…

Example, a tool called amass which is a tool used to identify subdomains, has a github page where it specifies which tools it uses to obtain the results.

• Use intruder if you want to test manually a list of payloads. Always customize your payload list and personalize it based on the current technology that your are testing on.

5. Lots of information, how to organize them.

“The amount of information that I need to know is overwhelming, how to organize these information so that I dont have to remember anything while actual testing?”

• Note taking tool : Obsidian, how to write obsidian notes - InsiderPHD- Youtube 1, InsiderPHD - Youtube 2 . I use a different approach, obsidian note taking. I create obsidian URI links using Advance URI plugin to create a browser friendly URL, which on visiting directly land to the given heading on the given page. I use this URL to link it to my mindmap and any other local notes. Like address can be access using the “open” command in linux. In the below example %20 is used insted of “ ” space. If file names has special character, you need to encode them in URL encoding, else use & symbol to separate variables.

obsidian://advanced-uri?vault=VAULTNAME&filename=NAME_OF_YOUR_NOTE_NOT_THE_PATH&heading=ANCHOR_OR_HEADING_AFTER_#
obsidian://advanced-uri?vault=BBKB&filename=Personal%20XSS%20Cheatsheet&heading=URL%20Based%20XSS

• Taking Notes during testing: The aim is to organize the testing, create checklists. Mark testing that is already done. For all this, there is a tool called SwiftnessX. This is not a necessary tool you need to know, it is for those you want all things organized.
• Mindmap & Mindmap Linking to other mindmap. I create different mind map for different purpose and link different mindmap and obsidian notes to prevent redundant information. I use a paid Mindmap tool called Edrawmind. My majority time we be spent on mindmap, so I wanted a powerful tool, note that the problem of using a powerful tools is that it has its own mindmap extension and format, which is not compatible to other tools. My current problem is solved via this tool and I am comfortable with it hence I use it. In free version you will get stuck later, as it has limit on number of topics you can include in one mindmap. You can find ways to get the pro version, if you know what I mean.
• Regarding Test cases: First thing you should do is to remove redundant testing. And automate the process and much as possible. With experience and repeated testing you will learn all testing cases.

6. Am I checking test cases that are already covered by tools?

• If you think the test case is very useful and important such that covers a lot of XSS surface, then it is always a good idea to do it manually, irrespective of it is done already or not. This will come under the first thing you do after the automation scans are finished.
• Make sure this list is not filled with junk data, as most of the test cases could be done done by open source tools and burpsuite.

7. Does reflected input behavior enough to detect all XSS vulnerabilities?

No. Some DOM bases XSS will not have input reflection, we need to send carefully designed payload in this case to trigger XSS. There could be other use cases also which I may miss.

8. Why people who do bug bounty are called “Security Researcher”?

Bug Bounty requires you to find bugs that were not known in the complete application development, testing and auditing phase. This is basically an art and it requires passion, patience and good problem solving skills to find complex attack chaining which were earlier considered as less severe. The attack logic may not work in other application environment, that is why there are less security researcher as compared to bug bounty programs.

9. What don’t people in security community make their Methodology, Mindmaps and notes public?

“Just share your notes, mindmaps and methodology publicly. It will save lots of time.”

• To push beginner to approach bug bounty according to their though process. Different people have different way of approaching the same problem. You should always use your way of doing the action, instead of blindly copying another. You can take inspiration and ideas from reading other’s methodology, use that knowledge to improve your approach to achieve the same results.
• To push for creativity, instead of blocking your though process. Reading somebody else’s detailed approach will mold your thought process. You should always do things that makes sense to you and the way that your are comfortable with such that it gives the intended outcome.
• The ultimate goal is to find bug, to cover all test cases. The ultimate goal is not to copy exactly other researcher’s methodology or their way of approaching bug bounty. If you are not able to find bug now, just have faith, keep on improving your approach, organize data, use automation, etc, no matter how much time it takes.
• People generally create new tools instead of sharing their notes and test cases.
• People who share their methodology in videos or blogs, their intent is to give you a way to identify bugs and so that you get an inspiration and ideas. After reading their approach, process it, and then create your own methodology on how you will achieve the same result. You should have your own insights so that it is aligned to your thought process.

10. Is it necessary to know all headers before attack? What if I directly work on HTTP parameter and HTTP POST body irrespective of header ( ignoring values in HTTP Headers ) , what will I approach miss any check or test cases?

• =pending=

11. Why do people talk so much about recon and very less about testing?

• Recon methodology helps you to identify as many assets that belong to target.
• Lets say you have found a webpage or subdomain that you think was not discovered earlier. What to do next? First run automated vulnerability scanner/auditor tool to find any low hanging fruits, as this could not have been discovered earlier. Next analyze what webpage or subdomain is and what information does it contain, is any sensitive information present like PII and user related information. What ports are open on that server. Perform a server vulnerability scan. All this you can do for all webpages and subdomains.
• Out of all you could get few endpoints subdomain which looks interesting to your and you can try different test cases on them.
• This is why recon methodology is very important to earn quick bounty.

Below are few points to do proper recon:

• find bigger attack surface.
• development environment, UAT environment, staging environment, QA environment are relatively less secure.
• useful documentation, API documentation (like simply search the complete document for command, os, run, execute, etc keywords).
• Sensitive data exposure (by mistake by a developer like backup files, personal read me file, passwords file, secret keys etc…)

Regarding Testing and Detection in the wild

Detailed discussion about approach for testing and improving it is discussed in the next part of this series. Beginner Bug Bounty Guide — Part 4

Ideas and Tips

1. Make use of PayloadAllTheThings - Github, this helped me a lot. For example, it has a good details on finding SSRF Vulnerabilities. swisskyrepo keeps the repository fairly up to date, either you can fork it to customize it or simply check every few months for changes.
2. Focus on only “in url” parameters first and then gradually go to to different types of input, like “POST body parameters”, etc. Like then you need to cover all attack surfaces.
3. Master 1 attack type at a time. Example, for beginner start with XSS, then do IDOR, and so on. While learning you create notes, wordlists, etc. It is very important to test different exploit separately, dont mix wordlists or testing approach. While testing also test vulnerability type one by one, like complete all XSS, then start for SSTI, and so on. Yes, it will take days to complete, but slowly you will first get complete understanding of your approach, and then you can automate your approach.
4. Keep your personally built payload, these will include, bug bounty tips from twitter and other sources, from case studies, you used it while learning. Only include if you think it will not be present in other wordlists. NOW, when you do the testing, create a new wordlist and merge your personal wordlists with whichever good wordlist you find in GitHub or other sources, now the wordlists size will be huge.
5. You should know that you are a beginner, you will not be knowing all the things. So only focus whatever you know, and make sure you test all cases whatever you know. Example, while learning you created your own xss payload list, then test it out on parameters for xss.