[ Beneath the Waves ]

YFVS - Example Comparison

Ben Lincoln

 

Table of Contents

  1. Definitions
  2. Scoring Walkthrough 1: Heartbleed
  3. Scoring Walkthrough 2: ShellShock
  4. Scoring Walkthrough 3: Custom Web Application Reflected Content-Spoofing/Cross-Site Scripting
  5. Scoring Walkthrough 4: Apache Tomcat Default Shutdown Password
  6. Scoring Walkthrough 5: Vulnerability Chain/Tree — Use of Sequential Object Identifiers, Missing Authorization Check
  7. Scoring Walkthrough 6: Vendor A Vulnerability Chain/Tree
  8. Scoring Walkthrough 7: Vendor B Vulnerability Chain/Tree
  9. Scoring Walkthrough 8: Vendor C Vulnerability Chain/Tree
  10. Bulk YFVS 0.4 Versus CVSS 2.0 Comparison Table

Definitions

When reading the questions and answers in The live YFVS 0.4 score calculator:

Scoring Walkthrough 1: Heartbleed

The first example I'll use is Heartbleed (CVE-2014-0160), because:

Heartbleed, of course, is the vulnerability in OpenSSL which allowed an attacker to read a 64kb chunk of memory from the webserver process running on target systems. The location of the 64kb chunk in memory would vary over time — the attacker had no direct control over which 64kb chunk of memory was read.

There are three useful ways I can think of to describe the scope of this vulnerability for scoring purposes. I've picked Apache httpd as the vulnerable webserver, but the same high-level descriptions would apply to most/all other OpenSSL-based webservers.

  1. Heartbleed is a reliable vulnerability in the combination of OpenSSL and Apache httpd which allows an attacker to make a request which has a small chance of returning sensitive data (credentials, TLS/SSL private keys, etc.).
  2. Heartbleed is an unreliable vulnerability in the combination of OpenSSL and Apache httpd which allows an attacker to make a request which will return sensitive data.
  3. Heartbleed is a reliable vulnerability in the combination of OpenSSL and Apache httpd which — when used many times — allows an attacker to reliably build up a fairly accurate picture of the target process's memory space, but doing so is "noisy".

The CVSS method of scoring this is to treat it as a "partial compromise" of "confidentiality", because some data about the target system is returned, but not nearly all of it. The other legs of the C/I/A triangle are set to "no impact", because the vulnerability does not allow the attacker to directly change data on the system, or cause a denial-of-service condition. The resulting CVSS 2.0 base score for this world-famous flaw in a ubiquitous product is therefore 5.0 (signature: AV:N/AC:L/Au:N/C:P/I:N/A:N). It doesn't actually matter which of the three scopes are used, because in neither case will all of the data within the system become accessible to the attacker, and no other factors that differ between those scopes significantly influence the score.

Now let's walk through scoring the vulnerability using YFVS 0.4. We'll start out by using the first scope, then go back and modify the result to change it into the second and third.

  1. Heartbleed does not allow any code execution, so Code/Command/Function Execution is set to No additional code/command/function execution (YCE:1).
  2. Heartbleed does not allow any data to be modified (only read), so Control Over Configuration/Data is set to No additional control over configuration/data (YDC:1).
  3. Heartbleed does provide data that can include credentials, so Information Disclosure is set to The vulnerability provides access to information beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system), OR access to valid credentials of any kind OR access to information whose disclosure in a real-world attack would lead to external regulatory action or other externally-imposed penalties (YID:10).
  4. Heartbleed does not provide an attacker with any additional denial-of-service capabilities, so Impact To Availability / Denial of Service Capability is set to No additional impact to availability (YAI:1).
  5. Heartbleed does not bypass other security controls or exploit business logic flaws, so Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. Nothing beyond the ability to connect to the vulnerable service using TCP is required, so Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. The flaw is exploitable anonymously, so Authentication is set to No authentication / anonymous access (EAT:10).
  8. Because no authentication is required, the only value for Authorization that makes sense is Default privileges/no privileges/no authentication (EAZ:10).
  9. The vulnerability can be exploited directly, so User Interaction is set to No (EUI:10).
  10. In the default configuration, httpd will identify itself by version number in several ways, but that version number may be insufficient to reliably determine if it is vulnerable or not, so Vulnerability Instance Recognition is set to Some element of the system displays information that uniquely identifies it as being of the same "lineage" as the version/model which contains the vulnerability (e.g. an HTTP header indicates that the server is "Apache Tomcat", but does not include a version number), but the only way to remotely determine if the system is actually vulnerable is to actively attempt to exploit it. (EVR:4).
  11. We're beginning with the "reliable vulnerability which has a small chance of returning sensitive data" scenario, so Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. End users have no visibility into whether the flaw is being exploited, so User Visibility is set to Exploiting the vulnerability does not cause any changes to the application that can be detected by users interacting with the system using the standard interface(s) of the system itself. (SUV:10).
  13. Heartbleed depends on the client explicitly sending a request in which the size of the value it is sending and the size it is requesting in response do not match. This may be difficult to represent using some IDS-type-system configuration models, but it is unique to exploitation, so Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect which unambiguously indicates that exploitation has taken place (a 512-byte value unique to the exploit appears in network traffic, etc.) (SPV:1).
  14. Apache httpd will not log any information related to TLS/SSL heartbeats, so Logging is set to Exploiting (or attempting to exploit) the vulnerability does inherently not cause any log entries to be written, or the log entries are indistinguishable from normal activity (a fileserver logs a successful authentication by a user account) (SLG:10). Potential logging via external components will be handled later.
  15. Apache httpd is easily available to anyone, so System Information Accessibility is set to The vulnerable system is available to the public, is available in multiple countries, or is used by more than twenty-five distinct organizations (PIA:10).
  16. The vulnerability in OpenSSL could be discovered by reading the (publicly-available) source code, so Obviousness is set to The vulnerability can be discovered by examining human-readable artifacts related to an instance/installation of the system (e.g. JSP/HTML files, WAR files and other standard archive formats, scripts, source code if source code is publicly available, instruction manuals) (POB:5).
  17. As of this writing, Heartbleed has been publicly-disclosed, and the disclosure included the specifics of how to exploit it, so Disclosure is set to The vulnerability has been publicly disclosed, with sufficient detail to identify all of the following: the vulnerable product/package, the type of vulnerability (buffer overflow, XSS, XXE, etc.), and the method/function/means of interacting with the system which is vulnerable to the attack (e.g. for a cross-site scripting vulnerability, the URL of the vulnerable page, for a missing authentication/authorization check, the address/location of the vulnerable component, etc.) (PDS:10).
  18. As of this writing, several variations on functional exploit code (including a Metasploit module) are available, so Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10).
  19. Exploiting Heartbleed does not require anything other than a standard computer, so Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Running the exploit enough times to return sensitive data would take more than a minute, so Time Required to Exploit is set to Real-world exploitation of the vulnerability would take longer than one minute, but less than one year using presently-known methods (e.g. cracking a large list of hashed user passwords) (PTR:5).

At this point, the vulnerability has been scored as it applies to all instances of vulnerable versions of Apache httpd (signature: [YFVS 0.4]YCE:1/YDC:10/YID:1/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:10/SPV:1/SLG:10/PIA:10/POB:5/PDS:10/POE:10/PRR:10/PTR:5/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U). The resulting score is 9.1. Let's go back and modify it into the second scenario to see what effect this has.

  1. The second way of viewing Heartbleed is as an unreliable vulnerability which reliably returns sensitive data when it succeeds, so based on writeups regarding proof-of-concept exploits, Reproducibility is set to The exploit succeeds fewer than 1 time in 10,000 (ERP:1).
  2. ...however, each attempt happens almost instantly, so Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10).

The resulting overall score of 9.0 (signature: [YFVS 0.4]YCE:1/YDC:10/YID:1/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:4/ERP:1/SUV:10/SPV:1/SLG:10/PIA:10/POB:5/PDS:10/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U) is close enough to consider both of these perspectives essentially equivalent. How about the third way of interpreting Heartbleed?

  1. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  2. Time Required to Exploit is set to Real-world exploitation of the vulnerability would take longer than one minute, but less than one year using presently-known methods (e.g. cracking a large list of hashed user passwords) (PTR:5).

