Identifying and Mitigating the PwnKit Vulnerability

While it may seem like the right course of action is to stop everything and immediately start patching the recent PwnKit vulnerability, this probably couldn’t be farther from the truth. Identifying the PwnKit vulnerability across enterprise assets, whether exposed to the internet or within the internal infrastructure, is critical. However, this marks the 3rd critical vulnerability identified in the past ~6 months, alongside Log4Shell and PrintNightmare, not to mention recent MS-Exchange zero-days, and even the 5-year-old EternalBlue exploit ( one of the top 30 exploitable vulnerabilities) still prevails despite our best efforts.

Another day, another vulnerability, another exploit, another… patch.

Polkit and its possible impact

The memory-corruption vulnerability in polkit (pkexec) has existed since its creation in May 2009 and is installed by default on all major Linux distributions. The pkexec program is very powerful, described as “the sudo of systemd” by Debian developers, and is capable of controlling system-wide privileges in Unix-like operating systems. It can be altered to allow an unprivileged local user to exploit and gain full root privileges of the host. Although PwnKit is technically a memory corruption, it is instantly exploitable in an architecture-independent way even if the polkit daemon itself is not running.

Keep calm and test along

Red Hat rates PwnKit (CVE-2021-4034) as having a Common Vulnerability Scoring System (CVSS) score of 7.8 (High). But what does that mean? Should it be prioritized over other high/critical vulnerabilities? Or perhaps not, as it hasn’t reached a CVSS criticality of 10.0?

The vulnerability-centric approach suggested by the CVSS  lacks meaningful risk prioritization and actionable context. This time, before immediately shifting patching priorities, security teams should stop to first discover the impact PwnKit has on the business in the event that it’s exploited, in the context of all other vulnerabilities that exist across the attack surface. 

Same same but different

Is PwnKit different from other Local Privilege Escalation (LPE – TA0004) exploitable vulnerabilities? Yes and no. 

A typical LPE is part of a chain of events across the attack kill-chain and not a standalone action that an adversary can “simply” exploit. Therefore, local user credentials are required. However, in a layered defense approach, we assume that what one security control missed, another control will prevent or at least detect.

PwnKit poses the biggest risk to environments that rely heavily on Linux permissions, where permissions differ across accounts. However, even in this case, context matters. 

Critical points to consider include:

• Asset criticality – The more critical the host is to the data or business continuity, the smaller the patching window. In addition, organizations are less inclined to deploy a memory or CPU-draining control due to the risk of business disruption.
• Endpoint controls – The Linux operating system prevention and detection coverage (EDR, NGAV, EPP) is limited. A large number of Linux kernel distributions limits vendors from developing a Windows OS-like parity and is therefore less mature. Ultimately, you can’t be dependent on multiple layers of controls to provide a defense-in-depth framework.
• Cloud assets – Linux has become the de facto standard for critical workloads in data centers and cloud computing environments. This makes the risk of Linux vulnerabilities a high-priority for organizations with a substantial cloud-deployed infrastructure – regardless of whether assets are publicly exposed or “behind the cloud perimeter.”

Where does PwnKit affect me and how can Pentera help?

Clearly, finding the vulnerabilities that exist across the enterprise is far from the end goal. It’s merely one important step along the way. In order to truly evaluate the possible risk and impact of the PwnKit vulnerability, Pentera can help you achieve the following:

Discover PwnKit across your exploitable attack surface

A complete asset discovery across the entire attack surface, which spans externally-exposed assets and distributed internal workloads, is a critical first step. Once the total attack surface has been mapped, vulnerabilities and misconfigurations are delineated to further identify the exploitable attack surface and progress the security validation process.

Safely exploit and validate your security readiness

A key indicator of exposure severity is whether an exploit has been proven and made publicly available. In this case, PwnKit was confirmed to be easily exploitable with active POCs across the web. Thus, emulating an end-to-end attack operation is an important step that provides the necessary context to prioritized remediation. Attack emulation should include external asset recon and exposure exploitation, all the way to lateral expansion and proven possible impact. This is as true for PwnKit as it is for any static or dynamic vulnerability.

With Pentera, either Black Box or Gray Box testing is available to emulate the impact of compromised local user credentials – either leaked or sniffed over the wire – leveraging the PwnKit exploitation as a chained event. The Pentera Attack Orchestrator™ privilege-escalation framework automatically takes advantage of credentials obtained or cracked and attempts to elevate privileges and progress the attack.

Prioritize remediation based on proven impact

When the security validation process is completed, security teams are handed a detailed attack map showing the possible paths adversaries may use, with each path directly correlated to its root cause and respective impact. With the full picture of potential impact and risk, surgical remediation can take place.

Hopefully, the PwnKit vulnerability will be the turning point where security teams stop the vulnerability-centric approach that results in patch whack-a-mole and shift toward focusing on evaluating and validating true risk.

For Pentera customers – please see more information available here.

Want to discover your exploitable attack surface? Get a free attack surface assessment today

Resources

• Qualys, who first discovered the PwnKit vulnerability, research blog: Local Privilege Escalation Vulnerability Discovered in polkit’s pkexec (CVE-2021-4034)
• MITRE registry on CVE-2021-4034
• NIST National Vulnerability Database registry on CVE-2021-4034
• Major Linux distributions have made patches available, including Debian, Ubuntu and Red Hat