Comment by craigkerstiens | Hacker News Reader

Comment by craigkerstiens | Hacker News Reader

The short story of this is:

- Gain access to the database itself

- And the Postgres database should be vulnerable to various remote code execution

- Once they're able to execute code remotely, they then download an image which has binary data tacked onto it

- They then parse out the executable part of the image using dd

- Then they're able to execute and mine away

While an interesting read the shortest takeaway is:

1. Don't leave your Postgres open to the public internet and

2. Ensure to upgrade when security releases come out.

If you're unsure if the version your on has security patches available or other reasons to upgrade consider checking out https://why-upgrade.depesz.com/

Edit: Looks like the user that gained access had ability to execute pl/c. Which has to run as superuser. You won't find things like pl/c, pl/python generally supported on most Postgres services like Heroku, RDS, Citus because of just this reason. So in this case database access with pl/c was enabled, suspect could have been done equally via other vectors (once database access was achieved).

> 1. Don't leave your Postgres open to the public internet and

you need to do better than that, since attacks within the firewall can occur as well, and this is probably a more common vector for corporate espionage these days. A compromised laptop can get a wide open remote exploit onto a companies' production environment if the database itself is open within the firewall.

Yup. Your database (as well as the majority of ports for other hosts) shouldn't be available from your corporate network either. 99% of corporate users don't need network access beyond a few ports to most hosts.

3. Don't let your DB engine execute random executable like wget/dd (Apparmor/SELinux)

4. Don't let your DB host make outbound connections (iptables/ip6tables)

> Don't let your DB host make outbound connections

Which can also be prevented with SELinux

Actually, the takeaway is not about updates. Because the problem is actual intended functionality, that is "misused" for other purposes: indirect function calls.

So, the takeaway would be to control, which functionality is needed and which not, then to take action accordingly.

Ah, yes. pl/c was the culprit it seems more than some other known vulnerability, updated original accordingly.

Well, for one thing, inserting into pg_catalog tables without DDLs should require privilege and be audited.

Secondly, things like lo_export() should be disabled by default.

> Well, for one thing, inserting into pg_catalog tables without DDLs should require privilege and be audited.

It does require privileges.

> Secondly, things like lo_export() should be disabled by default.

It's superuser only.

things like superuser should be disabled by default (only DBA needs superuser access, not anybody else).

The first paragraph mentions that this is a honeypot

The server is a honeypot run by Imperva.

This means that real attackers are attempting right now.

The article does mention there's a lot of monero in the indicated wallet.

The real problem is that Postgres will let you load C functions to run in the server context. That's inherently a bad idea.

Your databases should have multiple users configured with limited roles. Nothing web-facing should have a user with the ability to create a function. A SELECT-only user is a good start.

only the server administrator can do that. (i.e. users with server admin role) as far as I know thats forbidden on aws rds, i.e. to load c functions..

Also: 3. Ensure that you don't use or provide anybody superuser in Postgres. (Otherwise, there is much simpler way to download&run anything that explain in the article – just `copy tablename from program 'wget ... && chmod a+x ... && ...'`

RDS supports some random PL stuff, specifically PL/Perl and PL/v8 it seems.

RDS supports one that do not run as superuser and run sandboxed. pl/perl and pl/v8 are great procedural languages because of that reason.

Reply on news.ycombinator.com