Negotiate your bugs to win more

When it comes to finding bugs, there are different steps. You first need to find a bug, but then, when you report it, how can you evaluate your findings? How can you know if it's a Critical or a Low? Based on the bug bounty world it comes with a metric: the CVSS. And we will use it to evaluate a bug.

Is it a good way to evaluate a bug or not? It depends, it's not perfect and for a lot of bugs, the value can be wrong based on the company. And a bug with the same CVSS in a website can be more impactful than in another website.

So, how can we know and evaluate our bugs if they change based on the company? You can't, and you need to use the CVSS because all the platforms use it. Why? Because this is the most accurate way to evaluate a bug and have a clear reward grid. Some programs use their own CVSS calculator like Shopify, with other metrics so it can change, but most of the programs still use the CVSS 3.1 so you need to learn it.

Just for those who don't know what it is, CVSS means Common Vulnerability Scoring System. To this day, there are 4 versions of the calculator with different metrics, but most of the platforms use version 3.1, the most "stable" version at the moment.

Of course, this is not right for some types of bugs. Here is an example. In my opinion, this is the most characteristic way to see the issues of the CVSS system. If you find a website that way, unauthenticated, to have access to all the databases, but in read-only, you can get a massive PII leak, and get addresses, phone numbers, and insurance numbers of massive users. How can you evaluate this? Using CVSS it will be like this:

In the end, this is a simple High. Even if for you this is Critical and you can leak multiple data from all the users, it's a High. Some platforms try to change that like hackerone recognizing that this type of bug is now Criticals.

I don't want to just present this system and trash it. This is a way to evaluate the bug, and for bug hunter the way to get money. So we need to know it to live ( for the full-time hunter of course ). There are some tricks to know before evaluating a bug, and you need to know the specifications of the CVSS.

At first, when I needed to evaluate my bugs, I was pretty bad and didn't know much about them. But after having read the specification ( read it, it will help you a lot https://www.first.org/cvss/v3.1/specification-document ), I found that some metrics can help us to increase the score of some bugs.

About the tryptic CIA, it always depends on the bug and the impact on the system you are evaluating, so there are no tricks about it, except for some category of bugs.

XSS

When you find an XSS, how to evaluate it? It can be from Low to Criticals. Yes yes, critical. A lot of programs think that XSS is Low of Medium, but with a good POC, you can leverage it to a High or a Critical bug.

Let's take an example. You find a Reflected XSS on the search bar of a website, and you can make the basic POC alert(1). If you directly report it like that, the CVSS will be something between Low and Medium. There is no impact, nothing proved that you can leak data, so the program will just handle it as a no-impact bug. We'll leverage it.

Scope

The Scope metric can be Changed or Unchanged. Here is the description :

So if you can affect other resources and components than the original one, the scope is changed. This is unclear and hard to understand at first, but if you look at the examples given by the CVSS itself, an XSS has the Scope set to Changed ( https://www.first.org/cvss/v3.1/examples ). Why? Because of that :

You change the scope from the web server to the victim's browser so you can set the scope to Changed in every XSS you found. For instance, if there is a 0day in a browser, with an XSS you can be able to exploit it and have access to other components of the victim's browser, that's why an XSS can have this metric Changed.

User Interaction

Based on the spec, you need to set it to Required most of the time. If the user needs to visit a link you send or to click on a button in your profile, it looks like the UI will be Required. Some hunters think that if they click in the normal flow of the app, it will not be Required so this is quite blurry, so tell me what you think about that.

Otherwise, if the user just visits the site normally and navigates, and then an XSS pops out, the UI is None in my opinion.

CIA

About Confidentiality, Integrity, and Availability, of course, it will depend on the app. But based on an XSS you can leverage some of them. First, stop reporting only an alert(document.domain), there is absolutely no impact with that. And I did it in the past, and programs will just don't handle it as an impactful bug.

First, If there is authentication and users on the app, you need to find a way to account takeover with your XSS. By getting the authentication cookie if he is not httpOnly or by making a javascript POC to change the user email or password. Each time I found an XSS, I was able to find a way to modify something on the account to account takeover. It's not that hard, and you can craft payloads easily using ChatGPT now ( please don't give details about the vulnerability or the website, use it generally to understand what you are doing and to get some lines of javascript ).

If it's not possible to account takeover, just try to find a way to modify the app or some important parameters. Maybe an admin can create an admin account, so you will be able to get a privilege escalation by making a new admin user. So many possibilities with XSS, so stop making the wrong poc with just an alert.

About the Availability, it can be hard to leverage it, but there is a trick: the Cookie Bomb. By making a javascript poc to create a lot of cookies to crash the victim's browser, it will set the Availability to Low. From a hacker's perspective, you know that by deleting the cookies you can go back on the website. But from the normal guy, they don't know how to fix that so that you can use it in your reports.

Other bugs

I talked about XSS, but it's the same for all other vulnerabilities. By reading the specification, you can leverage your score and negotiate with the program. About the other metrics here is what I know :

Privilege Required

Sometimes it's clear, sometimes it's not. In some programs, if you can self-register, you can tell that the Privilege Required is None, but some of them will not accept it.

Attack Complexity

This metric is unclear in a lot of cases. One thing to know is that that's not because the user needs to click on multiple links or follow a certain path that the Attack Complexity must be High, this is covered by the User Interaction :

Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric).

It's hard to set Attack Complexity to High, here are some examples of where you will need to use it :

• When you find an IDOR with UUID, as this is not predictable, the AC will be High
• When the attacks don't work 100% of the time. Maybe you will find a DoS that works only 40% of the time in a specific environment, so the AC will be High too

Conclusion

All of these are some tricks you can use as a Bug Hunter. And it's fair because programs accepted to use the CVSS metrics so you need to use it and negotiate your bugs. Sometimes, they will try to decrease the score, then you can send the specification document to point out every metric you disagree with and give examples.

I wanted to point out that it's not a way to set all your bugs to critical and respect the CVSS, even if your bug is only a Medium. It's the game, you need to play with all the rules. If you write a bad report without a poc to show the impact of the bug, it's normal that they don't pay you more.

I learned all of this during my last year of bug hunting, and I wanted to thank Blaklis and Geluchat, the bosses of the CVSS who know the specifications by heart.

I may be wrong on some points, so feel free to correct me if you disagree with some metrics, I would love to know more about that.

Feel free to subscribe to me on Twitter or here to receive the next articles ;)