The final score is back up to 9.1 (signature: [YFVS 0.4]YCE:1/YDC:10/YID:1/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:10/SPV:1/SLG:10/PIA:10/POB:5/PDS:10/POE:10/PRR:10/PTR:5/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U). Ideally the scoring values would exactly cancel each other out, but for a version 0.4 draft, I'm happy with a variation of 0.1 between all three ways of viewing the vulnerability.

Scoring Walkthrough 2: ShellShock

ShellShock (CVE-2014-6271, as well as numerous others) is a little bit more complicated, because in my opinion there are two significantly different ways of interpreting this vulnerability:

  1. ShellShock is a vulnerability in the Bash Unix/Linux shell which allows function definitions to be unexpectedly passed to child processes, although those child processes will typically operate in a context that an attacker already has access to.
  2. ShellShock is a vulnerability in the combination of a webserver (we'll use Apache httpd again), the Common Gateway Interface (CGI) specification, and the Bash Unix/Linux shell which allows unauthenticated remote command execution (and therefore, in most cases, remote code execution) at the OS level in the context of the account under which the webserver process operates.

I prefer the second point of view, because Bash predates the components which actually make this vulnerability so fantastic, but let's score it using the first scope to start with:

  1. There is some tiny potential to trick users into running commands that behave differently than expected, so Code/Command/Function Execution is set to In an elevated/altered context within the vulnerable system (e.g. a user account can be used to access some additional functionality in an application by making calls directly to an API which fails to perform authorization checks correctly, or other users can be tricked into performing actions on behalf of an attacker via cross-site scripting, cross-site request forgery, etc.) (YCE:5).
  2. Again, there is some tiny potential for unexpected effects, so Control Over Configuration/Data is set to The ability to persistently modify some configuration and/or data stored in the vulnerable system, or to tamper with some configuration/data as it is transmitted between systems (YDC:5).
  3. For the same reason, Information Disclosure is set to Some of the information stored within or transmitted by the system (other than non-credential system configuration/state) which is not accessible in the absence of the vulnerability is made available (system-level access control has been partially bypassed) (YID:7).
  4. There are no additional denial-of-service capabilities, so Impact To Availability / Denial of Service Capability is set to No additional impact to availability (YAI:1).
  5. ShellShock (when discussing Bash alone) does not bypass other security controls or exploit business logic flaws, so Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. The ability to exploit ShellShock in this context requires the ability to log onto the system via other means, so Connectivity is set to The vulnerability can be exploited remotely, but requires connectivity via a means outside the scope of the vulnerable system (e.g. an escalation-of-privilege vulnerability in a command-line shell) (ECN:5).
  7. Logging on requires at least single-factor auth, so Authentication is set to Single-factor authentication (EAT:5).
  8. Our trivial vulnerability doesn't necessarily require special privileges, so Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. The type of trivial exploitation being described would typically require another user to execute a malicious script of some sort, so User Interaction is set to Yes, but exploitation is automatic for users of the vulnerable system one that system has been "seeded" with the exploit (e.g. a stored/persistent cross-site scripting vulnerability) (EUI:7).
  10. Bash identifies itself by full version number, so Vulnerability Instance Recognition is set to It is possible to accurately identify the system as being vulnerable, and doing so does not require authenticating to the system or attempting to exploit the vulnerability (e.g. a section of the vulnerable system which is accessible to unauthenticated users displays a full version number, or all versions of the product are vulnerable). (EVR:10).
  11. ShellShock always works against vulnerable versions of Bash, so Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. End users would be able to see unusual environment variables (at a minimum) if their session was exploited, so User Visibility is set to Exploiting the vulnerability causes the system to behave in a way that indicates to users that something has changed, but does not conclusively indicate exploitation (a new entry is added to a list, but it does not appear out-of-place, a machine name in an RSS feed URL has changed, but the RSS feed renders correctly, etc.) (SUV:5).
  13. ShellShock takes advantage of a little-used feature in the Bash specification, so Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect, but there are other potential causes (a single quote and SQL statements appear in network traffic, an abnormally long alphanumeric value is sent from a client to the server, a section of memory marked as "data" is executed as code, a new servlet is added to an existing web application server, etc.) (SPV:5).
  14. Logging is set to Exploiting (or attempting to exploit) the vulnerability does inherently not cause any log entries to be written, or the log entries are indistinguishable from normal activity (a fileserver logs a successful authentication by a user account) (SLG:10).
  15. Bash is easily available to anyone, so System Information Accessibility is set to The vulnerable system is available to the public, is available in multiple countries, or is used by more than twenty-five distinct organizations (PIA:10).
  16. The vulnerability in Bash could technically be discovered by an end user messing around with environment variables, so Obviousness is set to The vulnerability can be discovered while using the system as intended (for a web application with forms, entering a name with a single quote in it causes an error/crash due to a SQL injection vulnerability) (POB:10).
  17. As of this writing, ShellShock has been publicly-disclosed, and the disclosure included the specifics of how to exploit it, so Disclosure is set to The vulnerability has been publicly disclosed, with sufficient detail to identify all of the following: the vulnerable product/package, the type of vulnerability (buffer overflow, XSS, XXE, etc.), and the method/function/means of interacting with the system which is vulnerable to the attack (e.g. for a cross-site scripting vulnerability, the URL of the vulnerable page, for a missing authentication/authorization check, the address/location of the vulnerable component, etc.) (PDS:10).
  18. As of this writing, several variations on functional exploit code (including a Metasploit module) are available, so Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10).
  19. Exploiting ShellShock does not require anything other than a standard computer, so Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Exploitation is virtually instantaneous, so Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10).

The resulting description (signature: [YFVS 0.4]YCE:5/YDC:5/YID:7/YAI:1/YCB:1/ECN:5/EAT:5/EAZ:10/EUI:7/EVR:10/ERP:10/SUV:5/SPV:5/SLG:10/PIA:10/POB:10/PDS:10/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U) results in an overall score of 6.2, which is artificially low because we've just described the scope incorrectly — what makes this vulnerability interesting is how additional system components allow it to be exploited much more effectively. In other words, the vulnerability is not in Bash alone, even if it was addressed by code changes to Bash. Changing the scope to "the combination of Apache httpd, the Common Gateway Interface (CGI) specification, and the Bash Unix/Linux shell", let's update some of the scoring elements:

  1. The vulnerability allows penetration from a webserver service to the OS itself, so change Code/Command/Function Execution to Beyond the scope of the vulnerable system (e.g. a webserver vulnerability allows arbitrary shell commands to be executed on the host OS) (YCE:10).
  2. Similarly, shell access allows OS-level data to be modified, so Control Over Configuration/Data is updated to Configuration or data stored beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system) can be modified (YDC:10).
  3. Similarly, alter Information Disclosure to The vulnerability provides access to information beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system), OR access to valid credentials of any kind OR access to information whose disclosure in a real-world attack would lead to external regulatory action or other externally-imposed penalties (YID:10) to account for the ability to read OS-level data.
  4. At a bare minimum, shell access in the context of the account under which the webserver runs will typically allow me to take down the webserver service, so Impact To Availability / Denial of Service Capability is set to Exploiting the vulnerability can result in a complete outage of the vulnerable system which will persist until the system owner/administrator (or appropriate external automation) takes some action (YAI:9).
  5. The ShellShock vulnerability can be exploited with a "poisoned" HTTP request header, so update Connectivity to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  6. No authentication is required, so Authentication should be set to No authentication / anonymous access (EAT:10).
  7. User Interaction should be changed to No (EUI:10) as none is required.
  8. Determining that a particular webserver instance is vulnerable is harder so Vulnerability Instance Recognition is set to Some element of the system displays information that uniquely identifies it as being of the same "lineage" as the version/model which contains the vulnerability (e.g. an HTTP header indicates that the server is "Apache Tomcat", but does not include a version number), but the only way to remotely determine if the system is actually vulnerable is to actively attempt to exploit it. (EVR:4).
  9. Users will no longer see changes due to the exploit, so User Visibility is updated to Exploiting the vulnerability does not cause any changes to the application that can be detected by users interacting with the system using the standard interface(s) of the system itself. (SUV:10).
  10. The "poisoned" HTTP headers are distinctive to exploitation of the vulnerability, so Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect which unambiguously indicates that exploitation has taken place (a 512-byte value unique to the exploit appears in network traffic, etc.) (SPV:1).
  11. Discovering the vulnerability (without existing knowledge of it) could realistically only be done by combing through source code, so Obviousness is set to The vulnerability can be discovered by examining human-readable artifacts related to an instance/installation of the system (e.g. JSP/HTML files, WAR files and other standard archive formats, scripts, source code if source code is publicly available, instruction manuals) (POB:5).

