Security: Calculating the severity of an issue

HackerOne comes equipped with a handy "CVSS v3.0 Calculator" that scores the severity of each issue on a scale of 1-10 and using one of these keywords: None, Low, Medium, High, or Critical. Our SLAs on fixing issues is attached to this severity rating.

I want to walk thru each part of the calculation briefly by quoting how the calculator explains each item, then contextualizing it for Vanilla specifically.

Attack Vector

Options: Network, Adjacent, Local, or Physical. Our HackerOne campaign only includes Network-based attacks. Off to an easy start.

Attack Complexity

Options: Low or High.

This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.

Unless there is an element of timing or luck where you're required to try many times to reproduce the vulnerability once, the attach complexity is going to be Low. It's very rare to get a high-complexity report.

Privileges Required

Options: None, Low, or High. These map to Guest, User/Moderator, or Community Manager/Admin. Specifically, only the Settings.Manage and Community.Manage permissions qualify as elevating this to High.

User Interaction

Options: None or Required.

Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited.

For our purposes, this means "an action other than viewing the forum." A CSRF requires user interaction, because you must visit an attacker-controlled page. An in-page XSS does not require user interaction because it will trigger simply by navigating to the forum, which is a plausible assumption. Getting a user to click a specially constructed link is also a User Interaction being required.

Scope

Options: Changed or Unchanged.

Does a successful attack impact a component other than the vulnerable component?

The scope of an attack is typically 1 site and 1 app server. If you can escape those constraints, the scope is Changed. A remote code execution on an app server will allow you to compromise its access tokens to the rest of our infrastructure, so that is a Changed scope. This criteria is a strong indicator that a vulnerability is critical.

Comments

  • Vanilla Forums
    edited September 2018

    The last 3 criteria all have the same 3 options: None, Low, or High. While the previous criteria were all about the meta level, these are essentially measuring "what are we messing up by exploiting this issue?"

    Confidentiality

    impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

    Compromising the personal information of 1 person or a constrained number that you cannot control (like only folks who have sent you a PM) is Low. Compromising many or unlimited users is High. Same goes for private discussions - 1-few is Low, many is High.

    Integrity

    Integrity refers to the trustworthiness and veracity of information.

    Malciously editing a user's data, user-generated content, or the theme is a loss of integrity. The option is based on scope. If you can overwrite any discussion title, that's a High because it's important information in a broad context. If you can add Tags, that's Low because it's not overwriting anything and it's secondary info. If you can edit the comments of only posts by the discussion starter, that Low because the scope is considerably constrained.

    Availability

    It refers to the loss of availability of the impacted component itself, such as a networked service

    This is about preventing access to the forum (High) or a particular asset like a discussion or user profile (Low). If you filled the hard drive for the database and take one or more sites down, that's a High availability issue. If you put a malicious image in 1 discussion and it no longer renders in a browser, that's a Low availability issue.

  • A good example of a higher complexity attack would be an attack where a user uploads a file and then requires local access to the file in order to complete the attack.

    On OSS this is a low complexity attack because all files are uploaded to the /uploads directory.

    On cloud this is high complexity attack because we move files to a CDN and delete the local files. I don't want to guarantee that it's impossible for an attacker to get a file to stay in the /uploads directory, but if they are able to find a way it is probably through many attempts.