zlacker

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+(OP)
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+Y1
> 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.

>>phoron+Y1
Docker would punch through the host firewall by default, but the database wouldn’t be accessible to the internet unless the user opened the ports on their router firewall as well, which based on the article, it sounds like they did. Making the assumption they’re using a router firewall…

In this case, seems like Docker provided a bit of security in keeping the malware sandboxed in the container, as opposed to infecting the host (which would have been the case had the user just run the DB on bare metal and opened the same ports)

>>globul+P2
Also from TFA:

> it was exposed to the internet, with open ports in the router firewall

Upvoted because you're right that the comments in this thread have nothing to do with what happened here.

The story would have been no different if OP had created an Alpine Linux container and exposed SSH to the internet with SSH password authentication enabled and a weak password.

It's nothing to do with Docker's firewalling.

>>globul+P2
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...

>>armsaw+D3
That's a bit of a stretch here... Had the attackers' target been to escape from the docker container, they would have done it. They may even have done it, we can't know as OP does not seem to have investigated thoroughly enough apart from seeing some errors and then stopping the container...

Also, had it been a part of the host distro, postgres may have had selinux or apparmor restrictions applied that could have prevented further damage apart from a dump of the DB...

>>globul+P2
I feel like you and grandparent are the only people who read the article, because I'm wondering the same thing.

The article never properly explains how the attack happened. Having a port exposed to the internet on any container is a remote execution vulnerability? What? How? Nobody would be using docker in that case.

The article links to a blog post as a source on the vulnerability, but the article is a general "how to secure" article, there is nothing about remote code execution.

>>echelo+l4
>The story would have been no different if OP had created an Alpine Linux container and exposed SSH to the internet with SSH password authentication enabled and a weak password.

What? The story would have been VERY different, obviously that's asking for trouble. Opening a port to your database running in a docker container is not a remote execution vulnerability, or if it is, the article is failing to explain how.

>>phoron+79
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".

>>mathar+(OP)
This is one that can sneak up on you even when you're not intentionally exposing a port to the internet. Docker manages iptables directly by default (you can disable it but the networking between compose services will be messed up). Another common case this can bite you is if using an iptables front-end like ufw and thinking you're exposing just the application. Then unless you bind to localhost then Posgres in this case will be exposed. My recommendation is to review iptables -L directly and where possible use firewalls closer to the perimeter (e.g. the one from your vps provider) instead of solely relying on iptables on the same node

>>phoron+Y1
Docker doesn’t expose ports by default. It only bypasses your firewall if you choose to explicitly publish a port.

OP explicitly forwarded a port in Docker to their home network.

OP explicitly forwarded their port on their router to the Internet.

OP may have ran Postgres as root.

OP may have used a default password.

OP got hacked.

Imagine having done these same steps on a bare metal server.

>>63stac+JY
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).

>>harral+mE1
I do imagine:

1. postgres would have a sane default pg_hba disallowing remote superuser access.

2. postgres would not be running as root.

3. postgres would not have a default superuser password, as it uses peer authentication by default.

4. If ran on a redhat-derived distro, postgres would be a subject to selinux restrictions.

And yes, all of these can be circumvented by an incompetent admin.

>>tommy_+1a1
All this talk of iptables etc is really confusing. People don't use iptables rules on servers do they? Ubuntu server has the option to enable ufw but it's disabled by default because it would be a really annoying default for a server which is by definition supposed to have services. I couldn't imagine trying to wrangle firewall rules across every box on the network vs using network segregation and firewall appliances at the edges. Is there some confusion here between running docker on your dev box vs running it on a server to intentionally run network services?

>>globul+pX1
Yes, they do. At least back when I was at ZEIT, docker definitely used iptables directly. I know this because I was patching them as part of our infra that managed Docker at the time.