• caglararli@hotmail.com
  • 05386281520

Kinsing Malware entering via compromised Dockerhub Images?

Çağlar Arlı      -    6 Views

Kinsing Malware entering via compromised Dockerhub Images?

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.