The new overall score of 9.3 (signature: [YFVS 0.4]YCE:10/YDC:5/YID:10/YAI:9/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:10/SPV:1/SLG:10/PIA:10/POB:5/PDS:10/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U) much more accurately reflects the severity of this vulnerability. It is very bad, but there is still some room left over because it could technically be worse.

So what about CVSS? I believe an honest scoring using the CVSS 2.0 criteria would give a result of 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P/E:H/RL:U/RC:C), because the default/most common configuration for Unix/Linux webservers today has them running as non-superuser accounts. However, NIST appear to have cheated when scoring ShellShock, and rated it as a "complete" compromise of all three C/I/A factors for the entire host OS (AV:N/AC:L/Au:N/C:C/I:C/A:C), which is only possible if the webserver is running as root. I imagine this was to ensure that it achieved a 10.0 CVSS 2.0 score — probably as a result of complaints about Heartbleed being scored "too low" months earlier.

Scoring Walkthrough 3: Custom Web Application Reflected Content-Spoofing/Cross-Site Scripting

The two previous examples covered vulnerabilities as they would be scored by the vendor of a product — with the base and temporal factors scored, but none of the deployment-specific values.

The next scenario will be much more specific: a penetration test has revealed a reflected content-spoofing vulnerability in an online store. That is, if an attacker can convince a victim to click on a crafted link, the online store will display a page that has some of the text set by the crafted link. In this case, it is an error page which can display an arbitrary message (such as "Your recent order has been declined. Please call 1-877-763-2537 to verify your credit card information."). The tester has not found a way to use the vulnerability for cross-site scripting — only the display of arbitrary text.

  1. Code/Command/Function Execution is set to No additional code/command/function execution (YCE:1).
  2. Control Over Configuration/Data is set to The ability to non-persistently modify the appearance of the vulnerable system (e.g. a content-spoofing vulnerability which requires that users access a crafted URL) (YDC:3).
  3. Information Disclosure is set to No information disclosure (YID:1).
  4. Impact To Availability / Denial of Service Capability is set to No additional impact to availability (YAI:1).
  5. Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. Authentication is set to No authentication / anonymous access (EAT:10).
  8. Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. User Interaction is set to Yes - exploitation requires that users (or their client systems) must take some action beyond normal use of the vulnerable system, but there is no indication that anything out of the ordinary is occurring (most reflected cross-site scripting vulnerabilities, etc.) (EUI:5).
  10. This vulnerability is specific to the website being tested (it is custom code), so Vulnerability Instance Recognition is set to Some element of the system displays information that uniquely identifies it as being of the same "lineage" as the version/model which contains the vulnerability (e.g. an HTTP header indicates that the server is "Apache Tomcat", but does not include a version number), but the only way to remotely determine if the system is actually vulnerable is to actively attempt to exploit it. (EVR:4).
  11. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. User Visibility is set to Exploiting the vulnerability causes the system to behave in a way that indicates to users that something has changed, but does not conclusively indicate exploitation (a new entry is added to a list, but it does not appear out-of-place, a machine name in an RSS feed URL has changed, but the RSS feed renders correctly, etc.) (SUV:5).
  13. Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect, but there are other potential causes (a single quote and SQL statements appear in network traffic, an abnormally long alphanumeric value is sent from a client to the server, a section of memory marked as "data" is executed as code, a new servlet is added to an existing web application server, etc.) (SPV:5).
  14. Logging is set to Exploiting (or attempting to exploit) the vulnerability inherently causes log entries to be written which indicate the date and time of activity which is unusual, but not necessarily an exploit attempt (a search indexer receives several hundred document submissions in the space of a minute, etc.) (SLG:5).
  15. System Information Accessibility is set to The vulnerable system is completely proprietary and known only to members of the organization where it is used (PIA:1), because this is a custom web application used by no other organization.
  16. The tester found the vulnerability via a Burp Suite vulnerability scan, so Obviousness is set to The vulnerability can be discovered using one or more automated tools (POB:8).
  17. Disclosure is set to The vulnerability has not been publicly disclosed (yet) (PDS:1).
  18. Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10), because building a crafted link does not require coding.
  19. Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10), because the action is essentially instantaneous once the victim's browser accesses the crafted URL. The base score is now 1.4 (signature: [YFVS 0.4]YCE:1/YDC:3/YID:1/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:5/EVR:4/ERP:10/SUV:5/SPV:5/SLG:5/PIA:1/POB:8/PDS:1/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U).
  21. Connectivity/Accessibility is set to The vulnerable system instance is remotely-accessible to the public (e.g. the internet) (MCN:10).
  22. Instance Context is set to No modification to context (MIC:0) — the web application is running as a non-privileged account on the webserver.
  23. Authentication is set to No change (MAT:0).
  24. Availability is set to The responsible organization considers performance/availability issues for the vulnerable system instance to be of higher than usual severity, but still tolerable (MAV:3) for purposes of accurate data collection, although the score is unaffected in this case because there is no denial-of-service capability.
  25. Workarounds is set to No change (MWA:0).
  26. Detection is set to No external component will detect attempts to exploit the vulnerable system instance (MDT:10).
  27. Manual Response is set to No manual response has been defined (MMR:6).
  28. Automated Response is set to No automated response has been configured (MAR:0).
  29. Forensic Traceability is set to No change to forensic/logging information considerations (MFT:0).
  30. Further Compromise is set to The vulnerability does not compromise any other systems (QFC:1).
  31. Physical is set to No physical consequences (QPH:1).
  32. Information Leakage is set to Successful exploitation does not result in leakage of information (QIL:1).
  33. Financial/Business is set to There are no potential financial consequences to successful exploitation (QFB:1), because there are no direct financial consequences to exploitation of the vulnerability.
  34. Legal is set to There are no potential legal consequences (QLG:1).

The final real-world implementation score for this vulnerability (as described) is 1.6 (signature: [YFVS 0.4]YCE:1/YDC:3/YID:1/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:5/EVR:4/ERP:10/SUV:5/SPV:5/SLG:5/PIA:1/POB:8/PDS:1/POE:10/PRR:10/PTR:10/MCN:10/MIC:0/MAT:0/MAV:3/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:1/QPH:1/QIL:1/QFB:1/QLG:1).

