News recently broke of a serious security vulnerability found in Windows Containers. This security flaw has been exposed in the wild by a newly discovered malware named ‘Siloscape’. The vulnerability enables a compromised Windows Container to be used to gain privileges on its host node and thus potentially full access to a Kubernetes Cluster. This can enable the creation of rogue containers, administrative control of existing containers, or access to data within the existing containerized environment. Or in other words, a nightmare scenario for a production Kubernetes Infrastructure.
The name ‘Siloscape’ is indicative of how this vulnerability enables a user to “escape” what most administrators know to be a ‘silo’ in the form of a container. Thought to be the first known malware targeting Windows Containers, this has ramifications for any enterprise utilizing Windows Containers for Kubernetes and should be a reminder to all NetOps and DevOps teams of the importance of implementing proper security controls across the whole Kubernetes Cluster. A key point is that this is crucial across all deployments – production AND non-production. It also reaffirms how crucial it is that the Kubernetes Infrastructure is built with Zero Trust and Web Application Firewall protection from the outset.
This malware initially requires exploiting a known remote code execution vulnerability in the containerized application. This step of the exploit would be dependent on the application and would typically use a known 1-day vulnerability.
The next step is the most concerning. The malware takes advantage of symbolic links (a feature of windows not commonly used) to mount the host file system by impersonating a process called CExecSvc. This enables the malware to escape up to the host node. It then attempts to utilize node privileges to create a new deployment in Kubernetes that establishes a connection back to a rogue Tor network server where remote commands may be issued later. These could vary from accessing data within Kubernetes or controlling production Kubernetes containers.
Typically, containers operate by sharing the kernel with a host node and executing instructions on the host directly. However, while some resources are shared, this is strictly managed to maintain a ‘boundary’. In the case of Windows Containers, however, the recent discovery shows that the boundary may be ‘escaped’ using these techniques.
It is important to mention Windows containers can take two forms:
This issue only affects Process isolation containers.
As a result of this, admins must assume any process running in a Windows Server container to have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running applications in Windows Server containers that need to be secured and isolated, it is strongly recommended that these utilize Hyper-V Isolation containers.
This issue highlights the importance of securing ALL ingress traffic to containers as a prevention mechanism to exploits. Utilizing Kemp Ingress controller with Web Application Firewall and Zero Trust is one simple way to implement Day-0 protection for Kubernetes Applications. You can learn more about Kemp’s Kubernetes integration story here.
For more information, check out our upcoming webinar: Integrating Kemp load balancing with Kubernetes.