Mastering the Skills of Bug Bounty
Your syllabus for going from newbie to top hacker
Bug bounties are a great way to gain experience in cybersecurity and earn some extra bucks. I’m a huge proponent for participating in bug bounties as your way into the cybersecurity industry.
After publishing “How to Get into Bug Bounties”, people have been asking about the next step: How exactly do I find that first bug? What are some skills that I need to do that?
Today, let’s dive into the skills you need to succeed at bug bounties, and what you need to learn to start your hacker career!
Choose your track
Are you a mobile hacker or a web hacker? There are other kinds of bug bounty programs, but mobile and web hacking skills would be the most useful for most bug bounty programs.
Learning about web hacking is probably the easiest way to get started in bug bounties.
The majority of bug bounty programs on platforms are web programs. And most companies that host bug bounty programs have some sort of website that they want to be tested.
That’s why learning about web hacking will be the quickest way to start hacking and will provide a pretty good ROI for your time.
Mobile hacking, on the other hand, has a few more prerequisites and takes more time to get started.
But because of the higher barrier of entry, mobile programs tend to be less crowded and better paying. And although mobile programs are not as common as web programs, they are on the rise, since more and more companies are launching complex mobile products!
First, here are some skills that you need regardless of whether you choose to go the web route or the mobile route.
Learn to use a proxy
One of the most important skills that you’ll need to learn before you start hacking is to learn to use a proxy. A proxy is a server application that acts as an intermediary between your browser and the target application’s server.
Using a proxy is essential because proxies allow you to:
- Perform recon by examining and analyzing the traffic going to and from the server,
- Examine interesting requests to look for potential vulnerabilities, and
- Exploit vulnerabilities by tampering with requests.
There are three proxies that are particularly popular with bug bounty hunters: Burp Suite, Zed Attack Proxy (ZAP), and Tamper Data. Burp Suite is the most feature-rich while ZAP is Burp’s free alternative. Tamper data is a browser add-on that only allows the editing of HTTP headers and POST request parameters.
The details of how to use each proxy can be found on their websites. Keep in mind that you will have to follow instructions to configure your browser to work with the proxy before you can intercept any traffic.
The basics of web technologies
It is also essential to understand how web technologies work. Here are some concepts to read up on:
- The HTTP protocol, HTTP status codes and headers,
- the basics of network security,
- different encoding mechanisms, like hex, base64, and ASCII,
- the basics of cryptography,
- the Same-Origin Policy (SOP) and Cross-Origin Resource Sharing.
Reading up on these concepts will give you a big-picture understanding of how the Internet works, and how it is secured. This will give you a solid foundation to build on.
Session management issues
It is also important to learn about how modern web applications approach session management. For example, what are the different ways of identifying a user? What are cookies and how do they work? What are authentication headers? And how are session IDs issued, reused and destroyed?
Learning about Web Hacking
Now that you have a solid understanding of web technologies and how they work, it’s time to study up on common vulnerability types and how to find them!
Cross-Site Scripting (XSS)
XSS is the most common and easiest to find bug class. There are three main kinds of XSS: stored XSS, reflected XSS and DOM XSS.
Although new XSS vectors are often discovered manually, a good way to test a site for already known XSS vectors is through fuzzing:
Open redirects are often dismissed as trivial bugs, but they serve as a part of many bug chains to achieve a larger impact.
Open redirects happen when an HTTP parameter or URL parameter can contain a URL value and could cause the web application to redirect the request to the specified URL.
On their own, open redirects lead to phishing. But they can also be used as a way to bypass URL blacklists and whitelists. This means that open redirects can often be used to escalate an SSRF or to smuggle session tokens off-site.
Insecure Direct Object References (IDOR)
IDORs are another type of bug that is present in almost every web application.
IDORs happen when access control is not properly implemented, and when the references to data objects (like a file or a database entry) are predictable. They often lead to very critical vulnerabilities due to its potential for leaking sensitive data.
Learn more about how to find IDORs here:
Cross-Site Request Forgery (CSRF)
CSRF, or Cross-Site Request Forgery, is a technique that allows hackers to carry out unwanted actions on a victim’s behalf. Sites allow CSRFs to happen when they don’t implement random CSRF tokens for every state-changing request.
The impact of CSRF greatly depends on the action that the request causes. Sometimes, CSRFs lead to critical vulnerabilities and even account takeover. Othertimes, CSRFs are trivial vulnerabilities that are not worth reporting. So as with reporting any other vulnerability, always consider the business impact of the bug before you draft up your report!
Learn more about CSRFs in these posts:
Attacking Sites Using CSRF
From CSRF to user information leak, XSS and full account takeover.
Server-Side Request Forgery (SSRF)
SSRF is a vulnerability that happens when an attacker is able to send requests on behalf of a server. It allows attackers to “forge” the request signatures of the vulnerable server, therefore assuming a privileged position on a network, bypassing firewall controls and gaining access to internal services.
SSRFs can also vary in impact. But it can have a lot of potential if you know how to chain it, and how to escalate it! Minor SSRFs lead to info leaks and internal network scanning. But when combined with other bugs, like improper access control and open redirects, SSRF can lead to the leak of confidential data, and even code execution on reachable machines!
Learn more about SSRFs here:
A SQL injection is an attack in which malicious SQL commands are inserted into a SQL statement that is executed. This happens when user input is incorrectly filtered and escaped. They can lead to sensitive data leak and command execution.
SQL injections are not that common anymore since most web frameworks now have built-in mechanisms that protect against them. But if you can find one, they tend to be very critical vulnerabilities that result in high payouts.
Insecure deserialization is a type of vulnerability that arises when an attacker is able to manipulate the serialized object and cause unintended consequences in the program’s flow. This can cause DoS, authentication bypass or even RCE.
Deserialization issues are becoming more common in applications as web apps become more complex. Learn more about how and where to find them here:
Deserialization Bugs in the Wild
A totally unscientific analysis of deserialization vulns found in the wild
Clickjacking, also called UI redressing, is an attack that tricks a user into clicking on something different from what the user perceives. It is achieved by hiding the victim application under the guise of another page, using HTML page overlay techniques. It is used to bypass CSRF protection.
Learn more about clickjacking on Filedescriptor’s blog here:
Buttons are everywhere. Elevator buttons, machinery buttons, and even "Nuclear Button" that sits on the President's…
Remote Code Execution (RCE)
Remote code execution is when an attacker is able to execute arbitrary code on a target machine. There is no single technique to achieve this, but usually, it is done by exploiting vulnerabilities such as insecure file upload, remote file inclusion, server-side template injection (SSTI), or unsafe deserialization.
Developing exploits that lead to RCE often requires a deeper technical understanding of an application. So this is something to work towards once you get a hang of finding the simpler vulnerabilities.
Be careful when creating a proof of concept for RCEs, as it is easy to step over the bounds of the bounty policies, and cause unintended damages to the targetted site. Often, reading a non-sensitive file, or creating your own file under a random path is enough to prove your findings!
A race condition attack, or a Time of Check/Time of Use attack, happens when a server is forced to execute commands that are supposed to be executed in sequence simultaneously.
This attack takes advantage of the fact that security checks need to be executed before the sensitive action is executed in order for them to be effective. For example, let’s say you want to withdraw $2000 dollars from your bank account, but you only have $1000 dollars saved. Normally, the bank would not let you withdraw funds you don’t have. But if you can make the bank give you money before checking if you have sufficient funds, you can withdraw money that you don’t have.
Race conditions impact financial sites, trading sites, and e-commerce sites the most.
Broken Access Control
Other broken access control issues that are common in web apps are also something that you should learn about. For example, how do attackers tamper with cookies? What are the most common places in which info leaks occur? And what are the URLs and paths that often lead to hidden developer panels?
The more you understand about the architecture and development process of web applications, the better you will be at spotting these vulnerabilities.
Learning about Mobile Hacking
Hacking mobile applications is very similar to hacking web applications. But there are additional skills you need to learn before hacking mobile applications.
Using a proxy
First, you’ll need to figure out how to set up your mobile device to work with a proxy. This generally involves installing the proxy’s certificate on your device as well as adjusting your proxy’s settings.
For example, if you are using Burp and an Android phone, you can follow these two guides:
Configuring an Android Device to Work Wi...
To test web applications using an Android device you need to configure your Burp Proxy listener to accept connections…
Installing Burp's CA Certificate in...
Note: Android Nougat no longer trusts user or admin supplied CA certificates. We recommend that you use an older…
It is often also necessary to bypass certificate pinning in order to intercept the traffic of better-protected apps. If you have successfully set up your mobile device to work with a proxy but still cannot see the traffic of your target application, it is possible that that app has implemented certificate pinning.
Certificate pinning, also known as SSL pinning or cert pinning, limits the application to only trust a pre-defined certificate. It is used as an additional layer of security against Man-in-the-Middle (MITM) attacks. If you want to intercept and decode the traffic of an application that uses cert pinning, you’d have to bypass the cert pinning first.
The process of bypassing cert pinning would depend on the device that you are using. For Android applications, there are three main ways to achieve that:
- Use a Frida Hook,
- Overwrite the packaged certificate with your custom certificate,
- Change or disable the application’s certificate validation code.
For more details on these methods, please do some Googling!
Mobile applications are an excellent place to search for additional web vulnerabilities that are not present in its web application equivalent. This is because mobile apps often make use of unique API endpoints that may not be as well tested as web API endpoints. Search for IDORs, SQL injections, file upload vulnerabilities, and other common web vulnerabilities.
A good way of finding these vulnerabilities is to use Burp Suite to intercept the traffic coming out of the mobile app during sensitive actions.
In addition to common web vulnerabilities, there are also a few classes of bugs that are specific to mobile applications that you would need to know about.
Mobile applications may contain hardcoded secrets or API keys for the application to access certain web services.
Insecure data storage
Some applications will store sensitive data insecurely within the application’s source code. Look for things like session data, financial information, and personal information.
In mobile apps, sessions are often managed with a session token sent via a header. So an open redirect to a foreign server might lead to account takeover.
The same issues that plague session management in web apps, such as insufficient session expiration and reusing session tokens could also be an issue in mobile apps.
Some applications use custom implementations for encryption or hashing. Look for insecure algorithms, weak implementation of known algorithms and hardcoded encryption keys.
For more details on how to look for these vulnerabilities in Android applications, read my post here:
Generally Useful Skills
And here are some skills that are not necessary for beginners, but will be extremely useful in the long run.
One of the most powerful skills in bug bounty is recon skills: your ability to find new assets and attack surfaces. Good recon skills will put you ahead of the competition and help you find bugs before others.
Learning to script and automate tasks can also be very helpful. There are a lot of repetitive tasks that you have to do in bug bounties that can very easily be automized. By learning a programming language, such as Python or Shell Scripting, you can automate these tasks and save a lot of time.
Never Stop Learning
Finally, after you’ve mastered the basics, remember to never stop learning! New classes of vulnerabilities are constantly being discovered, and staying on top of the newest techniques will ensure that you are constantly finding new bugs.
For example, the ImageTragick vulnerability was discovered back in 2016. ImageTragick is a high impact vulnerability that could lead to RCE. A few months to years after its discovery, bug bounty hunters were constantly discovering vulnerable instances in the wild. (And making bank reporting it to companies!) So as a hacker, it definitely pays off to keep an eye out for the latest security news!
To learn more about different security topics, read some of my blog posts:
A note on Dupes and Informatives
It’s very normal to get a ton of duplicates and informatives when you first start out. So don’t get discouraged by them!
Remember that dupes and informatives mean one thing: that you were technically correct! It’s just that someone has found the bug before you, or that the company is accepting the risk at this time.
They by no means dismiss the quality of your work. Even if you don’t earn money or reputation, you still gained experience from the learning opportunity.
Just keep going and you will develop your own unique methodology and start finding unique, valuable bugs!
Lastly, a few words of Experience
It’s difficult. It really is. When I first started hunting for bugs, I would go weeks or even months without finding a bug. And when I do find a bug, it would be something trivial and low severity.
The key to getting better at finding vulnerabilities is practice. If you are willing to put in the time and effort, your bug hunting skills will improve and you will soon see yourself on leaderboards and private invite lists!
If you ever get frustrated during this process, remember that everything will get easier after you find your first bug. Good luck. And reach out to the community if you need any help.
Thanks for reading. Is there anything I missed? Feel free to let me know on Twitter: https://twitter.com/vickieli7.