Repository navigation
Docker hub image for version 12.4 contains cryptominer #767
Description
After ~3 days of uptime postgres process spawns 8 processes with autogenerated names like "0DJbp5eh" which eat up all CPU cores and RAM. Also this processes open connection to Hetzner (136.243.90.99) with some sort of "empty" http server which listens on 80 and 8080 ports.
Activity
wilhelmjung commentedon Sep 29, 2020
The official image?
Antender commentedon Sep 29, 2020
Yes, the "official" one.
ImreSamu commentedon Sep 29, 2020
related: #664 (comment)
tianon commentedon Sep 29, 2020
Indeed, this is most likely due to having your instance exposed on the public internet (or you have an attacker within your network, such as another previously compromised machine), and you've suffered a compromise.
Antender commentedon Sep 29, 2020
I don't think that's the case: this problem manifest by the schedule on 4 different unrelated machines in different networks (3 dev workstations and CI) and only after delay. Delay is always the same, approximately 3 days. Our company is switching to another image, so if issue is resolved, then your "official" image is definitely compromised.
Antender commentedon Sep 29, 2020
BTW, one of workstations has ufw rules that block all traffic except for incoming ssh, and postgres container isn't permanently up, but cryptominer still starts if I forget to shut down this container for the weekends.
tianon commentedon Sep 29, 2020
When you forward a port on a Docker container, Docker uses
iptablesdirectly to expose that port externally, so it is very likely bypassing all ufw rules unless you've gone to extra effort to ensure the Docker chain happens after the ufw one (and then maintain/verify that ordering periodically).tianon commentedon Sep 29, 2020
Additionally, the source code for our image is completely open and available for review here -- you should be able to trivially build it locally as well, if you suspect that our builds are the culprit. I think you'll find that Docker has bypassed your firewall.
Alternatively, you could try adding a more complex password for any/all users on the database instances, which should also be a deterrent.
Antender commentedon Sep 29, 2020
Can you, please, recomend a way to sandbox docker build process, so I can ensure it isn't downloading anything malicious? Your build script while being opensource looks obfuscated.
tianon commentedon Sep 29, 2020
It's not "obfuscated" as such, but it is a little bit complicated because it needs to build from source for architectures that the PostgreSQL project doesn't publish official release binaries for.
Doing
docker buildalready does some amount of sandboxing, but if you want to also sandbox the network accesses you'll have to pre-download all the files it needs (local Debian mirror, local PostgreSQL APT repo mirror, etc).For help with these things (and with mitigating your other issues), I would recommend a dedicated support forum such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow.