zlacker

>>todsac+(OP)
I think I'm missing something here - what is specific about Docker in the exploit? Nowhere is it mentioned what the actual exploit was, and whether for example a non-containerized postgres would have avoided it.

Should the recommendation rather be "don't expose anything from your home network publically unless it's properly secured"?

>>mathar+q3
From TFA:

> This was somewhat releiving, as the latest change I made was spinning up a postgres_alpine container in Docker right before the holidays. Spinning it up was done in a hurry, as I wanted to have it available remotely for a personal project while I was away from home. This also meant that it was exposed to the internet, with open ports in the router firewall and everything. Considering the process had been running for 8 days, this means that the infection occured just a day after creating the database. None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet. Ofcourse I password protected it, but seeing as it was meant to be temporary, I didn't dive into securing it properly.

Seems like they opened up a postgres container to the Internet (IIRC docker does this whether you want to or not, it punches holes in iptables without asking you). Possibly misconfigured authentication or left a default postgres password?

>>phoron+o5
> Seems like they opened up a postgres container to the Internet

Yes, but so what? Getting access to a postgres instance shouldn't allow arbitrary execution on the host.

> IIRC docker does this whether you want to or not, it punches holes in iptables without asking you

Which is only relevant if you run your computer directly connected to the internet. That's a dumb thing to do regardless. The author probably also opened their firewall or forwarded a port to the host, which Docker cannot do.

>>globul+f6
Are you sure about that? Last I checked pg admins had command execution on the DB host, as well as FS r/w and traversal.

See https://www.postgresql.org/docs/current/sql-copy.html#id-1.9...

Specifically the `filename` and `PROGRAM` parameters.

And that is documented expected out of the box behaviour without even looking for an exploit...

>>phoron+xc
It's funny that you said TFA a few comments earlier, because you seem to have not read the article either, or are making some great leaps here.

If the break in happened as you would explain the article would also mention that:

* the attacker gained access to the postgres user or equally privileged user

* they used specific SQL commands to execute code

* would have not claimed the vulnerability was about docker containers and exposed ports

And the take away would not be "be careful with exposing your home server to the internet", but would be "anyone with admin privileges to postgres is able to execute arbitrary code".

>>63stac+921
The article would only say that if OP was competent enough to determine exactly what went wrong. I did read the article however I do not agree with the conclusions in it as simply opening a postgres port to the Internet while having set up authentication correctly, is not fatal (though admittedly inadvisable).