The annual BeyondTrust Microsoft Vulnerabilities Report has become the industry standard for determining which threats can be mitigated simply via the reduction in administrative privileges. This year’s edition found that 81% of the published Microsoft vulnerabilities in 2018 can be mitigated just by removing local administrative rights from end users, which is a fundamental security best practice.
While the report shines the light directly on the powerful risk-reduction power of enforcing least privilege on endpoints that interact with Microsoft products, of course, few organizations live exclusively within a Windows ecosystem or rely exclusively on Microsoft solutions. So, just how effective are standard user rights for protecting against vulnerabilities within other common enterprise applications? This blog intends to answer that question.
While public vulnerability disclosure for other vendors is generally not as granular as that provided by Microsoft, we can still address at least two significant questions:
- How many vulnerabilities from each vendor can experience privilege escalation?
- What privileges are required for successful exploitation?
In other words, out of the total vulnerabilities released for 2018, which ones can be exploited to change their runtime privileges from a standard user to an administrative (or root account) and which ones need administrative rights to be exploitable in the first place? Let’s delve into this a bit further. If the user is operating the software as a standard user, could it lead to a privileged escalation attack? This potentially provides the cyber threat actor with privileged lateral movement, the opportunity to install malware, run code or ransomware, exfiltrate data, perform subversive command and control activities, or participate in other advanced persistent threats associated with running as a local administrator. Therefore, if the user is a standard user, the vulnerability “may” be only exploited in the context of the current user and the risk of privileged escalation is limited strictly based on the vulnerability characteristics itself.
Methods for Privileged Vulnerability Analysis
While some readers may consider the type of analysis I performed above voodoo, there are actually very good standards for determining and classifying these risks based on a vulnerability. First, it starts with public disclosure and providing a CVE for reference.
The Common Vulnerabilities and Exposures (CVE) program was launched in 1999 by MITRE, a nonprofit sponsored by the federal government, to identify and catalog vulnerabilities in software (applications and operating systems) and firmware. The mission was to provide organizations with a framework to improve their security by applying a standardized method to communicate vulnerability details between vendors, products, security tools, and end users. The word “Common” is the most important portion of the CVE standard. It informs you that, fundamentally, every tool, article, and solution is discussing the same underlying vulnerability in the same way.
Next, please give consideration to the Common Vulnerability Scoring System (CVSS); a vulnerability risk score per CVE. The CVSS provides a vendor-agnostic, open scoring standard to model vulnerability severity, and provides guidance on prioritization of remediation efforts. The basic metrics provided by CVSS allow for rating a vulnerability based on the severity of its components, such as Access Vector, Access Complexity, Authentication Method, Exploitation, Privileges Required, etc.
Within the Base scoring of CVSS are the Temporal Metrics. These represent three time-dependent descriptors for the vulnerability. They are:
- Exploitability: provides a measure of how complex the process is to exploit the vulnerability in a specific target system. This is vulnerability-specific.
- Remediation Level: provides a measurable level of an available solution. This can encompass everything ranging from an official security fix, to no solution or patch is available.
- Report Confidence: measures the confidence in the existence of the vulnerability, as well as the credibility of its existence.
The Exploitability metric (#1 above) is important for this discussion since it provides guidance using the following four criteria:
- Unproven: No exploit code is yet available (time-dependent).
- Proof of Concept: Proof of concept exploit code is available at the time of scoring.
- Functional: Functional exploit code is available.
- High: Exploitable by functional mobile autonomous code, or no exploit required and can be a manual trigger.
Next, we need to consider Privileges Required. This metric describes the level of privileges a threat actor must operate for successful exploitation of the vulnerability. Vulnerabilities that can be exploited without any privileges represent the highest threat. Vulnerabilities with no privileges required are the kind that scare everyone and, in the worst cases, are associated with wormable malware like WannaCry, NotPetya, and BlueKeep. Here are the levels of Privileges Required:
- None - The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack
- Low - The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user Alternatively, an attacker with Low privileges may have the ability to only impact non-sensitive resources
- High - The attacker is authorized with (i.e. requires) privileges that provide significant control (e.g. administrative) over the vulnerable component that could affect component-wide settings and files.* [Reference: Common Vulnerability Scoring System v3.0 Specification Document]
Based on the Exploitabililty and Privileges Required metrics, a vulnerability can be graded based on the possibility of exploitation and, most importantly, what privileges are needed for successful exploitation. When linked to a CVE, we have a quantifiable number of vulnerabilities per product and vendor that can pose a risk to an organization.