But wait — the penetration tester is able to find an obscure combination of encoding and barely-valid HTML and JavaScript which elevates this vulnerability into cross-site scripting territory. How is the score modified?

  1. Code/Command/Function Execution is set to In an elevated/altered context within the vulnerable system (e.g. a user account can be used to access some additional functionality in an application by making calls directly to an API which fails to perform authorization checks correctly, or other users can be tricked into performing actions on behalf of an attacker via cross-site scripting, cross-site request forgery, etc.) (YCE:5). This custom web store does not allow admin/superuser access via the front-end, so operating in the context of another customer is the worst that can happen.
  2. Control Over Configuration/Data is set to The ability to persistently modify some configuration and/or data stored in the vulnerable system, or to tamper with some configuration/data as it is transmitted between systems (YDC:5), because even in a worst-case scenario, an attacker can only modify other customers' accounts, not e.g. data about products for sale.
  3. Information Disclosure is set to Some of the information stored within or transmitted by the system (other than non-credential system configuration/state) which is not accessible in the absence of the vulnerability is made available (system-level access control has been partially bypassed) (YID:7).
  4. Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect which unambiguously indicates that exploitation has taken place (a 512-byte value unique to the exploit appears in network traffic, etc.) (SPV:1), because the XSS exploit code has a unique signature.
  5. Logging is set to Exploiting (or attempting to exploit) the vulnerability inherently causes log entries to be written which unambiguously indicate the date and time that an attempt was made (the vulnerable system generates an alert that a request was received to update a "canary" value in its database, etc.) (SLG:1) for similar reasons (the URLs of requests are logged by the webserver).
  6. Information Leakage is set to Successful exploitation results in exposure (outside the control of the responsible organization) of data the organization has classified in-between the lowest and highest sensitivity ratings - for example, when using NIST data classification, the sensitivity of the data would be 'Medium' (QIL:6), because the attacker can view the shipping address, phone number, and email address of existing customers, but not existing credit card numbers or other information the online store owner classifies as "highly-sensitive".
  7. Financial/Business is set to Successful exploitation can directly result in financial or business consequences, but the organization responsible for the system will continue to operate (QFB:5).
  8. Legal is set to Successful exploitation can directly result in legal proceedings other than those listed below (e.g. a civil lawsuit) against at least one member of the organization responsible for the system, or the organization itself (QLG:7), because of the possibility of customer data being stolen.

Now that the XSS capability has been described, the score has jumped to 5.4 (signature: [YFVS 0.4]YCE:5/YDC:5/YID:7/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:5/EVR:4/ERP:10/SUV:5/SPV:1/SLG:1/PIA:1/POB:8/PDS:1/POE:10/PRR:10/PTR:10/MCN:10/MIC:0/MAT:0/MAV:3/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:1/QPH:1/QIL:6/QFB:5/QLG:7).

If the organization considered this type of customer data "high-sensitivity", the score would increase to 8.4 (signature: [YFVS 0.4]YCE:5/YDC:5/YID:7/YAI:1/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:5/EVR:4/ERP:10/SUV:5/SPV:1/SLG:1/PIA:1/POB:8/PDS:1/POE:10/PRR:10/PTR:10/MCN:10/MIC:0/MAT:0/MAV:3/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:1/QPH:1/QIL:10/QFB:5/QLG:7).

Scoring Walkthrough 4: Apache Tomcat Default Shutdown Password

One of my "favourite" "features" of Apache Tomcat is that for some reason, its developers decided to have it listen on a distinct port for a special shutdown command, and if it was received, terminate the Tomcat process. Why only shutdown? I would think either no functionality would be exposed in this way, or other functionality (e.g. restart) would be as well. Perhaps they had watched Star Trek II a few too many times, and wanted to ensure that if someone hijacked their Tomcat instance, they could at least take it out of commission remotely. In any case, rather the value being random by default, it is the word SHUTDOWN in all-caps. It's a built-in denial-of-service capability, as long as the attacker has remote access to that port (8005 by default).

For this hypothetical scenario, consider a Tomcat instance used to host a web application used by university staff to track student attendence in classes. It won't be the end of the world if it's unavailable, but if a particular student wishes to miss class and not show up on the list, they may attempt to DoS the service and hope that their teacher forgets to update the data when the system is back online.

  1. Code/Command/Function Execution is set to No additional code/command/function execution (YCE:1).
  2. Control Over Configuration/Data is set to No additional control over configuration/data (YDC:1).
  3. Information Disclosure is set to No information disclosure (YID:1).
  4. Impact To Availability / Denial of Service Capability is set to Exploiting the vulnerability can result in a complete outage of the vulnerable system which will persist until the system owner/administrator (or appropriate external automation) takes some action (YAI:9).
  5. Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. Authentication is set to Single-factor authentication (EAT:5) — because there is technically a password. The fact that it's the default will be accounted for in the deployment/instance-specific category.
  8. Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. User Interaction is set to No (EUI:10).
  10. Vulnerability Instance Recognition is set to Some element of the system displays information that uniquely identifies it as being of the same "lineage" as the version/model which contains the vulnerability (e.g. an HTTP header indicates that the server is "Apache Tomcat", but does not include a version number), but the only way to remotely determine if the system is actually vulnerable is to actively attempt to exploit it. (EVR:4).
  11. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. User Visibility is set to Exploiting the vulnerability causes the system to behave in a way that unambiguously indicates to users interacting with the system using the standard interface(s) that something unusual has occurred (highly-visible machine-generated content, highly-visible extra entries in lists, the system stops responding entirely until administrative action is taken, etc.) (SUV:1), because the system will become unavailable when exploited.
  13. Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect, but there are other potential causes (a single quote and SQL statements appear in network traffic, an abnormally long alphanumeric value is sent from a client to the server, a section of memory marked as "data" is executed as code, a new servlet is added to an existing web application server, etc.) (SPV:5), because there is no way to differentiate between legitimate and malicious shutdown requests when the only authentication is a shared password without a user identifier attached.
  14. Logging is set to Successfully exploiting the vulnerability inherently causes log entries to be written which indicate the date and time of activity which is unusual, but not necessarily an exploit attempt, AND unsuccessful attempts do not generate unusual activity (failed publish requests for servlets are not logged, but successful requests are) (SLG:7).
  15. System Information Accessibility is set to The vulnerable system is available to the public, is available in multiple countries, or is used by more than twenty-five distinct organizations (PIA:10).
  16. Obviousness is set to The vulnerability can be discovered by examining human-readable artifacts related to an instance/installation of the system (e.g. JSP/HTML files, WAR files and other standard archive formats, scripts, source code if source code is publicly available, instruction manuals) (POB:5).
  17. Disclosure is set to The vulnerability has been publicly disclosed, with sufficient detail to identify all of the following: the vulnerable product/package, the type of vulnerability (buffer overflow, XSS, XXE, etc.), and the method/function/means of interacting with the system which is vulnerable to the attack (e.g. for a cross-site scripting vulnerability, the URL of the vulnerable page, for a missing authentication/authorization check, the address/location of the vulnerable component, etc.) (PDS:10).
  18. Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10).
  19. Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10). The base score is now 7.8 (signature: [YFVS 0.4]YCE:1/YDC:1/YID:1/YAI:9/YCB:1/ECN:10/EAT:5/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:1/SPV:5/SLG:7/PIA:10/POB:5/PDS:10/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U).
  21. Connectivity/Accessibility is set to The vulnerable system instance is remotely-accessible from systems that exclusively perform unrelated functions within the same organization (MCN:5).
  22. Instance Context is set to No modification to context (MIC:0).
  23. Authentication is set to At least one set of credentials which can be used to exploit the vulnerability are identical to the default values for the system (MAT:4).
  24. Availability is set to It is acceptable for the vulnerable system instance to experience degraded performance or outages limited to the length of time that manual or automated processes will take to restart the system in the event of an outage (MAV:-3), because this system is not considered highly-critical by the hypothetical university.
  25. Workarounds is set to No change (MWA:0).
  26. Detection is set to No external component will detect attempts to exploit the vulnerable system instance (MDT:10).
  27. Manual Response is set to No manual response has been defined (MMR:6).
  28. Automated Response is set to No automated response has been configured (MAR:0).
  29. Forensic Traceability is set to No change to forensic/logging information considerations (MFT:0).
  30. Further Compromise is set to The vulnerability does not compromise any other systems (QFC:1).
  31. Physical is set to No physical consequences (QPH:1).
  32. Information Leakage is set to Successful exploitation does not result in leakage of information (QIL:1).
  33. Financial/Business is set to There are no potential financial consequences to successful exploitation (QFB:1).
  34. Legal is set to There are no potential legal consequences (QLG:1).

The final score is 5.0 (signature: [YFVS 0.4]YCE:1/YDC:1/YID:1/YAI:9/YCB:1/ECN:10/EAT:5/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:1/SPV:5/SLG:7/PIA:10/POB:5/PDS:10/POE:10/PRR:10/PTR:10/MCN:5/MIC:0/MAT:4/MAV:-3/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:1/QPH:1/QIL:1/QFB:1/QLG:1), with the main influence downward being due to the fact that the system is considered non-essential in its current role.

Scoring Walkthrough 5: Vulnerability Chain/Tree — Use of Sequential Object Identifiers, Missing Authorization Check

