A Sprint in a Life while Penetration Testing Our Docker Environment (but not really)
Hi! My name is Azka and I want to destroy our docker infrastructure.
Actually no, just kidding :)
Docker is a very popular tool used to deploy and scale applications, and sometimes also used as development tool to share the same environment across platforms and machines to get the same expected behavior out of every and each of them. It also known for its strong security, for its contained environment is so hard to be broken. They uses concept as machine virtualization, while also very different, making it runs at noticeable better performance while providing similar level of isolation. It might be caused of the use of the same kernel as its host machine (at least for Linux that is).
But even when the security is tight, still it has its own problem. As the time goes it has various exploits and vulnerabilities. One of the most recent one is their vulnerability for the use of runC, a CLI tool for spawning and running containers. The vulnerability it self is documented as CVE-2019–5736.
Here at PPL at Fasilkom UI, we uses Docker with the assistance of Portainer. Knowing this vulnerability, of course I was wondering if our server is also vulnerable to the same cause.
After doing some research (read: google some stuff), I found something on this site, quoting from Scott McCarty, Red Hat technical product manager for containers:
The disclosure of a security flaw (CVE-2019–5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it.
After reading those statement, I decided not to tests it on the actual Portainer and Docker service running at our campus (yes, I don’t have a plan to be expelled or being the enemy of the entire faculty).
So what I did is do some research and proof of concept (PoC), and planning tries it on my very own, precious, primary machine that I use everyday like my life depends on it. (which apparently I have not yet done at the time of writing this blog).
This is Supposed be The Proof of Concept
The most comprehensive explanation of the vulnerability, along with the proof of concept, that I found is from a security site, twistlock.com.
There, I tried to comprehend what actually is happening, what was being exploited, and what can we do to prevent the exploitation. Here’s the link that I read.
At first, I thought that we need to specifically uses runC for the exploit to be working, but after reading this post, it appears to be that every modern host machines that’s running docker services uses runC for their container management CLI tool.
This sounds bad.
We know that the commit 6635b4f0c6af3810594d2770f662f34ddc15b40d supposed to patch the exploit, but how can we know if the service uses that commit version or more recent one?
So lets take a look at our system specification and hope that everything is clear and sound.
In Portainer, there is this tab called “ HOST”, where it appears to be some information tab showing the specification of the host system.
Well, there’s not so much to see, but we can get something out of it. Now we know that at least this system won’t be vulnerable to dirty cow vulnerability where it enables attacker to get an privilege escalation.
But what about in the “Engine Details” part? from there we know that it uses version 18.09.5 with API version 1.39, pretty much new at the time of writing this blog. However we still have no idea what was the commit version of the running runC.
So I install one myself. Here’s the version of my docker service running my machine.
It doesn’t have the same engine version, where what I have is the older one (I have no idea how did this happened). But since the version on the Portainer is newer, if my docker engin2e version is running well, then the one one Portainer should run better, so there’s no problem here.
So now let’s take a look at my version of runC
There we can see that the commit version of the runC is 2b18fe1d885ee5083ef9f0838fee39b62d653e30. If we take a look at runC’s github commit history, we can see which one is more recent.
As we can see at the two screenshots of commit detail, which both have been merged to master, that fortunately the runC on my local machine is more recent, so the patch have been applied.
I hadn’t had the time to test this myself on my machine, but hopefully the exploit has been rendered ineffective either against my local machine or the Portainer.
The effect it has
While this vulnerability is very severe, it is still somewhat save in our Portainer, because the access to that machine is limited to small group of student. But if the credential of any of this student is breached, then the attacker will have access to create a hostile image and runs it on Portainer.
Even though on my local machine the exploit is unusable, but we still have no idea about the one on Portainer. To further investigate, I need to ask for permission to the lecturer team.
