How to avoid getting “carpet-bombed” by Polkit Exec, Log4jShell and Kubernetes Container Escape?
· The Linux Policy Kit exploit CVE 2022–4034
· How is this related to microservices and Log4Shell?
· The recent Kubernetes vulnerability (CVE-2022–0185)
· Combining these exploits to gain access
· Using “Strong” Kontainers to prevent getting “carpet-bombed”
The recently discovered Linux Policy exploit CVE 2022–4034 by Qualys unearthed a 13-year old vulnerability in a Linux system tool called Polkit that gives unfettered root privileges on machines running most major distributions of Linux.
PolicyKit manages system-wide privileges in Linux, by providing a mechanism for non-privileged processes to safely interact with privileged processes, and allow users to safely execute commands with high privileges by using a component called “pkexec”. “pkexec” has been in use since 2009.
“pkexec” contains a memory-corruption vulnerability that allows users with limited control to escalate privileges all the way to root. This is demonstrated below in the short sequence below.
As seen above, the exploit was able to very quickly gain access to the root privileges in the system. This exploit works on all major Linux distros and their respective versions of Linux.
How is this related to microservices and Log4Shell?
If you recall from the video below, an attacker using the Log4Shell (CVE-2021–44228) exploit vector, can gain control of the microservice host through a sophisticated series of actions that target enterprise APIs as recounted in the video below.
More details at:
As reports continue to mount regarding the exploitability of Log4Shell, the possibilities for malicious activity seem exponential. Nefarious parties can execute code on the attacked system, for example, to access sensitive configuration data. In capturing this data, attackers could gain full control of a system — and all its data and applications. This is like a burglar who has keys to the front door and the combination to the safe inside.
Very likely, this exposes microservices running on millions of servers, Kubernetes nodes, VMs, desktops, IOT devices etc. both in cloud and on-premise.
And, a massive number of the microservices/containers in Enterprise and Cloud are possibly running Java Microservices with the Log4jShell vulnerability.
The recent Kubernetes vulnerability (CVE-2022–0185)
Along with these 2 exploits, there was another one based on Kubernetes in early January:
- CVE-2022–0185, which enables attackers to escape containers and get full control over the node,
Container orchestrators like Kubernetes heavily rely on namespace isolation to separate pods from each other on the node operating system. In addition, some of the pods or namespaces even on hosts outside the context of Kubernetes will always have CAP_SYS_ADMIN privileges.
Hence if these pods are not protected by Seccomp or AppArmor profile, there is a good chance even a novice attacker will be able to get CAP_SYS_ADMIN privileges using unshare system call as discussed earlier or by any other means (e.g., by compromising privileged pods).
Once such privileges are gained, this vulnerability can be exploited with relative ease. The POC was posted by researchers on twitter to show that reliable exploitation is possible on any vulnerable Kernel i.e. 5.1-rc1 and above with high probability of success.
More details are given here in the Crowdstrike article.
Combining these exploits/Attack Vectors to gain access
Hackers and Botnets are increasingly starting to use multiple attack vectors to attack the enterprise. In this API-first and microservices world, and with the recent onslaught of vulnerabilities, and the sophistication by which hackers are attacking the enterprise with Botnets and AI-controlled hacks that probe the Enterprise APIs and microservices for weaknesses, a group can gain take over and gain sensitive access to data or even worse, take over the whole enterprise network, effectively planting more and more exploits to eventually have access to all sensitive systems and information in an enterprise.
An illustration of an attack progressing in this direction is shown below:
Using “Strong” Kontainers to prevent getting “carpet-bombed”
A carpet bombing attack is described as “large area bombardment done in a progressive manner to inflict damage in every part of a selected area of land”.
The use of multiple attack vectors can lead to exactly such a scenario in an enterprise if your infrastructure uses “weak” Linux containers. An exploit using Log4jShell, and then using the Kubernetes Escape exploit or other Linux Namespace exploit or using any of the facilities afforded within the massive attack radius presented by the “Weak” container, and then applying the polkit pkexec vulnerability completely offers the attacker total control over the physical worker node.
Doing this simultaneously to multiple microservices over the network can effectively leads to a “carpet-bombing” exploit attack which can compromise several systems at the same time, and then “spread” to other systems.
Using “Strong” Kontainers (Containers built using Kontain) that can run alongside traditional Linux Containers, “isolates” the attack and reduces the blast radius by preventing a compromised Container exploit from escaping the Container. At the most the exploit is “contained” within the container.
This is because a “Strong” Kontainer provides:
- VM-level strong isolation boundaries
- Bundles ONLY just enough system code to run the App with App code (not the whole OS and Kernel, BIOS and utilities) which reduces the attack surface
- uses less resources than a traditional Docker Container reducing OpEx
- starts up faster than a traditional container
- provides instant start capabilities to Containers so that you can achieve scale to zero and instant scale-out on demand capability
- Docker and Kubernetes compatibility requiring no change in code
Kontain
You can learn more about using “Strong” Kontainers with Applications and microservices using the application user guide at:
and learn more about Kontain at:
and view the Kontain Github repo at:
