As of late, Kubernetes clusters have been actively breached by the Kinsing malware, which exploits vulnerabilities in container images and misconfigured, exposed PostgreSQL containers. While not new, the Defender for Cloud team at Microsoft has noticed a spike in recent months, suggesting that the threat actors are increasingly focusing on narrow access points.
Kinsing is Linux malware that has been known to infiltrate containerized environments for crypto mining, leveraging the compromised server’s hardware resources to make money for the attackers. Kinsing’s threat actors have previously breached targets and established persistence via taking advantage of Log4Shell and, more recently, an Atlassian Confluence RCE.
Kinsing Aimed At Exploiting Security Holes In PostgreSQL Database
Microsoft claims to have observed an increase in the frequency with which Kinsing operators used a vulnerability in container images or misconfigured PostgreSQL database servers to get initial access to a Linux system.
Exploiting images is a common tactic used by threat actors since it allows them to execute malware and deploy payloads remotely. Based on data collected by Microsoft Defender for the Cloud, we know that attackers are targeting the following software in an effort to get first access:
WebLogic is vulnerable to remote code execution weaknesses CVE-2020-14882, CVE-2020-14750, and CVE-2020-14883, all of which are scanned for by hackers. Earlier this year, Microsoft security researcher Sunders Bruskin discovered “a broad campaign of Kinsing” that aimed to exploit security holes in WebLogic server software.
Scanners are used in the initial stages of an attack to check for open ports that correspond to WebLogic’s default port (7001). To avoid this, make sure you’re consistently deploying the most recent versions of the images you’re using and only use images obtained from reliable sources like official repositories.
Also, IP allows Microsoft recommends lists and the principle of least privilege to restrict access to exposed containers.
Difficulties With PostgreSQL
Microsoft’s security analysts also noticed a rise in attacks directed at poorly configured PostgreSQL servers, the second primary attack vector.
In particular, attackers take advantage of the ‘trust authentication’ setting, which tells PostgreSQL to treat every connection as if it were legitimate and that “anyone who can connect to the server is permitted to access the database.”
It’s also a bad idea to give out IP addresses in a range that’s too big since that could allow an attacker to use one of their own addresses to gain access to the server. Microsoft claims that Kubernetes can be vulnerable to ARP (Address Resolution Protocol) poisoning even when IP access setup is tight, allowing attackers to mimic apps in the cluster and get access.
PostgreSQL configuration concerns can be reduced by following the precautions suggested on the project’s security guidelines page.
Finally, Microsoft claims that Defender for Cloud can identify vulnerable PostgreSQL containers by their permissive settings and misconfigurations, assisting administrators in fixing the problems before hackers can exploit them.
Best Practices for Securing Your Kubernetes Cluster from Security Flaws
The following are recommended procedures for protecting your Kubernetes cluster from security flaws:
- Scanning Process:
Making sure container images are secure is crucial since any flaws in the image will be passed on to all containers produced from it. One standard method for doing this is by checking the base image and its packages against a database of known security flaws.
- Reinforcing the Security of the Host Operating System:
Limit containers to the bare minimum of host permissions. Utilize a host OS that has been fortified with controls to limit access to the file system and the system call interface, and implement stringent isolation between processes. This is useful for preventing privilege escalation attacks, in which a compromised container acquires access to the host operating system or other containers on the system.
- Reducing Vulnerability by Simplifying the Container’s Foundation:
Choose a base image for your containers that only includes the programs that are required for the container to work correctly. To improve upon this, a container can be constructed without the use of a whole base picture.
- Toughen Gatherings of Kubernetes Servers:
Keep in mind that the default Kubernetes cluster configuration is not secure. Examine the current Kubernetes cluster setup and locate places where it falls short of security best practices. Scanning your clusters for conformity with standards like the CIS Benchmark for Kubernetes may be done automatically with tools like Kube-bench.
- Kubernetes Cluster Security Tool Integration
In most cases, traditional security measures, such as web access control gateways and Next Generation Firewalls (NGFW), are unaware of Kubernetes resources. Integrating your Kubernetes clusters with the preexisting security toolkit is one way to get around this problem. Your cluster’s internal security measures will be able to communicate with your perimeter security systems in this way.
- Network Protection:
Security measures in corporate networks and security groups controlled by cloud providers are all centered on the node level, which is a significant cause for alarm in Kubernetes deployments. Although current controls allow for ingress and egress to be managed, they are unaware of which pods or services are actually being executed on a node. As a result, runtime security restrictions are rendered entirely useless due to the fact that multiple services may coexist on a single node, each with its own unique set of security needs.
- Business-Wide Security Measures:
Automate the process of detecting and fixing compliance concerns with Kubernetes. A pod can be automatically updated with a new container image or shut down until the problem is fixed if it fails a compliance check performed by the cluster.
- Assault Prevention:
Threat actors might cause problems in a Kubernetes cluster by, for example, sending traffic to nodes, pods, or the Kubernetes control plane that is designed to exploit vulnerabilities in components operating in containers.
Conclusion
Right now, Kubernetes is under attack from the Kinsing malware. Clusters of Kinsing malware exploited PostgreSQL containers by taking use of flaws in container images and poor configuration. This strategy may not be novel. However, the Defender for Cloud team at Microsoft has seen increased activity in recent months. This indicates that the threat actors are looking for a certain way in. Kinsing is Linux malware that has been known to exploit containerized setups in order to mine cryptocurrencies. It makes money for the attackers by using the server’s hardware resources.
“Kubernetes is extremely powerful and a new foundation of IT strategy, but not immune from malware, vulnerability and exploitation. What’s concerning is that, for the most part, the data security capabilities built into Kubernetes meet bare minimum standards – data at rest protection and data in motion. There’s no persistent protection of data itself, for example, using industry-accepted techniques like field-level tokenization. So if an ecosystem is compromised because of a vulnerability, its only a matter of time before the sensitive data being processed by it succumbs to a more insidious attack. In the last 2 years, Kubernetes vulnerabilities related to privilege escalation, firewall gaps, and remote code execution in Kubernetes tools certainly show it’s vulnerable. The good news is that highly effective techniques like stateless data tokenization are also available for cloud-native/Kubernetes ecosystems today and are ready to mitigate threats while letting enterprises get on with digital transformation at full throttle without breach risks getting in the way.”
“Attacks like these underscore the dangers of misconfigured and exposed servers, which leave organizations vulnerable to attacks. It is vital to properly configure servers’ security features to help prevent attacks against known misconfiguration flaws.”
“Attackers targeting misconfigured databases is surprisingly common. If a database is accessible from the public internet, then there’s a strong chance that attackers can find it using specialized search engines like Shodan and Censys. Often the goal is to steal data or plant ransomware, but in Kinsing’s case, the purpose is to install malware that mines cryptocurrency for the attacker using the victim’s resources. For the victim, the result is diminished performance and higher usage bills.”