This is one of my favourite combination vulnerabilities, because even in 2014, I still run into it fairly frequently.

The first flaw is the use of sequential object identifiers (e.g. the first user/document/item to be created in a system is ID 1, the second is ID 2, and so on). In other words, if I look in a URL (or POST parameters, or network traffic for non-HTTP protocols, etc.) and see something like userID=7873, I will immediately want to know what happens if I change it to userID=7872, userID=7874, etc.

The second is that some tier of the application is missing an authorization check that would make sure I actually have permission to the object I'm requesting information about. I typically see this in REST/SOAP APIs, because a lot of developers don't consider that I can bypass their official client entirely when connecting to their network-accessible API.

An alternate variation on the second flaw is where the authorization check is performed using a trivial value, and there is no rate-limiting on the number of attempts made. For example, a very badly-written banking application might allow me to add credit cards to my account by specifying the card number and three-digit CVV2 code, without limiting how many requests I can send. In this case, if my card number is 4444111122223333, I can pick the next valid card number (4444111122223341), and simply step through all 1000 possible CVV2 values.

Consider the first variation. As a hypothetical scenario, suppose that by stepping through sequential "title IDs", I can discovered hidden rare-book inventory in a library, and bypass the normal authorization checks that would prevent that title from being checked out to me.

  1. Code/Command/Function Execution is set to No additional code/command/function execution (YCE:1).
  2. Control Over Configuration/Data is set to No additional control over configuration/data (YDC:1).
  3. Information Disclosure is set to Some of the information stored within or transmitted by the system (other than non-credential system configuration/state) which is not accessible in the absence of the vulnerability is made available (system-level access control has been partially bypassed) (YID:7).
  4. Impact To Availability / Denial of Service Capability is set to No additional impact to availability (YAI:1).
  5. Other Security Control Bypass / Business Logic Flaws is set to One or more security controls or intended business-logic rules within the vulnerable system are completely bypassed (a business-logic flaw allows any product in an online catalogue to be purchased at a price set by the attacker, an authorization flaw allows any user to read files belonging to any other user, a lack of rate-limiting combined with use of sequential card numbers allows an attacker to determine valid gift card numbers belonging to other customers, etc.) (YCB:9), because the attacker can check out any title in the system.
  6. Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. Authentication is set to Single-factor authentication (EAT:5).
  8. Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. User Interaction is set to No (EUI:10).
  10. Vulnerability Instance Recognition is set to Some element of the system displays information that uniquely identifies it as being of the same "lineage" as the version/model which contains the vulnerability (e.g. an HTTP header indicates that the server is "Apache Tomcat", but does not include a version number), but the only way to remotely determine if the system is actually vulnerable is to actively attempt to exploit it (EVR:10), as the software identifies itself to users, but does not include a specific version number.
  11. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. User Visibility is set to Exploiting the vulnerability causes the system to behave in a way that indicates to users that something has changed, but does not conclusively indicate exploitation (a new entry is added to a list, but it does not appear out-of-place, a machine name in an RSS feed URL has changed, but the RSS feed renders correctly, etc.) (SUV:5) — an attentive librarian may notice that a rare title shows as "checked out".
  13. Programmatic Visibility is set to Exploiting the vulnerability does not cause any effects which are out of the ordinary for the vulnerable system (A business-logic flaw results in predictable valid gift card numbers, a facial-recognition system is vulnerable to spoofing by photo, etc.) (SPV:10).
  14. Logging is set to Exploiting (or attempting to exploit) the vulnerability inherently causes log entries to be written which unambiguously indicate the date and time that an attempt was made (the vulnerable system generates an alert that a request was received to update a "canary" value in its database, etc.) (SLG:1), because the system logs check-in/check-out of titles.
  15. System Information Accessibility is set to The vulnerable system is completely proprietary and known only to members of the organization where it is used (PIA:1).
  16. Obviousness is set to The vulnerability can be discovered by examining human-readable artifacts related to an instance/installation of the system (e.g. JSP/HTML files, WAR files and other standard archive formats, scripts, source code if source code is publicly available, instruction manuals) (POB:5).
  17. Disclosure is set to The vulnerability has not been publicly disclosed (yet) (PDS:1).
  18. Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10).
  19. Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10). The base score is now 7.4 (signature: [YFVS 0.4]YCE:1/YDC:1/YID:7/YAI:1/YCB:9/ECN:10/EAT:5/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:5/SPV:10/SLG:1/PIA:1/POB:5/PDS:1/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U).
  21. Connectivity/Accessibility is set to The vulnerable system instance is remotely-accessible to the public (e.g. the internet) (MCN:10).
  22. Instance Context is set to No modification to context (MIC:0).
  23. Authentication is set to No change (MAT:0).
  24. Availability is set to No change (MAV:0).
  25. Workarounds is set to No change (MWA:0).
  26. Detection is set to No external component will detect attempts to exploit the vulnerable system instance (MDT:10).
  27. Manual Response is set to No manual response has been defined (MMR:6).
  28. Automated Response is set to No automated response has been configured (MAR:0).
  29. Forensic Traceability is set to No change to forensic/logging information considerations (MFT:0).
  30. Further Compromise is set to The vulnerability does not compromise any other systems (QFC:1).
  31. Physical is set to No physical consequences (QPH:1).
  32. Information Leakage is set to Successful exploitation does not result in leakage of information (QIL:1).
  33. Financial/Business is set to Successful exploitation can directly result in financial or business consequences, but the organization responsible for the system will continue to operate (QFB:5).
  34. Legal is set to There are no potential legal consequences (QLG:1).

The score for this first scenario is 7.6 (signature: [YFVS 0.4]YCE:1/YDC:1/YID:7/YAI:1/YCB:9/ECN:10/EAT:5/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:5/SPV:10/SLG:1/PIA:1/POB:5/PDS:1/POE:10/PRR:10/PTR:10/MCN:10/MIC:0/MAT:0/MAV:0/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:1/QPH:1/QIL:1/QFB:5/QLG:1), reflecting the relative severity of the system not correctly performing some of its core functionality.

Modify the score values to see how the second scenario (an ability to obtain valid credit card numbers belonging to other people) affects the overall score. Assume that nothing has changed except the type of data revealed.

  1. Information Disclosure is set to The vulnerability provides access to information beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system), OR access to valid credentials of any kind OR access to information whose disclosure in a real-world attack would lead to external regulatory action or other externally-imposed penalties (YID:10), because a successful exploitation will disclose credit card details.
  2. Reproducibility is set to The exploit succeeds at least 1 time in 1,000 (ERP:3).
  3. Information Leakage is set to Successful exploitation results in exposure (outside the control of the responsible organization) of data the organization has classified as the highest sensitivity - for example, when using NIST data classification, the sensitivity of the data would be 'High' (QIL:10).
  4. Legal is set to Successful exploitation can directly result in legal proceedings other than those listed below (e.g. a civil lawsuit) against at least one member of the organization responsible for the system, or the organization itself (QLG:7).

The final score is 8.4 (signature: [YFVS 0.4]YCE:1/YDC:1/YID:10/YAI:1/YCB:9/ECN:10/EAT:5/EAZ:10/EUI:10/EVR:4/ERP:3/SUV:5/SPV:10/SLG:1/PIA:1/POB:5/PDS:1/POE:10/PRR:10/PTR:10/MCN:10/MIC:0/MAT:0/MAV:0/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:1/QPH:1/QIL:10/QFB:5/QLG:7).

Scoring Walkthrough 6: Vendor A Vulnerability Chain/Tree

This combination of vulnerabilities was discovered in a real-world penetration test of a commercial product. Like the other examples below, "the serial numbers have been filed off" of the details in order to avoid disclosing some totally awesome zero-days that everyone would agree are "1337" and "epic".

