Welcome to our second blog post on the Kubernetes threat vectors series.
We are covering different tactics on the Kubernetes attack matrix, published by Microsoft and originally based on the MITRE ATT&CK framework. On the first blog we reviewed the Initial access tactic and its techniques and today, we are moving on to Execution. Let’s get started.
What is Execution?
After completing phase 1 of gaining initial access to the cluster’s resources, the second step of execution is probably the most widely abused tactic of them all. It essentially means that with the right permissions, the attacker is now able to run their code from inside the cluster. Such malicious code can ultimately lead to performing certain actions against containers or to simply take advantage of specific vulnerabilities.
Let’s review the different techniques:
- Container execution + New container
Once having access and relevant permissions, the attacker is able to remotely run malicious commands via the CLI, or more specifically, by using “kubectl exec”.
This technique enables the attacker to use and leverage images as a backdoor container and create new resources from which they can run their code. Ultimately, this can lead to compromising various objects within the environment.
The “New container” technique describes the ability of attackers to use relevant permissions for running their malicious code from a newly created container. Attackers who have permission to deploy a pod or a controller in the cluster (such as DaemonSet \ ReplicaSet \ Deployment) can create a new resource for running their code.
How to mitigate?
Probably the most effective way to protect your deployments is to set and enforce strict security policies that can control what commands are allowed to be executed and by whom. Make sure to have proper RBAC settings while monitoring service accounts with excess privileges, and always stick to the “least privilege” principle.
Another common method is to simply whitelist specific events and commands, denying the execution of unauthorized operations. Finally, you should always make sure that you have proper monitoring tools for early detection of container creation and execution.
- Application exploit
Adversaries may exploit software vulnerabilities in client applications to execute code.
As applications are deployed in a cluster, they are always vulnerable to remote code execution (RCE). An experienced attacker can communicate with the API server by using credentials associated with a certain service account, and service accounts are by default mounted to containers.
How to mitigate?
Application whitelisting is considered to be the most useful control for mitigating malware attacks. It forces the attacker to try other tactics and techniques, thus buying more time for the victim. Implementing scanning tools for your container images is crucial, and should be performed as early as you start building an application. Detecting potential vulnerabilities like RCE in the early stages is key when safely running Kubernetes deployments. In addition, enforcing relevant policies, including monitoring of RBAC settings can come into play here when limited access to the Kubernetes API is required.
- SSH server running inside a container
When attackers gain access with valid credentials, they are able to get remote access to the container itself by communicating through the SSH server. Managing SSH connections among Kubernetes deployments is indeed necessary, however, they can be exploited for attacks and other malicious activity when not configured properly.
How to mitigate?
First, you should have your monitoring and scanning tools set to alert on any open SSH ports. Furthermore, Kubernetes services should be limited in terms of exposure, and relevant network policies should be applied in order to restrict unauthorized traffic.
How can Alcide help?
The Alcide platform offers its three modules to help you neutralize the execution vector by several key methods. The first one is validating RBAC configurations for your resources, focusing on the “least privilege” principle. In addition, Alcide’s kAdvisor focuses on detecting and highlighting compromised Kubernetes resources, while adhering to predefined security and network policies.
Furthermore, Alcide leverages the Kubernetes Admission Controller, offering a simple and secure mechanism to integrate and enforce guardrails in your Kubernetes cluster.
Want to give it a try? Sign up for our 14-day trial to fully experience Alcide’s platform.