At the online Black Hat USA 2020 conference today, researchers from the Unit 42 arm of Palo Alto Networks disclosed how they had enabled malicious code to escape from a Kata Container runtime environment that makes use of lightweight virtual machines to isolate workloads.
In theory, if a cyberattack breaks out of the container it should still be confined to the virtual machine. However, Unit 42 researchers demonstrated multiple ways they were able to compromise both the Kata Container runtime and the underlying host. Several cloud service providers rely on Kata Containers, which were developed under the auspices of the OpenStack Foundation, to isolate container workloads.
Yuval Avrahami, senior staff researcher for Unit 42, says the techniques the researchers employed to break out of Kata Containers have already been remediated in collaboration with the Kata Container community.
Avrahami says the fact that Unit 42 researchers were able to find multiple ways to break out of a Kata Container shows IT teams should not assume that platforms that essentially create sandboxes to isolate containers are sufficient to ensure the security.
Interest in lighter-weight approaches to securing containers is rising as an alternative to legacy virtual machines. There is a clear need for lightweight virtual machine platforms to isolate containers in organizations as an alternative to legacy virtual machines that were designed primarily to run guest operating systems that host monolithic applications. Containers, in contrast, only require a lightweight virtual machine to isolate one container workload from another.
The overall adoption of lightweight virtual machines is still in its infancy. However, as IT teams explore alternatives to both commercial virtual machines from VMware that need to be licensed or open source virtual machines that consume too much infrastructure, the debate over how to best secure containers is intensifying.
In theory, applications built using containers are more secure because it is easier to rip and replace containers that might be compromised by malicious code. The issue is developers might pull compromised containers from a repository that they assume are safe. That malicious code then could compromise a container host unless layers of additional security are employed to ensure malware doesn’t move laterally across the IT environment, says Avrahami.
Unit 42 researchers last week disclosed how a known cybersecurity flaw could potentially be employed to take over an entire cluster when running an older version of Kubernetes.
As is often the case with any emerging platform, container security concerns are running high. The number of containers being deployed in IT environments is accelerating rapidly. However, many organizations still don’t understand all the cybersecurity implications.
It’s not apparent to what degree any of these vulnerabilities actually might have been exploited. However, hackers working on behalf of various nation-states have the skills required to exploit emerging container platforms. We don’t yet know if any of them already discovered these or any other issues before cybersecurity researchers disclosed them.