The individual vulnerabilities were:

  1. One of the web application interfaces to the product was accessible without authentication. This web application was actually obsolete, unused, and non-functional — it appeared to be an artifact from a much older version of the product which the current installer still put on the system because no one had removed it from the install package.
  2. That same web application included an undocumented configuration backup/restore feature which used zip-compressed XML files (discovered by unpacking the installer and examining the JSP file source code). The restore feature did not perform input validation on filenames within the zip file, and so was vulnerable to directory traversal (e.g. a malicious zip file created by hand using a hex editor or something like EvilArc).
  3. The instance of Tomcat hosting the vulnerable web application was run in the context of a superuser account on the host. To introduce some variation into the scoring steps, we'll pretend that this was not the default configuration.

The combination of these three vulnerabilities allowed unauthenticated remote code-execution as a local superuser:

  1. Create a JSP-encoded Meterpreter or obtain a JSP web shell.
  2. Create a malicious zip file which contained that JSP Meterpreter/web shell payload, with the filename using the directory traversal vulnerability to escape from the temporary directory where zip files were unpacked and writing the payload into a location where it would be accessible to the client web browser (e.g. ../../../webapps/ROOT/meterpreter.jsp).
  3. Access the JSP file from a client web browser.
  4. If using Meterpreter, wait for the connection back to Metasploit. Otherwise, execute commands via the JSP web shell.
  5. Do whatever you want!

Scoring this set as a "tree" or "chain" of vulnerabilities:

  1. Code/Command/Function Execution is set to Beyond the scope of the vulnerable system (e.g. a webserver vulnerability allows arbitrary shell commands to be executed on the host OS) (YCE:10).
  2. Control Over Configuration/Data is set to Configuration or data stored beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system) can be modified (YDC:10).
  3. Information Disclosure is set to The vulnerability provides access to information beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system), OR access to valid credentials of any kind OR access to information whose disclosure in a real-world attack would lead to external regulatory action or other externally-imposed penalties (YID:10).
  4. Impact To Availability / Denial of Service Capability is set to Exploiting the vulnerability can result in a complete outage of one or more systems beyond the scope of the vulnerable system, or exploiting the vulnerability can result in an outage which requires physical repair (YAI:10).
  5. Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. Authentication is set to No authentication / anonymous access (EAT:10).
  8. Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. User Interaction is set to No (EUI:10).
  10. Vulnerability Instance Recognition is set to It is possible to accurately identify the system as being vulnerable, and doing so does not require authenticating to the system or attempting to exploit the vulnerability (e.g. a section of the vulnerable system which is accessible to unauthenticated users displays a full version number, or all versions of the product are vulnerable) (EVR:10), because several of the web applications that comprised the deployment displayed full version numbers to unauthenticated users.
  11. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. User Visibility is set to Exploiting the vulnerability does not cause any changes to the application that can be detected by users interacting with the system using the standard interface(s) of the system itself. (SUV:10).
  13. Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect which unambiguously indicates that exploitation has taken place (a 512-byte value unique to the exploit appears in network traffic, etc.) (SPV:1) — if nothing else, due to the presence of directory traversal characters in the network traffic.
  14. Logging is set to Exploiting (or attempting to exploit) the vulnerability inherently causes log entries to be written which indicate the date and time of activity which is unusual, but not necessarily an exploit attempt (a search indexer receives several hundred document submissions in the space of a minute, etc.) (SLG:5), as Tomcat would log requests to pages that are not normally used, but which are not inherently malicious in nature.
  15. System Information Accessibility is set to The vulnerable system is available to the public, is available in multiple countries, or is used by more than twenty-five distinct organizations (PIA:10).
  16. Obviousness is set to The vulnerability can be discovered by examining human-readable artifacts related to an instance/installation of the system (e.g. JSP/HTML files, WAR files and other standard archive formats, scripts, source code if source code is publicly available, instruction manuals) (POB:5).
  17. Disclosure is set to The vulnerability has not been publicly disclosed (yet) (PDS:1).
  18. Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10), because the attack uses existing tools (e.g. Metasploit and EvilArc).
  19. Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10). The base score is now (signature: ).
  21. Connectivity/Accessibility is set to The vulnerable system instance is remotely-accessible from systems that exclusively perform unrelated functions within the same organization (MCN:5).
  22. Instance Context is set to The target is configured in a way that results in a successful exploitation being executed in the context of a superuser/administrative account, when the base vulnerability does not already allow this (MIC:6).
  23. Authentication is set to No change (MAT:0).
  24. Availability is set to The responsible organization considers performance/availability issues for the vulnerable system instance to be of higher than usual severity, but still tolerable (MAV:3).
  25. Workarounds is set to No change (MWA:0).
  26. Detection is set to No external component will detect attempts to exploit the vulnerable system instance (MDT:10).
  27. Manual Response is set to No manual response has been defined (MMR:6).
  28. Automated Response is set to No automated response has been configured (MAR:0).
  29. Forensic Traceability is set to No change to forensic/logging information considerations (MFT:0).
  30. Further Compromise is set to Successful exploitation will directly result in a compromise of one or more other systems which are not directly related to the function of the original system (the vulnerability provides the attacker with a superuser account which is valid on one or more unrelated systems) (QFC:10), because the local superuser on the vulnerable server was also a superuser on the other servers in-scope for the test.
  31. Physical is set to No physical consequences (QPH:1).
  32. Information Leakage is set to Successful exploitation results in exposure (outside the control of the responsible organization) of data the organization has classified in-between the lowest and highest sensitivity ratings - for example, when using NIST data classification, the sensitivity of the data would be 'Medium' (QIL:6).
  33. Financial/Business is set to There are no potential financial consequences to successful exploitation (QFB:1).
  34. Legal is set to There are no potential legal consequences (QLG:1).

Final score: 9.0 (signature: [YFVS 0.4]YCE:10/YDC:10/YID:10/YAI:10/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:10/ERP:10/SUV:10/SPV:1/SLG:5/PIA:10/POB:5/PDS:1/POE:10/PRR:10/PTR:10/MCN:5/MIC:6/MAT:0/MAV:3/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:10/QPH:1/QIL:6/QFB:1/QLG:1).

Scoring Walkthrough 7: Vendor B Vulnerability Chain/Tree

Another anonymized, previously-undisclosed real-world vulnerability I discovered during a pen-test. This application used a proprietary protocol running over TCP.

The individual vulnerabilities were:

  1. Server/agent communication performed over an insecure channel (unencrypted and unsigned) — among other things, this allowed the commands being sent to managed systems to be modified (or forged entirely using modified/replayed requests).
  2. Insecure storage of credentials — the commands included the user ID and password under which they should be executed. The password was reversibly encrypted using a key hardcoded into the product.
  3. Missing authentication check. The reversibly-encrypted password was not actually used — the receiving system was executing in the context of a superuser account, and would simply impersonate whichever user ID was specified in the message without verifying that the password was valid.

