Beginner Bug Bounty Guide - Part 5

Previous : Beginner Bug Bounty Guide - Part 4

Next : Beginner Bug Bounty Guide — Part 6

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 things that you should know before deciding your final testing approach using either burpsuite other open source tools.

Some details

1. Manual Testing - In my articles I will use the term “manual” to refer tasks like testing without any tools (burpsuite audit scan/plugins or open source tools which do end to end scanning). Like using Burp repeater on a webpage, and trying one by one payload manually. Custom developed tools build according to you also come in this category, as it basically automated repeated tasks. Open source tools which require significant manual efforts, example, directory enumeration will only gives us list of all URL and directories it does not tell which URL are vulnerable or not directly. We use this data and process it, then try to check all test cases on these URLs. This is considered in manual testing.
2. Automation - This includes both Burpsuite audit scan/plugins that automate vulnerability testing and open source tools which do end to end testing. The need for this differentiation is that, almost all hunters use automated tools, you may get bugs if the bug bounty program is new, or if you are the first one who discover the new webpage as a result of your improved wordlists. In here, Open source tools which require less efforts.

My thought on automated scanning

Master 1 attack type at a time. Example, in your first bug bounty program only focus to XSS, test all XSS test cases, find all open source tools for XSS, and make your XSS approach solid. Then in the next bug bounty program you can focus on 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 gradually start automating your approach.

Almost all security researcher do the exact same “automated vulnerability scanning” on the exact same assets, so it makes no sense to depend on (end-to-end) automated scans and open source tools to find new bugs. You should invest less than 20% of time doing automated scans. Most of your time should be focus on finding and identify a “Vulnerable Behavior”, “Trying different test cases which are customized after understand the application and its behavior” and “Attack chaining” and other attacks that cannot be automated.

Well known tool for automation, generally, are build using lots of other open source tools and also have different sources to collect information from. So if you use a open source tool, developed by some other security researcher, it is the result of his/her methodology of automation. Hence we should always see how the open source tools work and fetches and processes data. If the tool is not not aligned with your thinking approach or does not fetches all the input sources, then fork the tool and do the modifications to the tool to personalize it according to your though process and use it in your methodology. It makes little sense to, right-away, spend huge amount of time to designing a tool from scratch. You should always design a tool form scratch if there is no open source tool or the tool is not properly written.

Automation is the best way for :

There are list of attack that should be automated. It also includes attacks that sometime just needs additions in the source code to incorporate new attack payloads and techniques, for tools that are not updated. You can edit the source code of the open source tools or burpsuite extender plugin source code. In these vectors automated end to end scanning is enough. In all these there are always few test case (<10%) are not covered, so we may have to manually review and test if required.

• HTTP Request Smuggling (Attack)
• Input Reflection (Vulnerable Behavior)
• Out-of-Band / DNS : External Service Interaction (Vulnerable Behavior) : We can only find low hanging fruits in this case, but the automation is enough to cover significant test cases. Example, using “Collaborator Everywhere”.
• Open Redirection (Attack)
• Host Header Injection (Attack)
• Directory traversal (Attack)
• File Path - Basic (Attack) : a.k.a Directory traversal. LFI, RFI are similar attack but in network PT. I classify File Path attacks in two types “Basic”, “Personalized”. In basic we tend to use already known payload strings can be used to check file path vulnerabilities.

Automation is good not enough for :

These are attacks which either have automated tools / plugins but are not enough as these require manual insights or these tools / plugins do not cover all test cases. These could make use of burpsuite intruder wherever required.

• XSS (Attack) : You may seem automated tools can test all test cases, but it is not common to get a confirmed XSS, given we have input reflection, we have to bypass restrictions manually after understanding the application behavior in many cases. Input reflection does not cover all test cases of XSS. There are number of tools to test XSS, but to get bugs we need to design customized test cases, find hidden parameters, analyze unusual behavior, etc.
• IDOR/BOLA (Attack) : You may seem automated tools can test all test cases, but these are just first step, it is not end-to-end. The automated tools does not cover all actual attack surface, as you need to have a good understanding of the application.
• SSTI (Attack) : Automation does not cover all test cases, we need to manually analyze, which this category is present here and not in the below section, because, the detection can be automated and there are good test cases in the automated current scanning tools. But after detection, we need to confirm SSTI attack, which is a completely manual exercise, it requires knowledge of the complete documentation and may require some research.
• CORS (Attack) : Automation is useful but not enough.
• XXEi (Attack) : Automation is useful but not enough.
• CSRF (Attack) : Automation is useful but not enough. Generally, these are less impact bugs but depends on what is the feature.

Not possible to automate “end-to-end” for :

Don’t go with the literal meaning of “Not possible”, we can automate whatever we which, but if the behavior is not repeating, or, if the attack is dependent on variable names that one cannot predict, as these are custom developer defined names and not standard, then these automation in some cases are useless. Hence the work “not possible” if it work each and every time. These attack may use open source tools but, not an end-to-end automated tools. These could make use of burpsuite intruder wherever required.

• Authorization (Attack) or Privilege Escalation or Access Control
• Logic Flaws or Business Logic Vulnerabilities or Custom Functional Testing.
• Web Cache Poisoning : Yes there are tools but they are limited and not enough. This attack requires manual insights for which you require to understand the complete documentation of the underlying framework, library, hosting platform, infrastructure, analyzing unusual behavior and other research.
• Web Socket (Attack)
• URL Parser Inconsistencies (Vulnerable Behavior)
• File Path - Personalized (Attack) : These uses carefully crafted, the current program specific strings, which include valid path, etc. These require understanding of the application working or being creative.
• File Upload (Attack)
• Insecure Deserialization (Attack) : Yes there are tools that detect Insecure Deserialization but the attack requires manual insights. Automation not enough.
• OAuth (Attack) : Complex attacks.
• SSRF (Attack) : Definitely automated tools does not cover all test cases. The detection mechanism is not powerful enough to detect and confirm that it is SSRF, due to environment factors and restriction and controls specific to that deployed environment. But open source tools and plugins can be used or the attack can be run by combining different tools. Solely relying on manual approach without using any tools is not the best approach.

The previous part (part 4) of this series discusses on how you can improve your testing methodology, it is more focused on manual testing methodology. Beginner Bug Bounty Guide — Part 4

Integrating Burpsuite with other Open Source tools

Burpsuite provides a good interface for testing web related information and storing the request and response in a more user friendly way. We can always write a script to send output from one tool to input to another tool, but the same does not seems when burpsuite is one of those tool. The intention is to have seamless integration between burpsuite and other open source tools. This is enable us to come out of the burpsuite and its plugin world, and give us freedom to include other open source tools in the testing methodology of burpsuite. The ultimate goal is to set up automation and freedom to include any open source tool in burpsuite testing workflow.

Plugins to integrate with few open source tools

Custom Burpsuite Extensions

• Write custom burpsuite extensions using Burpsuite Extender APIs. Write a basic extension just to be familiar with how you can do automation inside burpsuite. Complete Youtube Video on how to build a burpsuite extension. Hello World of Burpsuite Extender APIs.

Whats Next?

• Find good sources on which are the list of open source tools used by security community. Example, Web Application Pentesting Tools — 2022
• Check all tomnomnom custom tools to have and idea of automation. These are well written and very useful tools.