Kinsing Malware entering via compromised Dockerhub Images?

Question

I got a server infected with the Kinsing malware, which mines crypto on your server, maxing out your CPUs.

The malware initially creates the files /tmp/kdevtmpfs and /tmp/kinsing If you delete these files and kill the process they get recreated elsewhere in the disk, and also inside your containers to continue with their mining job.

I initially applied this solution, I was free from it for a few minutes, but soon it had respawned with a slightly different name:

I have come across many posts pointing to vulnerabilities in Docker, such as its ability to control iptables, etc.

I have set DOCKER_OPTS="--iptables=false" immediately after installing docker and raised the firewall on a fresh build Blocking all incomming requests except for ssh http and https, but it didn't seem to affect the bug's ability to infect my server.

I am guessing its entering via compromised Docker images. I am using the following images pulled-in via docker-compose:

• dpage/pgadmin4
• rocker/shinyverse
• kartoza/postgis:12.0

I haven't seen any public statements from dockerhub admins raising the possibility of compromised images spreading this malware, so I am posting this here to ask for suggestion on how to mitigate this issue and also avoid being re-infected in the future.

I have considered dropping docker altogether and go back to old-fashioned server configuration and deploy, but without being sure about how this thing spreads, I'd rather delay this decision.

Update

I have modified my docker compose to download only the official Postgis image: postgis/postgis:latest and the dpage/pgadmin4 from dockerhub and reset the virtual server and after a few hours of just having the containers up with a fully closed firewall, the malware was back. So it seems that the malware is being injected as we pull the images from dockerhub. As the malware is written in golang, no having go in your server seems to be a good way to protect yourself from it. The only problem is that Docker itself is a Go program, so that would imply getting rid of Docker as well.

Answer 1

Docker is essentially just a way of deploying applications to your server. Whilst the attackers have used images on Docker Hub to deploy their malware, it's not intrinsically a Docker problem.

To be able to launch a Docker container onto your host, the attacker needs to already have root access or membership of the docker group (assuming you've not configured Docker to listen on a network port).

I'd suggest the general rule of responding to a malware infection is likely to apply here, which is that you need to consider that host compromised and re-build from scratch.

In terms of using images from Docker Hub, in general everything apart from the "official" images is completely uncurated, so Docker Hub doesn't review them. With 7.9m+ images it wouldn't really be practical for them to do so.

From a security standpoint, ideally never deploy images that aren't official and if you do take care to check them for malware before running.