At Twistlock Labs, we continuously try to get into the minds of attackers to better understand how they would attempt to gain access to or potentially compromise your containerized infrastructure. Recently, I shared an in-depth blog post on CVE-2017-5123 to detail how I exploited the waitid() vulnerability in order to modify the Linux capabilities of a Docker container, gain elevated privileges, and ultimately escape the container.
In this follow up article, I explore how the Twistlock Platform blocks malicious behaviors used in that exploit. The example will demonstrate the capabilities of the waitid exploit, which allows me to gain privilege escalation by overwriting the uid, guid, and Linux capabilities of a process. At the same time, you will be able to see how Twistlock Runtime Defense and Twistlock Incident Explorer automatically identify the attack, based on anomalous activity outside of our whitelist model, to surface the attack chain for further analysis.
Attempting the exploit with Twistlock installed
To begin, I assume that an attacker has already gained access to a container and can execute basic, non-privileged commands. First, the attacker will need to get the binary that contains the exploit in to the container, either by downloading it or by writing it locally (the latter would be more unlikely and time consuming).
In our example below, you can see the attacker gets the binary by executing wget. This activity can be seen in Incident Explorer, which automatically highlights the attack chain. The first incident shows the execution of wget, which is a binary that was not expected to run since it is outside the container whitelist behavioral profile. The second incident shows the connection between wget and the internet.
After these two steps, the attacker needs to execute the binary that he just downloaded, which will provide the attacker with elevated privileges. With these elevated privileges, the attacker can do a lot of things. In our demo, the attacker checks his new id, uncovers the ip addresses of the container network by issuing “ip addr”, and turns on promiscuous mode for eth0. After that he performs a port scan. The port scan can be seen as another incident below.
Next, you can see the audits that include most of the actions the attacker performed after the execution of the exploit. These audits represent any violation of the container model, while the incidents above represent a smart correlation of audits to detect attacks that arise when we set Twistlock to ‘alert’ mode.
Below, I’ve shown the same exploit with Twistlock set to prevention mode. As you can see, the wget binary execution was prevented and the rest of the exploitation flow was stopped.
Even if the wget process is whitelisted for our container, in case the attacker would try to write the exploit locally, Twistlock will prevent the filesystem event from writing the exploit on disk. I’ve shown what that would look like from the attacker’s perspective below.
Attackers will always look for the latest opportunity to access sensitive information or critical components of your containerized environments, which is why we are committed to continuously researching potential threats, sharing those details with the community, and improving the Twistlock Platform to better secure your applications.
While Twistlock also offers key capabilities for vulnerability and compliance management, this summary illustrates the immediate benefits Twistlock provides with runtime defense to protect your modern applications. As our team finds new vulnerabilities and threats, I look forward to sharing more details here on the blog. For more information about our latest threat research, follow @TwistlockLabs on Twitter.
Tracking Down Exposed Kubernetes Instances in the WildRead the Blog
The state of exposed container applications and registries | Labs researchRead the Blog
How to Crash the Linux Kernel with a CDROM Interaction – CVE-2018-11506Read the Blog
Twistlock Protection for Kubernetes Specific AttacksRead the Blog