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.
4. Don't let your DB host make outbound connections (iptables/ip6tables)
Which can also be prevented with SELinux
So, the takeaway would be to control, which functionality is needed and which not, then to take action accordingly.
Secondly, things like lo_export() should be disabled by default.
It does require privileges.
> Secondly, things like lo_export() should be disabled by default.
It's superuser only.
This means that real attackers are attempting right now.
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.
- 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).