Combine these together, and the result was another case of unauthenticated remote code-execution as a local superuser. In a non-default configuration, the third vulnerability could be avoided, but the combination of the first and second would still allow commands to be executed as any account whose credentials had been observed in legitimate traffic.

  1. Code/Command/Function Execution is set to Beyond the scope of the vulnerable system (e.g. a webserver vulnerability allows arbitrary shell commands to be executed on the host OS) (YCE:10).
  2. Control Over Configuration/Data is set to Configuration or data stored beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system) can be modified (YDC:10).
  3. Information Disclosure is set to The vulnerability provides access to information beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system), OR access to valid credentials of any kind OR access to information whose disclosure in a real-world attack would lead to external regulatory action or other externally-imposed penalties (YID:10).
  4. Impact To Availability / Denial of Service Capability is set to Exploiting the vulnerability can result in a complete outage of one or more systems beyond the scope of the vulnerable system, or exploiting the vulnerability can result in an outage which requires physical repair (YAI:10).
  5. Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. Authentication is set to No authentication / anonymous access (EAT:10).
  8. Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. User Interaction is set to No (EUI:10).
  10. Vulnerability Instance Recognition is set to Some element of the system displays information that uniquely identifies it as being of the same "lineage" as the version/model which contains the vulnerability (e.g. an HTTP header indicates that the server is "Apache Tomcat", but does not include a version number), but the only way to remotely determine if the system is actually vulnerable is to actively attempt to exploit it (EVR:4).
  11. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. User Visibility is set to Exploiting the vulnerability does not cause any changes to the application that can be detected by users interacting with the system using the standard interface(s) of the system itself. (SUV:10).
  13. Programmatic Visibility is set to Exploiting the vulnerability does not cause any effects which are out of the ordinary for the vulnerable system (A business-logic flaw results in predictable valid gift card numbers, a facial-recognition system is vulnerable to spoofing by photo, etc.) (SPV:10), because the exploit traffic only had modified command strings.
  14. Logging is set to Exploiting (or attempting to exploit) the vulnerability inherently causes log entries to be written which indicate the date and time of activity which is unusual, but not necessarily an exploit attempt (a search indexer receives several hundred document submissions in the space of a minute, etc.) (SLG:5), as the system might log somewhat-unusual data when exploited.
  15. System Information Accessibility is set to The vulnerable system is available to the public, is available in multiple countries, or is used by more than twenty-five distinct organizations (PIA:10).
  16. Obviousness is set to The vulnerability can be discovered by examining artifacts of an instance/installation which are converted to human-readable format using tools available to the public (e.g. decompiled/disassembled code) (POB:3), as the flawed encryption required the use of OllyDbg to understand. The other information was obtained from network captures, so if the encryption vulnerability were split out of this group, the Obviousness score would jump to 7.
  17. Disclosure is set to The vulnerability has not been publicly disclosed (yet) (PDS:1).
  18. Effort to Obtain Exploit is set to Exploit code is not publicly available (POE:1) — I wrote a custom Metasploit module to exploit it due to the complexity of trying to do so manually, but the module was not released.
  19. Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10). The base score is now 8.8 (signature: [YFVS 0.4]YCE:10/YDC:10/YID:10/YAI:10/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:10/SPV:10/SLG:5/PIA:10/POB:3/PDS:1/POE:1/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U).
  21. Connectivity/Accessibility is set to The vulnerable system instance is remotely-accessible from systems that exclusively perform unrelated functions within the same organization (MCN:5).
  22. Instance Context is set to No modification to context (MIC:0).
  23. Authentication is set to No change (MAT:0).
  24. Availability is set to The responsible organization considers performance/availability issues for the vulnerable system instance to be of higher than usual severity, but still tolerable (MAV:3).
  25. Workarounds is set to No change (MWA:0).
  26. Detection is set to No external component will detect attempts to exploit the vulnerable system instance (MDT:10).
  27. Manual Response is set to No manual response has been defined (MMR:6).
  28. Automated Response is set to No automated response has been configured (MAR:0).
  29. Forensic Traceability is set to No change to forensic/logging information considerations (MFT:0).
  30. Further Compromise is set to Successful exploitation will directly result in a compromise of one or more other systems which are not directly related to the function of the original system (the vulnerability provides the attacker with a superuser account which is valid on one or more unrelated systems) (QFC:10), for similar reasons to the previous chain/tree.
  31. Physical is set to No physical consequences (QPH:1).
  32. Information Leakage is set to Successful exploitation results in exposure (outside the control of the responsible organization) of data the organization has classified as the highest sensitivity - for example, when using NIST data classification, the sensitivity of the data would be 'High' (QIL:10), because the encryption vulnerability allows passwords to be obtained.
  33. Financial/Business is set to There are no potential financial consequences to successful exploitation (QFB:1).
  34. Legal is set to There are no potential legal consequences (QLG:1).

Final score: 8.7 (signature: [YFVS 0.4]YCE:10/YDC:10/YID:10/YAI:10/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:4/ERP:10/SUV:10/SPV:10/SLG:5/PIA:10/POB:3/PDS:1/POE:1/PRR:10/PTR:10/MCN:5/MIC:0/MAT:0/MAV:3/MWA:0/MDT:10/MMR:6/MAR:0/MFT:0/QFC:10/QPH:1/QIL:10/QFB:1/QLG:1).

Scoring Walkthrough 8: Vendor C Vulnerability Chain/Tree

This chain/tree involved a combination of publicly-disclosed and previously-undisclosed individual vulnerabilities in a third commercial product which was built on top of numerous open-source packages:

  1. The administrative interface of a web application was accessible without authentication.
  2. The web application was vulnerable to a publicly-disclosed local/remote file-inclusion vulnerability which also allowed directory enumeration.
  3. A world-readable text file on the host contained in plaintext the password for a superuser account in the PostgreSQL instance running on the same host.

As you may have guessed, this group of flaws led to another remote code-execution vulnerability (via SQLMap's ability to execute OS-level commands through Postgres), although in this case it was "only" as the Postgres account as opposed to a local superuser.

  1. Code/Command/Function Execution is set to Beyond the scope of the vulnerable system (e.g. a webserver vulnerability allows arbitrary shell commands to be executed on the host OS) (YCE:10).
  2. Control Over Configuration/Data is set to Configuration or data stored beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system) can be modified (YDC:10).
  3. Information Disclosure is set to The vulnerability provides access to information beyond the scope of the vulnerable system (which is not normally accessible via the vulnerable system), OR access to valid credentials of any kind OR access to information whose disclosure in a real-world attack would lead to external regulatory action or other externally-imposed penalties (YID:10).
  4. Impact To Availability / Denial of Service Capability is set to Exploiting the vulnerability can result in a complete outage of the vulnerable system which will persist until the system owner/administrator (or appropriate external automation) takes some action (YAI:9), because the account in question (in the absence of other vulnerabilities) could only shut down Postgres, not the entire server.
  5. Other Security Control Bypass / Business Logic Flaws is set to No additional security controls are bypassed (YCB:1).
  6. Connectivity is set to The vulnerability can be exploited remotely from any system that can make a connection to the target (or to which the target can connect, in the case of reflected/indirect exploits) (ECN:10).
  7. Authentication is set to No authentication / anonymous access (EAT:10).
  8. Authorization is set to Default privileges/no privileges/no authentication (EAZ:10).
  9. User Interaction is set to No (EUI:10).
  10. Vulnerability Instance Recognition is set to It is possible to accurately identify the system as being vulnerable, and doing so does not require authenticating to the system or attempting to exploit the vulnerability (e.g. a section of the vulnerable system which is accessible to unauthenticated users displays a full version number, or all versions of the product are vulnerable) (EVR:10) — full version numbers were visible without authentication in several components of the system.
  11. Reproducibility is set to The exploit succeeds in at least 90% of attempts (ERP:10).
  12. User Visibility is set to Exploiting the vulnerability does not cause any changes to the application that can be detected by users interacting with the system using the standard interface(s) of the system itself. (SUV:10).
  13. Programmatic Visibility is set to Exploiting the vulnerability causes a detectable effect which unambiguously indicates that exploitation has taken place (a 512-byte value unique to the exploit appears in network traffic, etc.) (SPV:1), because the file-inclusion vulnerability had a unique signature.
  14. Logging is set to Exploiting (or attempting to exploit) the vulnerability inherently causes log entries to be written which indicate the date and time of activity which is unusual, but not necessarily an exploit attempt (a search indexer receives several hundred document submissions in the space of a minute, etc.) (SLG:5), as the system might log somewhat-unusual data when exploited.
  15. System Information Accessibility is set to The vulnerable system is available to the public, is available in multiple countries, or is used by more than twenty-five distinct organizations (PIA:10).
  16. Obviousness is set to The vulnerability can be discovered by examining human-readable artifacts related to an instance/installation of the system (e.g. JSP/HTML files, WAR files and other standard archive formats, scripts, source code if source code is publicly available, instruction manuals) (POB:5).
  17. Disclosure is set to The vulnerability has not been publicly disclosed (yet) (PDS:1) — even though some of the elements are public, the overall vulnerability tree/chain is not.
  18. Effort to Obtain Exploit is set to Fully-functional exploit code is publicly available, or no exploit code is required (POE:10) — no tools beyond Burp Suite, Netcat, and Metasploit (using a generic Meterpreter instance) were required.
  19. Resources Required to Exploit is set to No resources, or non-specialized resources related to the field in which the system operates are required (PRR:10).
  20. Time Required to Exploit is set to The vulnerability can be successfully exploited in less than one minute (PTR:10). The base score is now 9.0 (signature: [YFVS 0.4]YCE:10/YDC:10/YID:10/YAI:9/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:10/ERP:10/SUV:10/SPV:1/SLG:5/PIA:10/POB:5/PDS:1/POE:10/PRR:10/PTR:10/MCN:U/MIC:U/MAT:U/MAV:U/MWA:U/MDT:U/MMR:U/MAR:U/MFT:U/QFC:U/QPH:U/QIL:U/QFB:U/QLG:U).
  21. Connectivity/Accessibility is set to The vulnerable system instance is remotely-accessible only from systems that perform related functions within the same organization (although those systems may perform other functions as well) (MCN:3), as the system was in a limited-access infrastructure network.
  22. Instance Context is set to No modification to context (MIC:0).
  23. Authentication is set to The vulnerable system instance requires multi-factor authentication to exploit the vulnerability, and none of the factors are compromised by the vulnerability itself (MAT:-2), because the restricted network could only be accessed using two-factor authentication.
  24. Availability is set to No change (MAV:0).
  25. Workarounds is set to No change (MWA:0).
  26. Detection is set to An external component will detect attempts to exploit the vulnerable system instance, but false-positives occur as well (MDT:5) — the restricted network included an IPS which should be able to detect and block this particular type of file-inclusion vulnerability.
  27. Manual Response is set to No manual response has been defined (MMR:6).
  28. Automated Response is set to One or more external components will automatically detect and block attempts to exploit the vulnerability, but there are false negatives (MAR:-1).
  29. Forensic Traceability is set to No change to forensic/logging information considerations (MFT:0).
  30. Further Compromise is set to Successful exploitation will not directly result in the compromise of another system, but it will provide connectivity to other systems which are not directly accessible via the avenue used to connect to the vulnerable system (e.g. the vulnerable target provides a foothold) (QFC:7), because a successful attacker would obtain a remote shell on the vulnerable server.
  31. Physical is set to No physical consequences (QPH:1).
  32. Information Leakage is set to Successful exploitation results in exposure (outside the control of the responsible organization) of data the organization has classified as the lowest sensitivity for internal information - for example, when using NIST data classification, the sensitivity of the data would be 'Low' (QIL:3), because the encryption vulnerability allows passwords to be obtained.
  33. Financial/Business is set to There are no potential financial consequences to successful exploitation (QFB:1).
  34. Legal is set to There are no potential legal consequences (QLG:1).

