Kinsing Malware Targets Kubernetes
It’s always something! The Kinsing malware has long been known to Linux administrators, and, now — surprise! — it’s coming after Kubernetes as well.
Kinsing is an old-school Linux/Unix Executable and Link format (ELF) malware program, written in Go. Given a chance, it runs a cryptominer and attempts to spread itself to other containers and hosts. Over the years, it’s been used in attacks against Docker, Redis, and SaltStack. And, now, now, Kinsing hackers are coming after Kubernetes. I’m shocked, shocked to discover that cryptomining is going on in Kubernetes!
Not.
Sunders Bruskin, Microsoft Defender for Cloud security researcher, is reporting on how it’s now often targeting Kubernetes clusters using two different initial access vector techniques. These are the exploitation of weakly configured PostgreSQL containers and vulnerable images.
In other words, it’s about what you’d expect. Lock down your PostgreSQL settings and check your images for security weaknesses. It’s not that hard.
Microsoft found many images that were vulnerable to remote code execution. These allowed attackers with network access to exploit the container and run their malicious payload. In particular,
The following application images were found to have vulnerable versions:
- PHPUnit
- Liferay
- WebLogic
- WordPress
Microsoft picked on Oracle WebLogic as a prime example. Much as I like to pick on Oracle, it’s not their fault. In 2020 Oracle disclosed three serious vulnerabilities that allowed remote code execution: CVE-2020-14882, CVE-2020-14750, and CVE-2020-14883. But has everyone adopted the fixed versions and built safe images? No. No, they haven’t.
Idiots.
Recently, Microsoft identified a widespread Kinsing campaign, which targeted vulnerable WebLogic servers. The attacks began by scanning IP addresses and looking for an open port that matches the WebLogic default port (7001). Once it finds a potential victim, it loads Kinsing in the system using curl and Bash.
Microsoft mentions, of course, that Microsoft Defender for Cloud, can identify this kind of behavior.
Examples of such alerts include:
- 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 the 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.
Other cloud security programs can do the same. You are using one, right? Right!?
Besides that, stop the infection from happening in the first place by using an image from a known, trusted registry and making sure you patched it up to the latest version. That would be, by the way, Oracle WebLogic Server 14.1.x.
The other popular way to sneak Kinsing in is to exploit weakly configured PostgreSQL instances. These misconfigurations include:
Using the “trust authentication” setting. This is NOT a good idea. As PostgreSQL states: “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).” Please, for the love of your cloud and little kittens, do not use trust authentication. It’s a security hole masquerading as a feature.
In addition, in some configurations, PostgreSQL will accept connections from any IP address. And when I say, “any,” I mean any. For example, it can accept 0.0.0.0/0 as a good address. Oh, and in such configurations, attackers can freely connect to the PostgreSQL servers without authentication. Personally, I would do awful, awful things to anyone who let a PostgreSQL instance with a setting like that on a production machine. Heck, even a test instance!
Finally, some Kubernetes network configurations are prone to ARP poisoning. This enables an attacker to impersonate applications in the cluster. Therefore, even specifying a private IP address in the “trust” configuration can pose a security risk.
Let me make it simple for you. Use PostgreSQL’s best security practices. Make this your default for all PostgreSQL instances, and you’ll be a lot safer from not only Kinsing and all the other attacks out there waiting for you.
