How to choose the Correct Severity or CVSS Score for a Bug: A Practical Guide

In the world of bug bounty hunting, one of the most critical aspects of submitting a report is accurately determining the severity or CVSS (Common Vulnerability Scoring System) score of the vulnerability. This helps the development team understand the urgency of the issue and prioritize it accordingly. Choosing the correct severity level not only reflects your understanding of the bug’s impact but also affects how seriously your report is taken.

Understanding Severity and CVSS Scores

Severity ratings typically fall into four categories: Low, Medium, High, and Critical. These categories help teams prioritize the remediation efforts based on the potential impact and risk associated with the vulnerability. However, these labels can sometimes oversimplify the issue, which is where the CVSS framework comes in.

CVSS provides a more detailed and systematic approach to scoring vulnerabilities. It considers various factors such as the attack vector, complexity, required privileges, and impact on confidentiality, integrity, and availability. The resulting score is a numeric value between 0.0 and 10.0, which can be mapped to one of the severity levels mentioned earlier.

Aspects of Determining CVSS Scores

When determining a CVSS score, the following aspects are evaluated:

1. Attack Vector (AV): How can the vulnerability be exploited? (e.g., network, adjacent, local, or physical)
2. Attack Complexity (AC): How difficult is it to exploit the vulnerability? (e.g., low or high)
3. Privileges Required (PR): What level of access does the attacker need? (e.g., none, low, high)
4. User Interaction (UI): Does the attack require user interaction? (e.g., none or required)
5. Scope (S): Does the vulnerability impact only the component it exists in, or does it affect other components as well? (e.g., unchanged or changed)
6. Impact: Evaluate the potential effects on the Confidentiality ©, Integrity (I), and Availability (A) of the system.

Example Report: Unauthorized Modification of Web Hosting Configuration

Summary:

A vulnerability was discovered in Huliahub that allows an attacker to modify the web hosting configuration of any project without proper permissions. This vulnerability can be exploited by an unauthenticated attacker who obtains the project ID or by a user with reader-only permissions.

Steps to Reproduce:

• Obtain the project ID of the target project on Huliahub.
• Craft a POST request to modify the web hosting configuration of the target project. Below is an example request:

POST /api/v1/projects/deployment_configuration/<projectid> HTTP/2
Host: huliahub.com
Cookie: 
Content-Length: 74
Sec-Ch-Ua: "Chromium";v="124", "Google Chrome";v="124", "Not-A.Brand";v="99"
Accept: application/json, text/plain, */*
Sec-Ch-Ua-Platform: "macOS"
X-Huliahub-Ensure-Js: true
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Content-Type: application/json
Origin: https://huliahub.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://huliahub.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Priority: u=1, i

{"machineType":"t32","port":9901,"dnsAutogen":true,"authentication":"me"}

• Send the request.
• The web hosting configuration of the target project gets modified according to the parameters in the malicious request.

Impact:

Unauthorized users can modify critical settings of any project, potentially causing disruptions, unauthorized access, and service downtime. This issue poses a severe risk to the confidentiality, availability and integrity and security of projects hosted on Huliahub.

Analyzing the Severity Using CVSS 3.0 Base Score

To accurately assess the severity, we use the CVSS 3.0 calculator. Here’s how the score is determined for this vulnerability:

CVSS 3.0 Metrics Breakdown:

• Attack Vector (AV): Network (N)
  The attack can be executed remotely over the network, making it accessible to attackers from anywhere.
• Attack Complexity (AC): Low (L)
  The attack does not require any special conditions or circumstances to exploit, making it relatively straightforward.
• Privileges Required (PR): Low (L)
  Although the request can be sent without privileges, it’s believed that some privileges might be required to obtain the project ID like read-only permission. This slightly mitigates the severity but still remains in the low category.
• User Interaction (UI): None (N)
  No user interaction is required to exploit this vulnerability, increasing the risk level.
• Scope (S): Unchanged (U)
  The scope remains within the same security domain, meaning the exploit does not extend beyond the impacted system.
• Confidentiality ©: High (H)
  Sensitive information could be exposed as a result of this attack, potentially allowing unauthorized access to project data.
• Integrity (I): Low (L)
  The attacker cannot alter the code or the core functionality of the project. The main risk lies in configuration changes, not in altering project content or results.
• Availability (A): High (H)
  The attack can disrupt the service by misconfiguring the project settings, leading to potential downtime.

Final CVSS Base Score: 8.3 (High Severity)

Key Points:

• Why Integrity is Low:
  The integrity score is low because the attacker cannot modify the actual code or the project’s core outputs. The changes are limited to the configuration, which, while disruptive, does not affect the integrity of the project’s calculations or results.
• Why Confidentiality and Availability are High:
  Confidentiality is rated high because unauthorized access to modify configurations could expose sensitive data. Availability is also high since improper configurations can lead to significant downtime, or not accessible on the intended configuration setting by victim impacting the project’s overall availability.
• Why Privileges Required is Low:
  The attack is mitigated slightly by the need to obtain the project ID, which might require some level of privilege. However, this is not enough to raise the privileges required beyond low, as the attack does not necessitate high-level access.

Key Takeaways

• Understand Each Aspect: Take time to evaluate each CVSS metric, as this will help in providing a more accurate severity rating.
• Use Tools: Utilize CVSS calculators to objectively assess the severity of a vulnerability.
• Communicate Clearly: When submitting bug reports, provide a detailed explanation of how you arrived at the severity rating to ensure the development team understands the risk.

Support and Follow

If you found this write-up insightful, please leave a clap and share your feedback in the comments. Follow me for more exciting findings and cybersecurity tips!

Find me on Twitter: @a13h1_

Thank you for your continued support. Keep clapping, commenting, and sharing your thoughts!