Remote Code Execution (RCE) in Kubernetes

A detailed overview of the Remote Code Execution (RCE) attacks, how it affects the Kubernetes infrastructure, and how the vulnerabilities of the K8 systems can be mitigated. 

Remote Code Execution (RCE) is a vulnerability in systems that cybercriminals can exploit to perform attacks. In RCE attacks, hackers execute malicious code in target systems remotely, irrespective of their location on the network. That’s because they don’t need the target systems to have the execution functionality. As long as the criminals can access the network, they can perform RCE attacks.

Usually, the attackers locate the target system over the internet. Then they find the system’s loopholes and vulnerabilities, and exploit them using malicious code. Theoretically, RCE attacks can be carried out on any system that can be accessed remotely. A successful RCE attack can cause a range of issues to the victim’s system, as will be discussed later in this post. 

How Do RCE Attacks Work?

RCE is a broad category. It comprises different types of attacks, which exploit a range of vulnerabilities and can lead to numerous issues. Let’s dive in.

Types of RCE Attacks

Injection

In this type of RCE attack, the code exploits vulnerabilities in applications where user input is required. A good example is the infamous  Log4j vulnerability. Many applications, including those deployed by leading technology companies, use the well-known Log4j Java library to log application messages and errors. To do this, it must communicate with directory services which is where a vulnerability can be exploited by hackers. They can do so by injecting malicious code that can download and install malware from a remote location.

Deserialization

Numerous websites and applications leverage serialization and deserialization modules to make internal and external communication seamless. Several data sources are combined into a single string or piece of information and later deserialized into their original format. Attackers format the input data so that it can be seen as a piece of code. Execution of that by deserialization programs can give attackers access. 

Out of Bounds Write

This type of RCE attack is related to the memory allocated for user-provided data. If the memory allocation process has loopholes and gaps, then malicious users can write the input data outside this memory storage. Thus the attacker can give a carefully crafted input that the system will execute as a code and lead to a successful RCE attack. 

The above three types of RCE attacks occur based on various system vulnerabilities. These loopholes in the system can be explained with Common Vulnerabilities and Exposure. 

What is CVE (Common Vulnerabilities and Exposure)?

Common Vulnerabilities and Exposure is a list of commonly identified vulnerabilities within systems that are openly disclosed. IT professionals prioritize and mitigate these gaps in order to create a system with minimal risk. RCE attacks exploit a wide range of CVEs as follows:

Log4Shell

Numerous variations of Apache vulnerabilities are associated with Log4Shell. This usually occurs due to the common logging library used by Apache and many applications that leverage Java. Due to this, a cyber attacker can create a malicious LDAP server and access it via JndiLookup Class. The CVE associated with Log4Shell/CVE-2021-44228 includes CVE-2021-45046, CVE-2021-45105, and maybe more. Log4j is the logging library.

CVE-2021-1844

Apple products such as iOS, watchOS, macOS, and Safari possess this vulnerability. Here, if the device/system accesses a fraudulent URL, the OS will execute and create a malicious payload on the system. 

CVE-2020-17051

Microsoft Windows communication protocol, called NFS v3, has this CVE. Due to this, the NFS Server can act as a medium for the attacker to send the malicious payload or code to the target system. 

CVE-2019-8942

WordPress 5.0.0 consists of the CVE, which enables cyber attackers to upload image files that comprise PHP code in the Exif metadata of the image. This would give them the necessary access to execute the operations. 

While these are merely four examples of CVEs, there are over 700 CVEs across applications and systems such as banking, 4G routers, billing systems, apache, payment systems, and more. 

Impact of RCE Attacks

• Penetration: The attackers can get access to the network or the system. 

• Data Exposure: Malicious users can intercept sensitive information, access it, and expose it. This is via various means, including data-stealing malware and memory-scraping software that looks for credentials. 

• Denial of Service: Systems can be crashed with RCE attacks that exhaust the network or applications resources, thus denying legitimate users the application’s service. 

• Ransomware: One of the notorious RCE attacks that withhold access to the system from the developers and owners in exchange for money/ransom, thus the malware’s titled – ransomware. 

RCE Attacks on Kubernetes

The aforementioned attacks and impacts are generic and applicable to several systems and networks. The Kubernetes infrastructure is also vulnerable to these and has a significant impact. These involve:

Types of Vulnerabilities in Kubernetes

The vulnerabilities in the Kubernetes infrastructure occur mainly due to misconfigurations of various components such as pods, etcd servers, API servers, and more. These must behave a certain way and mustn’t be accessible to external access directly. 

Exposed kubelet

The kubelet agent is present for every pod and is responsible for managing the pod’s functionalities. It also interacts with the API Server for operations; hence, exposed kubelets can give the attacker access to the various pods.  

Exposed etcd Server

The etcd Server comprises configuration files for k8 systems and its other confidential data, so exposure to the server can hinder the Kube system. 

Exposed API Server

The API Server is a crucial component that enables the communication between various components. An exposure of this would result in an RCE attack that might affect various modules of the infrastructure. 

These three gateways into the Kube infrastructure, means RCE attacks can occur on different modules and lead to the following impact on the system. 

Impact of RCE on Kubernetes

Stolen Account Credentials

Clouds that host Kube systems can be used to gain access to them if the attackers possess the account credentials of the cloud. 

Stolen Service Account Tokens

Containers comprise service account tokens that authenticate with API Servers. If these account tokens are stolen, individuals can control containers and API Servers and command them to perform various functions based on the intent.

Permissive Capabilities

Containers possess several sensitive capabilities that are crucial to the Kube infrastructure’s smooth functioning. If malicious users gain access to these containers, they can access the application’s core and control it entirely. 

Shared Namespaces

Containerized applications tend to run across resources that are spread in various namespaces. These namespaces can also be shared across hosts and containers. During this sharing process, the medium used is at risk of exposure and acts as a gateway for the cyber attacker to enter the container and even the host. 

How to Mitigate RCE Attacks in Kubernetes

Protecting the Kube infrastructure can mitigate the aforementioned vulnerabilities and potential RCE attacks. For this, the following are the most common steps leveraged by developers. 

• Security Updates: Always update the systems to the latest version since the older versions possess several loopholes and vulnerabilities that the attackers can exploit. 

• Access Control: Restricting access to crucial resources and restricting the  kind of users who can access it. 

• Memory Management: To prevent out-of-bound write/read attacks, the memory buffer and storage must be consolidated with utmost safety. 

• Input Sanitization: Well-modified and crafted inputs can be the doom of K8 systems. The various user-input systems need a method that filters out potentially malicious input data from the system’s users. 

• Traffic Monitoring: Monitoring the traffic is a necessary aspect of the mitigation techniques. The various user requests must go through one or more layers of filtering that can identify potentially malicious requests.