- 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.
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.
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.
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 ... && ...'`
- 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).