6 ms·
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 the
by craigkerstiens 9y ago
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/ 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).
- tonmoy 9y agoThe first paragraph mentions that this is a honeypot
- misterman101 9y agoThe server is a honeypot run by Imperva. This means that real attackers are attempting right now.
- Cthulhu_ 9y agoThe article does mention there's a lot of monero in the indicated wallet.
- PinguTS 9y agoActually, 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.
- craigkerstiens 9y agoAh, yes. pl/c was the culprit it seems more than some other known vulnerability, updated original accordingly.
- cryptonector 9y agoWell, 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.
- anarazel 9y ago> 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.
- postila 9y agothings like superuser should be disabled by default (only DBA needs superuser access, not anybody else).
- chucky_z 9y agoRDS supports some random PL stuff, specifically PL/Perl and PL/v8 it seems.
- craigkerstiens 9y agoRDS supports one that do not run as superuser and run sandboxed. pl/perl and pl/v8 are great procedural languages because of that reason.
- Animats 9y agoThe 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.
- deleted 9y ago[deleted]
- merb 9y agoonly 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..
- zzzeek 9y ago> 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.
- favorited 9y agoYup. 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.
- sdeziel 9y ago3. 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)
- emmelaich 9y ago> Don't let your DB host make outbound connections Which can also be prevented with SELinux
- postila 9y agoAlso: 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 ... && ...'`