Bitcoin miner in docker hub postgis 13 ?

[jbjuin]

Hi,

it seems that there is a bitcoin miner in this image:

https://hub.docker.com/layers/kartoza/postgis/13/images/sha256-0ebcf54aa52c3c433307273c3f69a07952bb7f794f8d1ee91faaf611b974ae88?context=explore

We installed it few days ago on a machine and 2 days after the process kdevtmpfsi show up consuming 100% CPU.
See here for an issue describing the pb: docker-library/postgres#798

I stoped the container, removed the image, rebooted and deployed the kartoza/posgis:11-2.5.
We already use this image elsewhere and it seems that the miner is not present.

Any idea why it appeared in this last image ?

[ImreSamu]

Any idea why it appeared in this last image ?

I can't see.

$ docker pull kartoza/postgis:13
13: Pulling from kartoza/postgis
Digest: sha256:0ebcf54aa52c3c433307273c3f69a07952bb7f794f8d1ee91faaf611b974ae88
Status: Image is up to date for kartoza/postgis:13
docker.io/kartoza/postgis:13

$ docker run --name kpostgis13  -d kartoza/postgis:13
5ab8a278fbb29e16be88ed1b3e903ec6867c5df9318c99c6b7271758c0f528a7

$ docker exec -it  kpostgis13 sh -c "whoami && find / -name kdevtmpfsi"
root
find: ‘/proc/324/map_files’: Permission denied
find: ‘/proc/327/map_files’: Permission denied
find: ‘/proc/328/map_files’: Permission denied
find: ‘/proc/329/map_files’: Permission denied
find: ‘/proc/330/map_files’: Permission denied
find: ‘/proc/331/map_files’: Permission denied
find: ‘/proc/332/map_files’: Permission denied
find: ‘/proc/333/map_files’: Permission denied

$ docker stop kpostgis13
kpostgis13

IMHO:

• add SSL
  • Fix Sslmode connections #114
  • https://github.com/kartoza/docker-postgis#basic-configuration
• AND add extra strong password ( >= 40 random characters )
• AND limit your database public access
  • limit IP range
  • https://github.com/kartoza/docker-osm/blob/develop/docker-compose.yml#L23

see more: docker-library/postgres#770 (comment)

[NyakudyaA]

@ImreSamu can you please try the latest image. The 13.0 image hasn’t been updated and we generally do no back port any changes into stable images so that we do not break production environments.

try the image 13-3.1

[ImreSamu]

@NyakudyaA :

can you please try the latest image.

IMHO: This is the latest ( updated 9 hours ago ) and I can' see the kdevtmpfsi inside.

kartoza/postgis:13 == kartoza/postgis:13-3.1

$ docker images | grep kartoza
kartoza/postgis                         13              67256cd5559a   9 hours ago     1.61GB
kartoza/postgis                         13-3.1          67256cd5559a   9 hours ago     1.61GB

$ docker exec -it  kpostgis13 bash -c "apt list --installed | grep postgis"

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

postgresql-13-postgis-3-scripts/now 3.1.2+dfsg-1~exp2.pgdg110+1 all [installed,local]
postgresql-13-postgis-3/now 3.1.2+dfsg-1~exp2.pgdg110+1 amd64 [installed,local]

[NyakudyaA]

@ImreSamu it looks like your machine had been compromised. https://brycematheson.io/how-to-permanently-kill-and-remove-kdevtmpfsi-kinsing/

The most likely reason that popped up in your image is that you might have been using the default password which is used within the image.

someone would have maliciously started that process .

As a security guide you will need to use

• strong password
• Expose the Postgres port if you really need to use it.
• Restrict ip ranges in pg_hba
• Use docker secrets etc

[ImreSamu]

@NyakudyaA

@ImreSamu it looks like your machine had been compromised.

???? No; NO - not my machine!

On the other hand - probably @jbjuin machine.

[jbjuin]

@ImreSamu thanks for the insights.

My configuration was: postgres 13 in a container with a 80 characters password, but no SSL and no ip restriction.

I was just trying to reverse proxy tcp with traefik and had troubles getting it working... when it finally worked it was late in the day and I just let everything "as is". So the DB was opened on 5432, no ip whitelist, no SSL but a strong password, no client connecting "officialy" to it. I still can't figure out how they breach into the machine... any idea ? They had to break in postgres (password length of 80 characters) and execute the miner from within postgres ?

This DB is just OSM data so nothing important for us. We can just reinstall the OS if needed.

Anyway I will put in place all restrictions as I would have done if I had the time to do it properly... I just did not expect this to happen so quickly.

Thanks !

[ImreSamu]

Anyway I will put in place all restrictions as I would have done if I had the time to do it properly... I just did not expect this to happen so quickly.

Be more careful next time!

[timlinux]

In addition, if you do not enable SSL, your passwords are transmitted as clear text for which a strong password will offer no benefit.