The Kinsing malware is now actively breaching Kubernetes clusters by leveraging known weaknesses in container images and misconfigured, exposed PostgreSQL containers.
While these tactics aren't novel, Microsoft's Defender for Cloud team reports they have seen an uptick lately, indicating that the threat actors are actively looking for specific entry points.
Kinsing is a Linux malware with a history of targeting containerized environments for crypto mining, using the breached server's hardware resources to generate revenue for the threat actors.
The threat actors behind Kinsing are known for exploiting known vulnerabilities like Log4Shell, and, more recently, an Atlassian Confluence RCE to breach targets and establish persistence.
Scanning for container image flaws
Microsoft says that they saw an uptick in two methods used by Kinsing operators to gain initial access to a Linux server — exploiting a vulnerability in container images or misconfigured PostgreSQL database servers.
When exploiting image vulnerabilities, the threat actors hunt for remote code execution flaws that enable them to push their payloads.
Microsoft Defender for Cloud telemetry indicated that the threat actors are attempting to exploit vulnerabilities in the following apps for initial access:
- PHPUnit
- Liferay
- Oracle WebLogic
- WordPress
In WebLogic cases, the hackers scan for CVE-2020-14882, CVE-2020-14750, and CVE-2020-14883, all remote code execution flaws impacting Oracle’s product.
“Recently, we identified a widespread campaign of Kinsing that targeted vulnerable versions of WebLogic servers,” reads a report by Microsoft security researcher Sunders Bruskin.
“Attacks start with scanning of a wide range of IP addresses, looking for an open port that matches the WebLogic default port (7001).”
Mitigating this problem is as simple as using the latest available versions of the images you wish to deploy and only sourcing these images from official repositories and trustworthy locations.
Microsoft also suggests minimizing access to exposed containers by using IP allow lists and following least privilege principles.
Attacking PostgreSQL
The second initial attack pathway that Microsoft's security experts observed was an uptick in the targeting of misconfigured PostgreSQL servers.
One of the most common misconfigurations the attackers leverage is the ‘trust authentication’ setting, which instructs PostgreSQL to assume that “anyone who can connect to the server is authorized to access the database.”
Another mistake is assigning an IP address range that is far too wide, including any IP address the attacker may be using to give them access to the server.
Even if the IP access configuration is strict, Microsoft says Kubernetes is still prone to ARP (Address Resolution Protocol) poisoning, so attackers could spoof apps in the cluster to gain access.
To mitigate PostgreSQL configuration issues, consult the project's security recommendations webpage and apply the proposed measures.
Finally, Microsoft says Defender for Cloud can detect permissive settings and misconfigurations on PostgreSQL containers and help administrators mitigate the risks before hackers leverage them.
For PostgreSQL admins whose servers become infected with Kinsing, BigBinary's Sreeram Venkitesh wrote an article on how the malware infected their device and how they finally removed it.
Comments
JamesVanderPump - 1 year ago
Apart from the obvious unpatched WordPress issue, having layer upon layer of abstractions (docker, Kubernetes) makes the whole system very opaque and prone to misconfigurations. Take for instance Docker that can really mess up your firewall configuration. I try to run things as bare bones as possible and take full control over the configuration and update policies.
prune998 - 1 year ago
Can you give some examples of "actively breaching Kubernetes clusters " ?
It feels Kubernetes is just a clickbait here... yes, your stupid java or PHP apps depending on stupid unmaintained libs blindly used by devs that don't know or care about how they work can be breached, even in K8s, but I still would like to understand how this is worse that breaching into your vmware or your onprem server ?