How Privileges Affect Third-Party Application Vulnerabilities: An Analysis Based on Public Vulnerability Disclosures

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:

1. How many vulnerabilities from each vendor can experience privilege escalation?
2. 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:

1. Exploitability: provides a measure of how complex the process is to exploit the vulnerability in a specific target system. This is vulnerability-specific.
2. 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.
3. 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.

What Analyzing Public Disclosures Reveals about Third-Party Privileged Vulnerabilities

Using the methodology described in the above section, we are able to analyze the details regarding the vulnerability, the quantity released per year per product, and the potential ramifications of privileged escalation and privileges required for exploitation by reviewing the public disclosure of vulnerabilities for a variety of third-party applications.

The following data was derived for leading vendors and their solutions from CVE’s issued in 2018:

• Oracle disclosed 733 vulnerabilities in 2018 across all of their solutions, regardless of platform. None of the vulnerabilities had public exploits nor allowed the elevation of privileges. However, 5 vulnerabilities allowed remote code execution in the context of the user executing the process. This is a very low percentage compared to other vendors and noteworthy as you continue to examine the data.
• Adobe, whose software has frequently been the target for exploitation, released 372 vulnerabilities in 2018. None of the vulnerabilities allowed the escalation of privileges, nor are public exploits reported for any of them. However, 169 of the published vulnerabilities allowed for remote code execution in the context of the operating user. This means 45% of the vulnerabilities identified by Adobe in 2018 could be exploited and allow foreign code to operate in the context of the user. If the user was operating as an administrator, it could be a “game over” incident.
• Google disclosed 786 vulnerabilities in 2018 across all of their solutions. While none of the vulnerabilities have public exploits, three did allow for privilege escalation attacks—all of which were in their Android product line. In addition, 102 of the vulnerabilities allowed for remote code execution, representing 13% of all vulnerabilities that could allow code to be executed in the context of the user.
• VMware disclosed only 21 vulnerabilities in 2018 across all their product lines. None of the vulnerabilities allowed for the escalation of privileges, but 6 did allow for code execution across a variety of server, workstation, and network products. This represents over 28% coverage for vulnerabilities that can be used to execute code inappropriately in the context of the user. If the user was using a desktop virtualization product, that remote code execution would be in the same context as the privileges assigned to that user.
• Cisco disclosed 424 vulnerabilities in 2018. 28 of the vulnerabilities allowed for the threat actor to gain privileges, and 153 allowed for code execution (6% and 36% respectively) across all of their products. These are some of the highest percentages for any vendor in 2018.

Now, consider this pivoted by products in 2018:

• Adobe Reader had a whopping 138 vulnerabilities across all platforms. 63 of the vulnerabilities allowed code execution--this highlights the critical need for removing end-user administrative rights to mitigate the remote code execution threats.
• Adobe Flash had 26 vulnerabilities across all platforms and widgets. 12 (46%) allowed for code execution.
• Google Chrome had 161 vulnerabilities across all platforms, 15 of which could be linked to code execution.
• Microsoft Internet Explorer had 75 vulnerabilities across all versions of Windows. While this article is primarily focused on third-party applications, some readers may consider IE optional based on their region of the world and build of the operating system. To that end, 54 (72%) vulnerabilities allowed for code execution, This alone demonstrates the dangers of this aging browser and the threats of using local administrative rights when surfing the web.
• Apple iTunes – Apple disclosed 43 vulnerabilities for iTunes across MacOS, Windows, iOS, and WatchOS. 32 of the vulnerabilities allowed for code execution. Based on simple math, 74% of the vulnerabilities could be a privileged attack vector for threat actors if Apple users are allowed to run with administrative rights on their preferred platforms.
• Generic Linux Kernel – 176 vulnerabilities were reported against the Linux Kernel. This is in contrast to 1,086 found for builds like Debian Linux, and 613 for Ubuntu Linux over the same time period. Of the 176 vulnerabilities, three allowed for code execution and three allowed for escalation of privileges. While none of these vulnerabilities were exploitable remotely, a standard user could potentially exploit the kernel to gain privileges. It is important to note the word, “potentially” because, as we have described, while none of these have yet resulted in public exploits, the complexity to develop an exploit is considered “low”.

While we could continue this analysis for dozens of other vendors and products, I think, by now, a at least three important points are clear:

1. Many vulnerabilities allow for remote code execution, but few allow for privileged elevation (which is fortunate).
2. Restricting the privileges of the operating user will limit the ability of remote code to operate on a remote target, if exploited.
3. The sheer fact that very few public exploits are available across the large numbers of vulnerabilities is of some comfort with regard to opportunistic threats. However, we shouldn’t discount the threat of nation-state targeted attacks, phishing attacks, and insider threats that could leverage the vulnerabilities using commercial penetration tools.

Enterprise application vulnerability disclosures validate the security best practices for removing administrative rights and enforcing least privilege on all end user systems to prevent exploitation and the prevention of remote code execution in the context as an administrator. And, as a security best practice, the true best line of defense based on these findings is to perform regular vulnerability assessments and timely security updates via patch management to eliminate these threats.

BeyondTrust is the only analyst-recognized leader in both privileged access management (PAM) and vulnerability management. We can help you seamlessly remove admin rights and enforce least privilege via our endpoint privilege management solution, and discover, prioritize, and eliminate vulnerabilities via our enterprise vulnerability management solution Want to learn more? Contact us today.

Related Reading

Microsoft Vulnerabilities Report 2019 (research report)

What Public Disclosures are Revealing about Cyber War Threats (blog)

Privileged Access Threat Report Highlights Cyber Risks & Strategies for Addressing External/Insider Threats, Vendor Access, & IoT (blog + research report)