First Known Malware to Operate Exclusively From Within a Container
It was a good run. For years Kubernetes and containers were impervious to the ever-increasing threat of malware and ransomware; unfortunately, that streak has ended. A nasty little techno-critter has started to show its hand, and it may only be the beginning.
Siloscape, named because it tries to escape the silo that is its container, started rearing its ugly little face back in March. Discovered by Daniel Prizmant of Unit42 and documented within his interesting write-up, it is the first known malware to operate exclusively from within a container and target backdoors inside poorly configured Kubernetes clusters. Prizmant quickly details how the malware collects data at the cluster level, making any hosted databases, user credentials, and other business-critical data inside an easy and obvious target for the autonomous attacker.
Prizmant states just how dangerous Siloscape can be once it gets hold of some of this data from within the Kubernetes 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.
At the time of writing, Prizmant managed to get into the Siloscape "command and control" sever and identified over 23 victims of the malware and over 300 users participating in the attack, which he deemed a small part of a much larger campaign. With all of the information gathered around Siloscape, it is paramount that we realize the threat has just begun to manifest itself against Kubernetes environments. When one bad app can get through, more are soon to follow.
Now, if you are like me and thought, "containers and Kubernetes are the future and were impervious to all of this ransomware badness," I have more disturbing news. The discovery of Siloscape becomes especially more troubling when paired with a research study performed by Stackrox, who found over 67% of respondents polled had detected some serious misconfiguration around their Kubernetes environment. With Kubernetes being open-source and a quick-to-deploy solution that leaves much of the finer configuration details and security setup to an untrained end-user to manage, this could very quickly get out of hand.
Fortunately, it's not all bad news. Many businesses and governments have already opened their eyes to the monumental threat malware as Siloscape poses. Veritas' very own Sonya Duffin has written an excellent piece about some of the changes that have already begun to take place at the White House level of operations. Beyond the demands of Uncle Sam, there are numerous tactics any admin can take to help prevent the pain that a Kubernetes targeted malware can bring.
Good IT behavior starts with YOU! As a victim of ransomware, I can attest to the importance of having good password behavior firsthand. I recommend using unique, differentiated passwords per user account, ensuring correct password (and data) encryption when static or in transit, and keeping vulnerable and valuable data out of plaintext whenever possible. In the case of Kubernetes, ensure you understand how to secure it from top to bottom is up to snuff. Kubernetes offers some of the most well-written and understandable documentation out there and presents an entire section on how to configure, manage, and secure your cluster properly. Kubernetes can be an awesome way to level up applications and services. Still, it can't be overstated how important the proper configuration of each Kubernetes cluster is for the end-user.
In addition to good hygiene, Veritas is also out to make protection and recovery from ransomware like Siloscape less burdensome. With the latest release of NetBackup 9.1, admins now can protect an entire Kubernetes namespace, keeping all the pods, storage volumes, and containers within recoverable. Whether you are rocking a build-your-own deployment of native K8s, operating in VMware Tanzu, Azure Kubernetes Service, or a little bit of all the distributions out there, ensuring a healthy library of namespace backups brings confidence and expediency to recovery for Kubernetes should something go wrong. Pair this with the additional ability to recover to an unaffected cluster in a secondary location, and the level of resiliency and effectiveness to quickly bring apps and services back online becomes readily achievable.
The good news is with proactive security behavior and data protection policies in place, you can avoid pitfalls at best and recover to a last good working state at worst. Ensuring Kubernetes admins are aware of the looming threat that can now attack the once invulnerable application stack is pivotal to its continued growth and success. Like the great team of philosopher counter-terrorists always said: Knowing is half the battle! While I always wondered what the other half was, I think it's safe to say that it's probably ensuring you have good data protection in place, and that's something we can all agree.
If you'd like to see if we CAN agree - check out our lively discussion on the future of virtual machines, containers, Kubernetes, and which is the right tool for the job during Veritas L!VE tomorrow, July 13, at 8 AM Pacific on LinkedIn.
