Статья Exploring Command Injection Flaws in Kubernetes

[admin]

Introduction​

Kubernetes is no stranger to command injection vulnerabilities. In 2023 alone, 7 such vulnerabilities were found, including several Для просмотра ссылки Войди или Зарегистрируйся. Input sanitization concerns drove us to look more deeply into ancillary attack vectors: Is this attack vector unique to Kubernetes’ main project or is it more widespread? There are several sidecar projects associated with Kubernetes in which vulnerabilities can hide, including Для просмотра ссылки Войди или Зарегистрируйся.
The git-sync project is meant to connect a pod and a git repository to sync changes between their site/server automatically instead of making changes manually through a CI/CD solution. For example, users could use this feature to link their nginx pod with a repository containing the files they want to expose through an nginx pod.

In this blog post, we will go through the details of the design flaw, the issues in the Kubernetes source code that allow it, and some mitigations. We will also discuss Для просмотра ссылки Войди или Зарегистрируйся to our findings.

Attack vector details​

By looking into the git-sync use page, we can see that it supports many possible configuration parameters so that a user can customize git-sync to their needs. This allows for a potentially large attack surface that an attacker could exploit (Figure 1).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 1: Some of git-sync’s parameters

The Kubernetes framework uses YAML files for basically everything — from configuring the Container Network Interface to pod management and even secret handling, so a vulnerability within YAML can be quite dire. In this case, a pod can be created to use git-sync to connect to a remote repository (or an attacker).
Figure 2 is an example of a configuration YAML file that deploys a pod with git-sync.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 2: Configuration YAML file that deploys a pod with git-sync

The two parameters that stood out the most as potential attack vectors were GITSYNC_GIT and GITSYNC_PASSWORD.
Per the official git-sync Для просмотра ссылки Войди или Зарегистрируйся, GITSYNC_PASSWORD_FILE is “The file from which the password or personal access token (see github docs) to use for git authentication (see --username) will be read.“ This hints at a possibility for data exfiltration of the “accesstoken” or other files on the pod.
GITSYNC_GIT is (again, from the Для просмотра ссылки Войди или Зарегистрируйся) “The git command to run (subject to PATH search, mostly for testing). This defaults to "git," which means we can choose a binary that will be executed instead of git, and use it for code execution on the cluster.

Proposed attack chain​

With the above information in mind, we set out to prove our theories. We believe there are a few attack vectors that attackers can exploit.

Stealthy code execution​

An attacker with low privileges (Create privileges) on the cluster or namespace can apply a malicious YAML file containing a path to their binary, causing it to be executed under the git-sync name.

The binary file needs to be inside the pod, which can be done in a few different ways, such as via Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся, or LOLBins that come with the git-sync pod (Figure 3).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 3: YAML example using LOLBins

After applying the YAML file, in the eyes of blue team personnel git-sync is the one communicating with a remote server, and therefore it's reasonable to assume it would be trusted to communicate externally. This allows attackers to bypass security measures as a bonus to the command execution.
Figure 4 is a POC of a potential attack starting an XMrig cryptominer under the git-sync user.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 4: PoC of potential XMRig cryptominer

Now, when a network administrator audits existing pods and their communication outside the company network, they will most likely see the git-sync user communicating with an outside server.

Data exfiltration​

An attacker with Edit privileges can edit a git-sync deployment to change or add the GITSYNC_PASSWORD_FILE parameter and point it at any file on the pod. This will cause git-sync to send over the file as a means of authentication on its next connection to the git repository.

If the attacker also modifies the git repository location, and sets up a pseudo repository server, the next deployment of the git-sync process inside the pod will send the file in the GITSYNC_PASSWORD_FILE parameter from the pod to their machine. There are no restrictions on the file paths or permissions required for the GITSYNC_PASSWORD_FILE.

A high-risk exfiltration is not hard to imagine. Consider the following: Attackers can use this technique to retrieve the access token of the pod, which would allow them to interact with the cluster under the guise of the git-sync pod (Figure 5).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 5: PoC of potential GITSYNC_PASSWORD_FILE attack

Disclosure and Kubernetes’ response​

We originally disclosed our findings to the Kubernetes team back in December 2023. After some discussion with the Kubernetes team, it was decided that editing YAMLs is considered a high-privilege operation so our findings don’t cross a security threshold. From our perspective, however, although edit operations on a pod are considered privileged, lateral movement is still possible with this technique. There was also a concern of losing integrity: The attacker would be able to steal information as if they were a legitimate git-sync user.

On the matter of GITSYNC_GIT, the Kubernetes team acknowledged that the privileges required for this type of action are low, but did not think that the low-privilege operations would lead to any harmful behavior. However, we believe that the design flaw we’ve described would allow attackers to execute commands while spoofing their identity, and the only bar to harmful behavior is low privileges on the cluster. This attack flow is especially dangerous in organizations that have pre-authorized git-sync communication in their cluster. In both cases, Kubernetes encouraged us to share this very valuable research online as it “helps remind admins to think carefully about the surface area they expose to users.”

Для просмотра ссылки Войди или Зарегистрируйся