2

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: enter image description here

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.

0

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.

3
  • Agree that this is a curation issue, but I suspect that Docker hub will have to be more transparent on which images are verified and safe and wich are not.
    – fccoelho
    Jun 21 at 13:29
  • 1
    On Docker Hub Search, there are two categories. the first is "Official Images" and the second is "Verified Publishers" , both of those are (AFAIK) curated. There are (at the moment) 612 images in those categories. The rest of the ~8M images on Docker hub are not curated. Jun 21 at 14:05
  • I understand that they cannot verify all containers, but guidelines for verifying containers should be provided IMHO
    – fccoelho
    Jun 22 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.