Protecting towards new Kubernetes threats in 2024 and past

A wave of latest assaults focused Kubernetes in 2023: Dero and Monero crypto miners, Scarleteel and RBAC-Buster. Finding an preliminary foothold with an online app vulnerability, then transferring laterally is the hallmark of a Kubernetes assault. Understanding the fact of those assaults may help shield your group from present and future assaults focusing on Kubernetes.

Here’s a breakdown of how the assaults unfold and what you are able to do to guard towards them — or not less than reduce the injury as soon as attacked.

Scarleteel plan of assault

A Jupyter pocket book internet software hosted in Kubernetes was the entry level for Scarleteel, with the purpose of accessing encrypted, delicate knowledge housed in cloud storage and crypto mining. To discover open entry to the AWS cloud atmosphere, the attackers additionally used an open-source Kubernetes penetration testing device known as Peirates, together with the same device known as Pacu.

Scarleteel demonstrated how fluidly an attacker can transfer by means of a cloud atmosphere. The attacker jumped from an online software hosted in Kubernetes straight to the cloud to Kubernetes after which again once more. Defenders do not need a equally linked view of their atmosphere, as an alternative cloud safety, internet app safety and Kubernetes safety individually, then struggling to place collectively the total movement and goals of the attacker. 

What you are able to do to guard from Scarleteel

If you’re not utilizing Jupyter notebooks, you may not be vulnerable to this assault. But there are a lot of different internet app vulnerabilities. You can be sure that you shield towards the very particular cloud misconfiguration the attackers took benefit of. If you run EKS, look into locations the place you will have IMDSv1 versus IMDSv2 put in and get a blue crew to run Peirates and Paco towards your atmosphere earlier than an attacker does.

Runtime capabilities would doubtlessly detect the Pandora malware, however wouldn’t join this to the broader assault and exercise taking place throughout the cloud and Kubernetes environments, so it might probably’t cease the whole lot of the assault.

Dero and Monero Cryptocurrency Miners

In the Dero assault, the dangerous actor first scanned for Kubernetes APIs the place authentication is about to permit anybody nameless entry. For this to work, the cluster additionally wanted RBAC configuration that allowed for the creation of pods in that cluster. With these situations met, the attacker deployed a Daemonset, creating its personal pods from malicious pictures throughout the cluster. 

The first a part of the Monero assault is similar as Dero. Then, with entry to the Kubernetes API, attackers deleted the Dero pods and deployed their very own privileged pod through Daemonset. The privileged pod then tried to mount the host listing to flee the container and downloaded a rootkit that might conceal the miner. Afterward, the attacker put in a customized mining service on the host.

Unlike Dero, the Monero assault includes privilege escalation and container escape methods. Allowing privileged containers is likely one of the most important Kubernetes safety points to keep away from. Kubernetes disallows privileged pods in its baseline coverage for Pod Security Standards, making it much less doubtless it will occur by default.

However, for those who’re working EKS and Kubernetes v1.13 and above, the default pod safety coverage is privileged. In EKS, you will need to delete this coverage to allow your buyer insurance policies — an added step that doubtlessly will increase the possibilities you’ll enable creation of privileged pods. 

In Monero, there’s lots of runtime exercise that occurs after hackers reap the benefits of the preliminary Kubernetes misconfiguration. Locking this down would stop malicious runtime habits from spreading to different pods and clusters. Stopping disallowed host mounted paths and privileged pod misconfigurations is a very powerful preventive measure. If you’re doing KSPM on polling intervals, you’re lacking any attacker exercise that occurs in between.

How to guard from the Dero / Monero assaults

If uncovered, your major concern is tamping down the blast radius — because the assault happens in real-time in Kubernetes, not in runtime. If your runtime functionality features a rule round Monero crypto mining, you’ll be able to cease the final step however not the preliminary phases of the compromise.

Although you most likely wouldn’t set your API to permit nameless entry, there are different methods this similar entry level could possibly be exploited. A malicious insider might plant backdoors or cryptocurrency miners just like those in these assaults. A developer might unknowingly examine in a service account token or kubeconfig file to a public git repository that might depart a cluster weak.

The most vital protecting measure is stopping the creation of malicious workloads from Daemonsets. There’s additionally a case for observability tooling, as many crypto jacking operations are found by means of surprising site visitors spikes.

Since this assault used a picture to create the malicious pods, organising an admission management coverage that stops the creation of workloads coming from untrusted picture sources would work. However, you’d both should implement the coverage broadly or make use of a real-time KSPM detection answer to grasp precisely the place you’re having points, then use the admission controller surgically as you repair the configurations in code.

RBAC-Buster plan of assault

The attacker makes an attempt to achieve a foothold in a Kubernetes atmosphere by scanning for a misconfigured API server that will enable unauthenticated requests from customers with privileges. Attackers used privileged entry to record secrets and techniques and uncover the kube-system namespace.

They created a brand new ClusterRole with admin privileges and a brand new Service Account within the namespace, binding the 2 collectively to offer the ClusterRole’s admin privileges to the Service Account. The attacker seemed for AWS keys to achieve entry to the cloud service supplier. They then used a Daemonset to deploy malicious pods for crypto mining throughout the cluster, utilizing a container picture. 

The preliminary step on this assault assumes that not solely is your Kubernetes API server open, nevertheless it’s additionally accepting requests that privileged customers have. The remainder of the assault operates with this privileged entry. 

What you are able to do to guard from RBAC-Buster

To unfold laterally, the attackers used the identical Daemonset method as within the Dero marketing campaign — a reminder to forestall creation of malicious workloads from Daemonsets. Check your API server configurations and audit your RBAC permissions to guard towards this assault.

Preventing future assaults

The crew that found RBAC-Buster mentioned 60% of uncovered clusters discovered had an lively marketing campaign working. This doesn’t imply 60% of all clusters are uncovered. But attackers are looking for errors, misconfigurations and a manner into your Kubernetes atmosphere.

Most clusters have been solely accessible for a number of hours, highlighting the ephemeral nature of Kubernetes clusters and the way what at the moment factors to an exploitation and publicity may tomorrow be closed off to attackers. This means a nightmare in remediation for those who’re working with polling intervals that may’t present these adjustments over time.

Relying solely on admission management or reverse-engineering detection on runtime occasions when the following assault comes both received’t detect it in any respect or will detect it too late. You want a real-time, mixed view of Kubernetes threat. Defense-in-depth is greatest follow. But, if defense-in-depth supplies no view of how all of the completely different elements work collectively, you’re nonetheless one step behind the attacker. 

Jimmy Mesta is CTO and co-founder of KSOC.