Protecting Kubernetes Against MITRE ATT&CK: Execution

We recently published the first part of our nine-part blog series where we take a deep dive into each of the nine Kubernetes threat vectors across 40 attack techniques and provide actionable advice to mitigate these threats.

• Part one - Initial Access
• Part three - Persistence
• Part four - Privilege Escalation
• Part five - Defense Evasion
• Part six - Credential Access
• Part seven - Discovery
• Part eight - Lateral Movement
• Part nine - Impact

This post is the second in the series and covers tactic #2: Execution.

Execution

The second tactic in the Kubernetes attack matrix is Execution, which focuses on an attacker running code within a Kubernetes cluster to achieve his or her objectives. Malicious code could be executed by gaining access to a running pod, starting a new pod, or exploiting an application vulnerability, or other means.

StackRox helps secure organizations from these threats with capabilities that include the following: detecting and alerting on execution of anomalous, suspicious, or malicious processes; alerting on the use of suspicious tools; incorporating tools that may be useful to attackers into its automated risk profiling; enforcing secure pod configurations; and monitoring RBAC privileges.

Technique 2.1: Exec into container

Issue

Kubectl is a command line tool for managing Kubernetes clusters. ‘kubectl exec’ allows a user to execute a command in a container. Attackers with permissions could run ‘kubectl exec’ to execute malicious code and compromise resources within a cluster.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Administrators can mitigate this threat by restricting RBAC access to the “pods/exec’” resource according to the principle of least privilege. Kubernetes RBAC can be used to reference both resources and subresources. Also, pod configurations can be hardened to limit what an attacker can accomplish by removing unnecessary privileges and ensuring pods run with a read-only root file system.

How StackRox Helps

The StackRox platform helps mitigate threats related to ‘kubectl exec’ by monitoring Kubernetes RBAC configurations for users and service accounts with excess privileges. It automatically monitors runtime activity in every container to detect and alert on anomalous, suspicious, or malicious processes that may execute within a container as a result of an attacker issuing a command. StackRox also alerts on the use of suspicious tools and enforces policies for secure pod configurations.

Technique 2.2: bash/cmd inside container

Issue

This technique references the potential for attackers with permissions to run a bash script inside a container to execute malicious code and compromise cluster resources.

Best Practice for Mitigation

Primary area to configure security controls: Cloud Provider

Organizations can best reduce their exposure to this threat by minimizing access to container hosts.

How StackRox Helps

StackRox helps mitigate this threat in multiple ways. StackRox’s risk profiling automatically identifies containers with tools that are potentially useful to attacker, including bash. It also alerts on the use of suspicious tools as well as monitors, detects, and alerts on concerning runtime activity such as execution of abnormal or unexpected processes within containers.

Technique 2.3: New container

Issue

Existing, running pods are not the only resources that can be utilized by threat actors, and this technique highlights the ability of attackers with permissions to launch new pods as well as Deployments, DaemonSets, ReplicaSets, and other resources that reference controllers to execute their malicious code and compromise cluster resources.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations can implement protections for this technique by controlling and restricting RBAC permissions to create pods and/or abstractions (such as Deployments, DaemonSets, ReplicaSets, and others) that also create pods.

How StackRox Helps

StackRox helps organizations limit RBAC permissions according to the principle of least privilege by automatically monitoring RBAC settings for users and service accounts and identifying ones with overly excessive privileges on clusters. StackRox also analyzes image contents, pod configurations, and runtime activity within pods and gives organizations the ability to optionally block non-compliant container deployments or delete suspicious pods.

Technique 2.4: Application exploit (RCE)

Issue

Containers with a vulnerability that allows for remote code execution can be exploited by an attacker to run malicious code and since service account credentials are mounted to containers by default, these credentials can be used to make requests to the Kubernetes API server that can lead to cluster compromise. Exploiting a vulnerability may also allow an attacker to compromise other resources, access the kubelet read-only API server, access sensitive data stored on cloud provider instance metadata servers, cause a denial of service attack, or undertake other malicious activities.

Real-world example: Docker containers running ElasticSearch with the RCE vulnerability CVE-2014-3120 were observed to have been breached.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Administrators should ensure that applications use unique service accounts and that service account tokens are not mounted if an application does not require access to the Kubernetes API server. Container images should be scanned for vulnerabilities, including RCE vulnerabilities, and users should ensure that running Kubernetes Deployments do not have vulnerabilities that would allow for code execution.

How StackRox Helps

StackRox scans container images for vulnerabilities and enforces policies on how images with specific vulnerabilities can be used and provides a Kubernetes admission controller to prevent containers with vulnerabilities from launching. It makes it easy to discover vulnerabilities in existing Deployments and also automatically monitors RBAC configurations to help determine whether access to the Kubernetes API server is scoped down to as few privileges as required.

Technique 2.5: SSH server running inside container

Issue

This technique under Execution arises when an SSH server is running inside a container, which could allow an attacker who obtains credentials to that container through other means to gain remote access to the container to run malicious code and compromise resources.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Other - tooling

Kubernetes

In Kubernetes, administrators should limit service exposure and apply Kubernetes Network Policies to restrict network traffic and prevent unintended access to a container that is running an SSH server. Pod configurations should also be hardened to prevent SSH servers from being added at runtime.

Other - Tooling

Additionally, organizations should audit any installations of SSH server software that exist in container images.

How StackRox Helps

StackRox delivers built-in policies within its platform that identify Deployments with SSH ports exposed and pods that execute ‘sshd’ processes. The StackRox platform’s user interface also provides a visualization of network traffic flows to and from containers, making it easy to identify unexpected communication with containers that are running SSH servers.