Final score: 8.6 (signature: [YFVS 0.4]YCE:10/YDC:10/YID:10/YAI:9/YCB:1/ECN:10/EAT:10/EAZ:10/EUI:10/EVR:10/ERP:10/SUV:10/SPV:1/SLG:5/PIA:10/POB:5/PDS:1/POE:10/PRR:10/PTR:10/MCN:3/MIC:0/MAT:-2/MAV:0/MWA:0/MDT:5/MMR:6/MAR:-1/MFT:0/QFC:7/QPH:1/QIL:3/QFB:U/QLG:U).

Bulk YFVS 0.4 Versus CVSS 2.0 Comparison Table

Here are a number of real-world findings that I scored with both YFVS 0.4 and CVSS 2.0. Hopefully most pen-testers will agree that the YFVS scores much more accurately reflect the severity of the flaws.

Vendor Anonymized Vulnerability Description YFVS 0.4 Score CVSS 2.0 Score YFVS 0.4 Signature CVSS 2.0 Signature
Vendor A Use of TLS/SSL not required or used by default for web application. 9.5 6.5 YFVS details for this vulnerability AV:N/AC:M/Au:N/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor A Web application users' credentials are hashed on the client side, sent in that form, and compared directly against hashes in the server-side database. [ Scored as a vulnerability in the event of access to the database ] 8.9 4.4 YFVS details for this vulnerability AV:N/AC:H/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor A Web application users' credentials are hashed on the client side, sent in that form, and compared directly against hashes in the server-side database. [ Scored in conjunction with the lack of TLS/SSL ] 9.4 6.5 YFVS details for this vulnerability AV:N/AC:M/Au:N/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor A Credential hashing is performed using unsalted MD5. [ Scored as a vulnerability in the event of access to the database ] 8.7 4.4 YFVS details for this vulnerability AV:N/AC:H/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor A A poorly-implemented maintenance interface allows unauthenticated remote code execution as the database administrator OS-level account. 9.1 7.1 YFVS details for this vulnerability AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor A Existing passwords for connectivity to several related devices are retrieved from the database and sent to web clients to pre-populate password form fields. 9.0 3.8 YFVS details for this vulnerability AV:N/AC:L/Au:S/C:P/I:N/A:N/E:F/RL:U/RC:ND
Vendor A Use of the web application requires that browser-level Data Execution Prevention be disabled in Internet Explorer due to use of a legacy plugin/ActiveX object. 8.8 4.3 YFVS details for this vulnerability AV:N/AC:H/Au:N/C:P/I:P/A:P/E:U/RL:U/RC:ND
Vendor A A world-readable backup file contains the complete contents of the /etc directory. 8.8 2.0 YFVS details for this vulnerability AV:L/AC:L/Au:N/C:P/I:N/A:N/E:F/RL:U/RC:C
Vendor B The application is vulnerable to unauthenticated remote code execution as root/LocalSystem. 8.7 6.8 YFVS details for this vulnerability AV:N/AC:H/Au:N/C:C/I:C/A:C/E:POC/RL:U/RC:C
Vendor B Sensitive data (including user and service account passwords) is encrypted using a hardcoded key which is identical for every installation of the product (worldwide). 8.9 3.3 YFVS details for this vulnerability AV:L/AC:H/Au:N/C:P/I:P/A:P/E:POC/RL:U/RC:C
Vendor B If an overly-long command string is sent to the software, it will crash. 4.6 5.5 YFVS details for this vulnerability AV:N/AC:H/Au:N/C:N/I:C/A:P/E:POC/RL:U/RC:C
Vendor B Network communication is performed over an unencrypted channel. 8.7 4.6 YFVS details for this vulnerability AV:N/AC:H/Au:N/C:P/I:P/A:P/E:POC/RL:U/RC:C
Vendor D Users' passwords are stored in the database in a proprietary, bizarre format which combines the worst parts of a poor hashing algorithm with the worst parts of a weak reversible encryption algorithm. 8.5 1.4 YFVS details for this vulnerability AV:L/AC:M/Au:S/C:P/I:N/A:N/E:POC/RL:U/RC:C
Vendor D Use of complex passwords is not enforced. 9.4 5.7 YFVS details for this vulnerability AV:N/AC:M/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor D At least two accounts exist with default/easily-guessed names and passwords which are identical to the username. 9.5 5.7 YFVS details for this vulnerability AV:N/AC:M/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:ND
Vendor D Session tokens for the web application are sent via a cookie without the HttpOnly or Secure flags set. 8.4 4.3 YFVS details for this vulnerability AV:N/AC:M/Au:N/C:P/I:N/A:N
Vendor D The application server has a legacy (non-TLS) FTP service enabled, and it authenticates against Active Directory. 9.7 5.8 YFVS details for this vulnerability AV:N/AC:M/Au:N/C:P/I:P/A:N/E:H/RL:U/RC:C
Vendor D The web application server directory which contains the JSP files for the application has directory-listing enabled for web clients. 3.7 5.0 YFVS details for this vulnerability AV:N/AC:L/Au:N/C:P/I:N/A:N/E:H/RL:U/RC:C
Vendor E TCP timestamp responses are enabled. 3.3 5.0 YFVS details for this vulnerability AV:N/AC:L/Au:N/C:P/I:N/A:N/E:H/RL:U/RC:C
Vendor F Default Apache Tomcat content is installed. 3.3 5.0 YFVS details for this vulnerability AV:N/AC:L/Au:N/C:P/I:N/A:N/E:H/RL:U/RC:C
Vendor G Password change page vulnerable to CSRF (proprietary application which does not allow admin access via the web interface). 8.5 5.5 YFVS details for this vulnerability AV:N/AC:M/Au:N/C:P/I:P/A:N/E:F/RL:U/RC:C
 
[ Page Icon ]