Kloudle
academy

How to Patch the Pwnkit vulnerability (CVE-2021-4034) on the Cloud

Riyaz Walikar •
#pwnkitvulnerability#cloudsecurity#pwnkit
Feature image

What is Pwnkit and why is it bad?

Polkit (formerly known as PolicyKit) is a tool that provides a mechanism for privileged and non-privileged processes to communicate with each other in UNIX-like operating systems. Polkit also has the ability to execute commands as root by using the pkexec command. Polkit is also widely used and comes pre-installed in many major Linux distributions. Some operating systems do not have Polkit installed out-of-the-box but they tend to have packages for which Polkit is a dependency. Thus, making Polkit a widely utilized tool making it a lucrative target for attackers.

Pwnkit is the name given to a local privilege escalation vulnerability, discovered by Qualys, that affects the Polkit service, specifically targeting the pkexec executable. In the Pwnkit vulnerability (CVE-2021-4034), a low-privilege process can escalate to root-level permissions. The ability to escalate a program to be executed as root allows an attacker to perform essentially any operation on the system that was compromised such as - exfiltrating data from the system like proprietary source code, using it to perform recon on other systems in the network, or even lock out authorized users of the system from the machine. The vulnerability combined with the fact that Polkit is an extremely popular tool that comes bundled with many major Linux distros or as a package dependency makes it a severe security issue that should be patched immediately.

The exploit for Pwnkit is very reliable and gives immediate access to a root shell that can be used to take over the entire system. As the vulnerability can only be exploited from a local environment, the attack vectors are somewhat reduced. However as any number of weaknesses that may be afflicting services and web applications exposed to the Internet could give local command execution capability, this vulnerability must be fixed to prevent attacker escalation of privileges.

Who is affected by Pwnkit?

All operating systems that have Polkit installed are vulnerable to Pwnkit (CVE-2021-4034). Some distributions that are affected are - Ubuntu, Debian, CentOS, RHEL, and Fedora.

To check if Polkit is installed on Ubuntu 18.04, the following command can be used:

which pkexec

Polkit installation

You can also use the equivalent of apt list --installed | grep policykit for your flavor of Linux to identify if the necessary package is installed.

Patching standalone machines

Patching the vulnerability is fortunately not a complicated process thanks to most operating systems releasing a security patch for the same. Patching standalone servers can be done in the following three steps:

  1. SSH into the VM (assuming it is a remote system, make sure that you apply the patch for your local systems as well)
  2. Check for updates, specifically any security updates
  3. Install the patch using the operating systems package manager
  4. Reboot the system for the patch to take effect

For example, in Ubuntu 18.04, the following commands can be run to apply the security patch that has been released after SSH-ing into the machine:

sudo apt update
sudo apt upgrade
sudo reboot

Similarly, equivalent commands can be used to patch other distros. The version level of the pkexec binary is 0.105 post patch update. This can be verified using

pkexec --version

For a Linux distribution that does not have a patch release yet by the operating system vendor, we can remove the setuid bit on the pkexec binary to disable the privilege escalation part of the exploit.

sudo chmod -s $(which pkexec)

Patching multiple machines on AWS and GCP

We now know how we can patch a Linux server against the vulnerability, but in a realistic scenario, most Site Reliability Engineers (SREs) and DevOps Engineers would be managing hundreds and even thousands of servers at once on the cloud. Patching at this scale is different from the manual way of patching that we did previously. We will look at using cloud native services to assist us with patching across multiple machines on AWS or by using SSH commands to remotely install the patch for GCP and other cloud providers.

Please note, the package manager commands shown below are for Ubuntu and Debian based systems. For RedHat systems yum update && yum upgrade would serve the same purpose.

AWS with SSM

AWS Systems Manager (SSM) is a service by AWS that allows management of EC2 instances at scale and provides a mechanism for performing actions on the instances as well as within the instances - such as running a bash script.

Prerequisites

Before we can begin, there are some prerequisites for using SSM with EC2 instances:

  1. Ensure that the instance has an IAM role attached to it with the AmazonSSMManagedInstanceCore policy attached to it (refer to this documentation)
  2. Ensure that SSM agent is installed in the instance, some operating systems have it pre-installed while in others, SSM agent needs to be installed manually (refer to this documentation for more details)

Now, with the prerequisites satisfied, we can patch the instances by running the following commands:

  1. List instance IDs

    aws ec2 describe-instances  --query "Reservations[].Instances[].InstanceId" | jq -r '.[]' > instance-ids.txt

  2. Run bash commands to patch the server (Ubuntu 18.04 in this example)

    for instance in `cat instance-ids.txt`; do aws ssm send-command --instance-ids "$instance" --document-name "AWS-RunShellScript" --parameters commands='sudo apt update && sudo apt upgrade -y && sudo reboot' --output text; done;

Note: Steps 1 and 2 need to be repeated for all regions to patch all EC2 instances.

GCP with gcloud ssh exec

GCP’s equivalent of AWS CLI is the gcloud CLI tool. Using gcloud, we can SSH into machines without explicitly configuring SSH access. There are no extensive prerequisites as we had in the case of AWS SSM apart from having an IAM user/Service Account with sufficient privilege to SSH into compute instances.

For all virtual machines in GCP, we can use the following bash script to patch the machines:

#!/bin/bash

gcloud compute instances list --format json > instance-details.txt

cat instance-details.txt | jq -r '.[].name' > instance-names.txt
cat instance-details.txt | jq -r '.[].zone' > instance-zones.txt

while IFS= read -r name && IFS= read -r zone <&3

do
    echo "Name: $name Zone: $zone"  
    gcloud compute ssh ubuntu@$name --zone $zone --command "sudo apt update && sudo apt upgrade -y && sudo reboot &" &
done < instance-names.txt 3<instance-zones.txt

The patching mechanism would be very similar for other cloud providers and you should be able to use native SSH to login into machines remotely and run the update commands.

Conclusion

Pwnkit is a very recently discovered vulnerability (CVE-2021-4034) and thus many systems are still vulnerable. PolKit’s extensive usage across multiple Linux distributions such as Ubuntu, Fedora, etc. make it an even more attractive target. Thankfully, most operating system vendors have released a patch and we saw how we can patch our server with the same. We also saw how to mitigate the vulnerability by removing the setuid permissions on our servers if an official patch is not released and also how to patch a group of servers on AWS and GCP using the CLI. Pwnkit is a serious security issue as it allows root-level access to the underlying machines for users with limited access and thus, performing patching for all our affected servers should be actively considered.

← Back to Academy