Lateral Movement in Containerized Environments
What Is Lateral Movement?
Lateral movement refers to the actions taken by an attacker, after they have successfully compromised a system or network, to move from their initial point of entry to other systems or networks within the same organization. This can include techniques such as using stolen credentials to access other systems, exploiting vulnerabilities in network infrastructure, or leveraging trust relationships between systems to move laterally.
The goal of lateral movement is to gain access to sensitive data or to gain control of additional systems, which can be used to further the attacker’s objectives. This can enable the attacker to exfiltrate data, disrupt services, or establish a foothold for future attacks. This stage is crucial for attackers as it gives them the ability to move around the environment and have a bigger attack surface.
Lateral movement techniques can be manual or automated. Manual lateral movement typically involves an attacker using their own knowledge and skills to manually access other systems or networks within an organization. This process can be time-consuming, but it can also be very effective if the attacker is able to gain access to sensitive data or systems.
Automated lateral movement typically involves the use of scripts or tools that automate the process of moving laterally within a network. This can include tools that use stolen credentials to automatically access other systems or exploit known vulnerabilities to gain access to additional systems. Attackers might use a combination of both manual and automated methods to traverse through the environment and achieve their objectives.
How Does an Adversary Gain Unauthorized Access to a Kubernetes Cluster?
There are several ways an attacker can gain unauthorized access to a Kubernetes cluster, but the most common scenario involves compromising a pod and using it to access other parts of the cluster. Here are a few examples:
- Misconfigured cluster: Kubernetes clusters may be misconfigured in ways that expose them to unauthorized access. For example, if a cluster is set up with weak or easily guessable credentials, an attacker may be able to gain access using brute-force methods.
- Compromised node: An attacker may be able to gain access to a cluster by compromising a node, either through a vulnerability in the underlying operating system or by stealing credentials from an administrator. Once a node is compromised, an attacker may be able to use it to gain access to the cluster and move laterally to other nodes.
- Insecure communication: If the communication between nodes or between nodes and the Kubernetes API server is not properly secured using encryption and authentication, an attacker may be able to intercept and tamper with the traffic to gain access to the cluster.
- Exploiting Kubernetes components: There are cases where an attacker might be able to exploit vulnerabilities in the Kubernetes components such as etcd, kubelet, apiserver. If an attacker is able to exploit these components, they can gain control over the cluster and its resources.
- Container breakout: Containers running in the cluster may be compromised by an attacker, either through a vulnerability in the container image or runtime, or by stealing credentials from within the container. Once an attacker has compromised a container, they may be able to use it as a point of entry to access other resources within the cluster.
How to Protect Kubernetes Against Lateral Movement
Restrict Access to the Kubernetes Dashboard
The Kubernetes dashboard helps manage cluster resources, but it exposes internal endpoints, allowing unauthorized modifications to the cluster when publicly accessible. Some Kubernetes platform versions deploy the dashboard by default.
If the administrators don’t need the dashboard, they should disable or delete it from the environment. If they choose to deploy the dashboard, it must not have elevated SA privileges.
Restrict Access to Cloud-Based Resources
When running Kubernetes in a cloud environment, it is important to look out for attackers that might exploit their access to one cluster to reach other resources in the cloud.
Applying pod security policies will restrict the file paths that an attacker can mount using a host mount. These policies can also set host paths to read-only.
Protect Container Service Accounts
Kubernetes service accounts are mounted to all pods by default, allowing containers to send requests to the API server. Attackers with access to one pod can use the service account (SA) token to communicate with the Kubernetes API server and access cluster resources.
Enabling role-based access control (RBAC) ensures that service account privileges are restricted by the associated role bindings. Otherwise, the token grants attackers full access to the compromised cluster.
Restrict Internal Network Traffic
Kubernetes allows all internal traffic between pods within a cluster by default. To prevent lateral movement, it is important to enable and configure Kubernetes network policies that segment and restrict communication between different pods in the same cluster. Thus, an attacker that breaches one pod cannot access the other pods.
Protect Credentials Stored in Config Files
Kubernetes configuration files are often used to store secrets, such as application credentials, which can be used to access internal and external resources. It is best to avoid storing such details in config files because attackers might steal them. If storing these secrets is unavoidable, the organization should ensure that the Kubernetes manifests don’t pass them.
Avoid Writable Host Volume Mounts
Attackers can persist on a system by leveraging the hostPath volume, which is used to mount files or directories to a container. Pod security policies should limit the mountable file paths that can be mounted with host mounts (although persistent volume claims can bypass these policies).
Using MITRE ATT&CK and XDR
MITRE ATT&CK is a framework for establishing a cybersecurity baseline, allowing teams to understand how exploits work in a Kubernetes environment. Matrix for Kubernetes is a MITRE ATT&CK knowledge base of tactics and techniques with detailed steps that attackers use to infiltrate Kubernetes clusters.
Once inside the system, attackers often use lateral movement to access other Kubernetes resources like containers and nodes. Extended detection and response (XDR) platforms integrate with MITRE ATT&CK to protect against attacks in containerized environments, allowing organizations to quickly identify malicious actors moving through the network.
An XDR solution ingests network, endpoint, identity, and cloud data to profile device and user behavior. It monitors all internal traffic and endpoint activity to detect suspicious behavior and identify hacking methods and tools such as Mimikatz.
Conclusion
In conclusion, lateral movement is a critical phase of an attacker’s operation in which they move from their initial point of entry to other systems or networks within the same organization. Containerized environments, such as those based on Kubernetes, provide a complex and dynamic environment that can be particularly challenging to secure against lateral movement.
However, by following best practices and implementing multiple layers of security, it’s possible to significantly reduce the risk of an attacker successfully moving laterally within a Kubernetes cluster. Measures such as network segmentation, least privilege access, secure authentication and authorization, network policies, and regular system updates can help limit the potential attack surface and make it more difficult for an attacker to move laterally.