I used to do web application security. I did bug bounties, which were a lot of fun and challenging as hell. I also earned my bachelor’s degree in information systems and technologies. I’d say I’ve developed some understanding of cyber security, even though it is still a drop in the ocean. But that is only the supply side of the equation. My technical background gives me the ability to build, but it doesn’t teach me how to make people want what I build.
I want to start my own company in the future. For that, I need to work on both sides of the equation.
That’s why I’m now focusing on understanding the demand side. Marketing teaches how people make decisions, what they pay attention to, and what makes them act. Changing my focus from hacking to marketing is a difficult choice because I am leaving years of experience, better pay, and a more advanced career on the table and starting from scratch in a seemingly unrelated field. However, to go after my goals, I need to understand both.
Hacking, in a technical sense, is mainly just experimentation. Run a payload, analyze the response, think of new ways, and do it again and again. That is what eventually makes a cyber security analyst a hacker. Running so many experiments on countless scenarios builds this hacker mindset. After a while, you become able to find vulnerabilities even without sitting in front of a computer, because it is a mindset.
Hacking, in its broader sense, means breaking patterns and finding unusual ways of doing things. I’m not speaking of finding new exploitation methods or attack vectors. I’m speaking of something that applies to everything, everywhere. That mindset of finding unusual approaches is what I believe will transfer to marketing. In other words, my technical skills help me build, that’s the supply. And the hacker mindset itself might help me generate demand too. In this sense, testing new messaging and testing new payloads are the same thing. Finding new ways to reach people and mapping an attack surface also follow the same logic. Both are about experimenting creatively until you find what works.
I won’t pretend that marketing excites me the way cyber security does. Not a chance. But I’ve realized that building something nobody wants is worse than not building at all. I’ve seen brilliant technical projects die because nobody knew they existed or understood their value. Lacking these skills means leaving what I build to the void. In an age of so much information and such short attention spans, nobody will spend hours understanding what I offer, how it benefits them, and why they should pay for it. So it’s become a necessary skill for the goals I’m chasing.
Despite the title, I don’t see this as a “from… to…” or as a change in my path. It is more like creating another lane in my path, so that I can move more freely and faster in the future. And if I fail, it is not the end of the world. I would still have worked on my hacker mindset, just in a different domain.
That is a calculated risk I’m taking with my career. Let’s see how it plays out.
]]>The main goal of a bug bounty program is to find skilled hunters to assess their applications, systems, and other types of digital assets. Both to reach their goal and due to their different resources, programs set different policies. Whereas some programs get the hunters’ like with their good policies, some fail and have to end their programs. Here are some key points for becoming a more successful program from a hunter’s perspective:
It is not a surprise for rewards to be the most eye-catching thing in an ecosystem, which includes bounty in its name. According to HackerOne and Bugcrowd’s annual hacker reports, financial gain is one of the hunters’ motivations. Bug bounty programs should set their reward policies consequently.
Unique Rewards
Sometimes, regular cash prizes may not be as attractive as the unique rewards. Such rewards as t-shirts, coins, and the company’s own goods may be more interesting for hunters and cost-effective for the programs. Here is a recent example: Red Bull received more than 5500 submissions on Intigriti in return for trays of Red Bulls. The more unique rewards a program offers, the more interest the hunters have (usually)!
Payments
It is worth recalling that bounty hunting is a freelance job. Most hunters do bug bounties for a living and to pay their bills. Due to the nature of the freelance jobs, their income is inconsistent, and sometimes that inconsistency becomes a problem for the hunters. To not put them in difficult situations and not waste time dealing with the “Where is my bounty, sir?” messages, the programs should pay when the bug is triaged, which is called “Pay at triage”.
Programs should determine an initial bounty to apply that policy, usually three digits or a fixed percentage of the estimated amount. When the report is triaged, the initial payment should be sent. After the mitigation steps are taken, and the report is resolved, the remaining bounty should be sent to the hunter.
Promotions
An excellent way to get the hunters’ attraction in a short period is to run a promotion with increasing rewards. This policy helps programs to receive better and targeted reports. Some programs run promotions on specific types of vulnerabilities to test their recently updated assets, new releases, and recent zero-days. Yahoo’s promotion on the recent Log4j vulnerabilities is an ideal example of running specific promotions.
When it is not beneficial to run promotions on specific vulnerabilities, running a general promotion may be a better option. Meta’s Hacker Plus Programme is an excellent example of general promotions: The more a hunter contributes to the program, the more benefits the hunter receives!
Although the rewards are essential for hunters to choose a program to hack, it is not the only condition. Ineffective communication between the programs and the hunters usually causes unwanted results. Therefore, programs should be straightforward in communication and easy to collaborate with. The below key points may help the programs be the favorite of the hunters, even if their rewards are not the best in the market.
Clarification of the decisions & Clear Policy
Imagine a hunter finds a P1 severity vulnerability and reports it immediately with the dream of the bounty in mind. While the hunter is waiting for at least five digits from the program, they decrease the severity to P4 and offer $250 for some uncertain or unacceptable reasons. After some arguments and counterarguments, both parties will be unhappy with the result. Such situations occur primarily because of the programs’ unclear policies and decisions and some hunters’ unprofessional behaviors. Although both parties may be faulty, this blog post is for only the programs, so their role in the issue is examined.
A program’s policy must include “Dos and Don’ts” very clearly. The policy should also include the reward criteria and clarification of the report’s decisions. A clear policy helps both parties to share their objections and reasons for the report. Shopify’s bounty calculator is an excellent example of this topic. Shopify lets the hunter know the rationale behind the bounty and clarifies every criterion that played a role in the decision.
Another important field to be careful in the policy is the rules to follow in the hacking process. Suppose a program aims to test only the specific part of their assets or wants to have the hunters follow some restrictions such as VPN usage, some limitations on testing, and the post-exploitation period. In that case, the policy should be set accordingly. As hunters usually do not read the whole policy, putting the important notes under the rewards table may be a good option. Yahoo’s program is an excellent example of having a clear policy.
Public disclosures
Disclosing reports is a good way to interact with the global hacking community, as it takes place in the hunters’ feed. Publicly disclosed reports help the inexperienced hunters gain knowledge from a successful hack. Concurrently, they are also beneficial as they create an opportunity for already known contributors to collaborate with the other hunters. HackerOne’s own program is an ideal example as they have a company value named Default to disclosure!.
Responsiveness
Bugcrowd’s latest hacker report shows that a responsive team is the most important thing that makes a program attractive. Therefore, the programs should be patient and responsive even though they receive many unnecessary messages about the status of the bounty or the report.
Bug bounty programs may pay at triage to decrease the number of unnecessary messages and therefore save time and focus on the more critical reports. Another method for saving time is to use the platforms’ triage services. It is especially beneficial for big security teams, as they receive many inapplicable reports.
Treatment
Bug hunting is not easy since the hunters compete with the other hunters, black-hat hackers, and the internal security teams. When they find some vulnerabilities after that competition, they contribute to companies’ security in a unique way as they see what is overlooked. Due to the importance of the bug hunters’ contribution, the bug bounty programs should treat the hunters with respect. Public testimonials, job offers, and invitations to the company events are some ways to show the value of the hunter.
This blog post series aims to have a better bug bounty ecosystem. The bug bounty programs are playing a critical role in that ecosystem. The points mentioned above may help programs have a more successful experience. Even if some topics may not suit every program, I believe the programs will see the benefits of applying most of them!
]]>There are many successful bug hunters on the bug bounty platforms and most beginners want to achieve that level of success however settle for low impact findings as they aim to find vulnerabilities using certain methods. For most beginners, a better approach would be to analyze what the top bug hunters find and how to build on top of the know-how and the methods used by bug hunters of more experience. This is why I decided to make a simple analysis with the public “2019 Year in Reviews” and “2020 Year in Reviews” then, I interpreted the results. The analysis is based on the top 1000 hackers who have public reviews (2019) and the top 100 hackers who have public reviews (2020). The results are not the data of all users of the bug bounty platforms.
The most reported vulnerabilities:
Cross-Site Scripting also known as XSS, is a vulnerability that allows an attacker to inject HTML and JavaScript code when the user input is not sanitized. It is the most popular and number one most reported bug on the bug bounty platforms. Because it is easy to find, bypass, and exploit. Most of the top bug hunters have custom scanners to find XSS vulnerabilities. If you prefer to find XSS manually, the optimal way to doing that is by looking at the source code.
While everyone has their own way of bounty hunting, I have a few suggestions that I would like to share. Making a difference between other researchers and scanners is simple, work to improve the impact of XSS. After, write a working exploit. For example, if there is a CSRF-token in the response, select the tag which includes the token. Then, write an exploit that submits a password change request with the collected CSRF token. If you are good with JavaScript, you can increase the severity from P3 to P2 and even to P1.
Information Disclosure is a collection of non-expected (in some cases, expected) behavior while securing sensitive data. There is a lot of types of Information Disclosure issues. Generally, if you see data that you are not supposed to be, there is an information disclosure (leakage, exposure) vulnerability. For example, while fuzzing the directories, you may find a file that includes confidential data. Or, while you are visiting a friend’s profile, you may retrieve their PII (Personally Identifiable Information) in the response. You can automate all the unauthenticated services to find information disclosures. Remember, the most critical information disclosures are often discovered by understanding the application logic.
Privilege Escalation is a weakness that permits attackers to perform an action that they are not authorized to. It occurs in the applications’ workflow. For example, a user may ban the admin from the project, and the system assigns the user as a new admin. In this case, the user could escalate their privileges with the business logic error in the flow. The scanners cannot find the issue with the default settings. Thus, the privilege escalations need a hacker mindset to find. Most of the top bug hunters read the freaking manual before testing, especially necessary for API security testing. Reading documentation is a very effective (and boring) way of understanding how the application works. With this method, you may able to find privilege escalation weaknesses easily.
Improper Access Control weaknesses occur when the application does not restrict or incorrectly restricts access to a resource from an unauthorized actor. For example, a user is not able to access functionality to which they are not authorized, with a browser. However, the user can access to the administrative functions with the API, without any control or broken controls. This method is a common way to find this weakness. Modern applications prefer client-side mechanisms because it is faster than server-side but at the same time easier to bypass. I suggest you think about the different access control methods between the server and the client.
Insecure Direct Object Reference (IDOR) is a type of Broken Access Control vulnerability. The problem occurs when the application does not check a user from gaining access to another user’s data by modifying the identity reference. For example, consider a function that accesses the customer page. When you access the page; you see an ID at the query. If a user changes the ID and could get the data of the modified ID, then there is an IDOR vulnerability that leads to horizontal privilege escalation. There is no limit to this vulnerability. Mostly if there is an object referenced with an ID, you may find an IDOR there. IDOR is the favorite vulnerability of many researchers.
Open Redirect is harmless in most cases. But that does not mean all instances of open redirect vulnerabilities are harmless. If you have an open redirect at SSO (Single Sign-On) or Oauth mechanism, you can steal the authentication code of the victim. If you do not want to report a simple open redirect, you can keep it for an SSRF whitelist bypass or a CSP bypass. Open Redirect can be a good part of a bug chain.
Cross-Site Request Forgery is used by attackers to send malicious requests from an authenticated user to a web application. The problem occurs when the application does not provide an anti-CSRF token or does not control the token for each request. The impact of CSRF depends on where the vulnerability. CSRF vulnerability can lead to a one-click account takeover. Such as, an attacker can change the password of your Twitter account with a one-click using this vulnerability. CSRF can be part of the turning Self-XSS into Good XSS. Unfortunately, CSRF started to be killed by browsers.
Server Side Request Forgery (also known as SSRF) vulnerabilities allows an attacker to send malicious requests from the back-end server of a vulnerable web application. An SSRF vulnerability with the maximum impact might allow an attacker to read the internal files. Additionally, with an SSRF, an attacker can scan ports (XSPA), grab the banners, execute XSS payloads, bypass host-based authentication controls. Consider that there is an image fetching function. A user gives the URL, and the server brings the file. “This is not a bug, this is a feature” so far. When the server tries to fetch the given unexpected URL (payload), the SSRF vulnerability occurs. There are some reasons why SSRF vulnerabilities are so popular. Such as, it is easy to exploit, easy to bypass, and easy to improve the impact with the protocols. But it is hard to find a parameter (endpoint) that is vulnerable to SSRF attacks because it needs a function that can send requests with the given input. Earning bounties with the SSRF requires keeping an eye open because SSRF vulnerabilities are rare.
Submission severity:
Duplicate reports are the bug hunters’ nightmare. Consider that after working for hours, you finally find a vulnerability. You report it and wait for it to be triaged. Then you get an email that says: “Unfortunately, the vulnerability was submitted previously by another researcher.”. As a consequence, everything goes to another researcher, except one thing: The experience. All the experiences that you have, make you a better researcher. Yes, it does!
As a result of this analysis, I saw that an important percentage of reports are duplicate even for the top 100 researchers. The duplicate is just a warning that says you should find unique bugs or be faster. Learn how to live with them, because they will be always there.
The majority of valid bugs have Medium or Low severity. To be honest, if you think the bug hunters hack all companies, you should change your understanding of the word “hacking”. In my opinion, finding an Open Redirect bug, not mean hacking the company. Only a minority of valid bugs have High or Critical severity. Finding a critical vulnerability depends on a comprehensive understanding of how the application works or depends on unusual techniques.
In my opinion, the signal and the impact stats is what separates successful hunters from the rest. Keep your signal high with valid reports. Then, keep your impact high with the vulnerability chains, and focus on important functions of the application.
Sometimes a bug hunter sticks with a vulnerability and usually cannot find a way to exploit or improve the impact. The best thing to do at moments like this is to collaborate. If you are looking for a hunter to collaborate, you can use https://findhunters.com/
My four year experience in bounty hunting has taught me that bug bounty becomes easier with the following recipe:
Enumeration + Fuzzing + Collaborate + to understand the application = Bounty
Thanks for reading.
Thanks for their support on this blog post
Berk Cem Göksel (https://twitter.com/berkcgoksel)
Evren Yalçın (https://twitter.com/evrnyalcin)
Mert Taşçı (https://twitter.com/mertistaken)
Dr. Süleyman Özarslan (https://twitter.com/su13ym4n)
References
https://blog.convisoappsec.com/en/privilege-escalation-how-it-can-affect-application-security/
https://blog.detectify.com/2019/01/10/what-is-server-side-request-forgery-ssrf/
https://capec.mitre.org/data/definitions/233.html
https://cwe.mitre.org/data/definitions/284.html
https://hackerone.com/reports/816143
https://owasp.org/www-community/attacks/csrf
https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
https://portswigger.net/web-security/access-control
https://portswigger.net/web-security/access-control/idor
https://portswigger.net/web-security/csrf
https://portswigger.net/web-security/ssrf
https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
https://www.bugcrowd.com/blog/how-to-find-idor-insecure-direct-object-reference-vulnerabilities-for-large-bounty-rewards/
https://www.hackerone.com/blog/hackerone-top-10-most-impactful-and-rewarded-vulnerability-types
https://www.hackerone.com/top-10-vulnerabilities
https://www.immuniweb.com/vulnerability/improper-access-control.html
https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/
https://www.netsparker.com/blog/web-security/information-disclosure-issues-attacks/
https://www.netsparker.com/blog/web-security/owasp-top-10/
https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
https://www.netsparker.com/blog/web-security/server-side-request-forgery-vulnerability-ssrf/