A reverse engineer has discovered what is claimed to be “the first known malware targeting Windows containers to compromise cloud environments,” a sentence to put any system administrator on edge.

Building on work published in December of last year on reverse-engineering Windows containers, security researcher Daniel Prizmant’s latest discovery – made during his day job at Palo Alto Networks’ Unit 42 security arm – looks to punch holes in Kubernetes clusters, and has apparently succeeded in doing so across at least 23 known targets.

“Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers,” Prizmant wrote of the malware, which he first discovered in the wild in March. “Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.”

A hidden danger
Siloscape does its best to stay hidden, Prizmant discovered, using the Tor Project network and an anonymous .onion domain to connect to a command-and-control server. During his analysis, Prizmant found 313 individual systems connecting to this server – though could verify only 23 active Siloscape victims, suggesting the malware represents only part of a broader attack.

“Compromising an entire cluster is much more severe than compromising an individual container,” Prizmant explained in his report, “as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application. For example, the attacker might be able to steal critical information such as usernames and passwords, an organization’s confidential and internal files or even entire databases hosted in the cluster.

“Such an attack could even be leveraged as a ransomware attack by taking the organization’s files hostage. Even worse, with organizations moving to the cloud, many use Kubernetes clusters as their development and testing environments, and a breach of such an environment can lead to devastating software supply chain attacks.”

“This particular malware is extremely impressive,” ESET UK cybersecurity specialist Jake Moore told The Register, “and something even infosec professionals were not expecting. However, this is exactly what we should be doing and expecting the unexpected in all walks of cyber crime. This type of attack can be leveraged into multi-layered attacks causing all levels of disruption and grief to any targeted organisation.”

“While it may seem surprising that we now have malware targeting containers, in reality it shouldn’t come as much of a surprise,” added security specialist Sean Wright. “The way organisations run their services has changed, with more and more organisations deploying their services and applications into containers, most notably Kubernetes. Criminals will adapt as well, and time and time again they have shown if anything they are incredibly resourceful and adaptive when it comes to trying to stay a step ahead.

“Additionally,” said Wright, “since organisations will likely run multiple services within a single Kubernetes cluster, gaining access to this could effectively give attackers an enormous level of access and control. It’s no wonder that attackers have their eyes on this. Combine this with the fact the Kubernetes is still a relatively new technology, many companies likely don’t have the sufficient knowledge to ensure that their instances are configured entirely correctly and most importantly securely.”

Microsoft caught napping
Prizmant had previously reported the ability to break out of Windows container boundaries in July 2020, but to his surprise Microsoft was initially unconcerned. “Microsoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server containers are not a security boundary, and therefore each application that is being run inside a container should be treated as if it is executed directly on the host,” Prizmant recalled.

“A few weeks after that discussion, I reported the issue to Google because Kubernetes is vulnerable to those issues. Google contacted Microsoft, and after some back and forth, it was determined by Microsoft that an escape from a Windows container to the host, when executed without administrator permissions inside the container, will in fact be considered a vulnerability.”

It was shortly after this reclassification that Prizmant discovered Siloscape, which he believes has been actively exploiting zero-day vulnerabilities in containerised applications, and using Windows-specific container escape techniques to gain access to the underlying node and from there the cluster for over a year.

“Users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature,” Prizmant concluded. “Furthermore, administrators should make sure their Kubernetes cluster is securely configured. In particular, a secured Kubernetes cluster won’t be as vulnerable to this specific malware as the nodes’ privileges won’t suffice to create new deployments. In this case, Siloscape will exit.”

StackRox today unveiled an open source static analysis tool dubbed Kubelinter that analyzes YAML files and Helm Charts to identify misconfigurations in Kubernetes deployments prior to deployment.

Viswa Venugopal, staff software engineer at StackRox, says given the prevalence of misconfigured Kubernetes clusters it’s apparent there is a need for a security tool that IT teams can employ before a Kubernetes cluster is deployed. Written on the Go programming language, Kubelintr accomplishes that goal in a single binary file that IT teams can run in a command line, he says.

Longer term, StackRox plans to add auto-remediation capabilities to Kubelinter that IT teams can employ as they best see fit depending on the impact those changes might have on their applications. Many existing clusters are running older versions of Kubernetes that were not designed to support security capabilities that have been included in the more recent versions, notes Venugopal.

Configuration issues among early adopter of Kubernetes clusters have become an issue because of the complexity of the platform. Most developers who have spun up Kubernetes clusters are primarily focused on simply getting the platform to run. As such, they often overlook the fact that the default setting for Kubernetes are fundamentally insecure. Security settings are not turned on by default because it adds additional complexity to a platform many IT teams are already struggling to master, he says.

KubeLinter provides an automated means to carry out configuration checks as part of a continuous integration (CI) workflow that makes it easier to track how changes are proposed and made to YAML files and Helm charts, he adds.

A recent survey of 400 IT and security professionals conducted by StackRox finds human error to be the main cause of most Kubernetes security incidents, with misconfigurations contributing to roughly 67% of the incidents reported by survey respondents. A total of 90% of respondents report they experienced a security incident in their container and Kubernetes environments over the last 12 months, with 44% noting they delayed moving an application into production because of security concerns.

Despite misconfiguration issues, the rate at which Kubernetes clusters are being deployed continues to accelerate as organizations look to deploy microservices-based applications that are both more flexible and resilient. Many of those applications are driving digital business transformation initiatives that require applications that can also be more easily updated as business conditions change.

The challenge organizations face is cyber criminals are also tracking this transition. Tools for scanning for misconfigured Kubernetes clusters are readily available. The paradox is that some of the most strategic applications any organization has deployed in years are running on Kubernetes clusters that are often misconfigured.

It may be a while before best DevSecOps practices evolve to point where misconfigurations of Kubernetes clusters become less of an issue. However, as more tools to address the issue become available, it may now only be a matter of time before most IT teams are configuring Kubernetes clusters right every time they are deployed.