Imperva, a provider of data and application security solutions, is actively running a research effort with the express goal of identifying attack methods on databases. They call their project StickyDB, a database decoy designed to deceive a would-be hacker into targeting their databases. Once hackers engage the database decoy and reveal their methods, Imperva has more knowledge to counter new exploits and harden their customer’s data security.
Targeting a Database Decoy
Recently, the Imperva research team uncovered a technique targeted at their database decoy leveraging code inside a photo of Scarlett Johansson, code that was only meaningful to the program downloading it. The exploit targeted an Imperva PostgreSQL server and was designed to mine Monero cryptocurrency.
The layers of intrigue have all the makings of a compelling story: counter-intelligence, malicious intent, a beautiful actress, and hacking. But what are the true implications of this? The Imperva research team does not allege any flaws in PostgreSQL. In fact, Imperva left their PostgreSQL server open for attack. This is the equivalent of saying, "I left my keys in the car and somebody stole it! And when I got it back it was full of pictures of Scarlett Johansson!"
Imperva describes their findings in this article. Our EDB Postgres team read the article and found the exploit technique interesting. Did this attack only work because PostgreSQL was set up for trust and peer authentication? Did the success of the attack require a brute-forcing of the super user account? Was there an obvious Postgres setting that would reduce the threat of this vulnerability? The Imperva article is a bit confusing since it jumps right into how the exploit uses Postgres and an image to mine cryptocurrency. However, to truly understand it, you have to examine how this started.
How Did We Get Here?
To start, a computer must have been broken into using a method not yet documented and also unrelated to Postgres or any particular image. The attacker would then have had to download a script on a local machine, again unrelated to Postgres or images. They would have then scanned the Internet looking for Postgres servers, and in the case of Imperva, the database was set up to be found.
An attempt to discover PostgreSQL instances in a domain can be done using discovery tools, such as Nmap, considering the attacker is inside the local network already. But attackers can find easier targets, like publicly exposed PostgreSQL databases. We know it is bad practice, but there are at least 710,000 publicly exposed PostgreSQL databases out there, hosted on AWS (see Figure 12 in this article). And, finding them is as easy as using online services like Shodan. Once found, an attacker can try to brute force the default Postgres user in order to get in. Once in, they can then apply some of the techniques described.
Notice our use of "brute force the default Postgres user" wording. The attackers are not doing anything except scanning the Internet for vulnerable systems. These might be test servers or empty databases, where the owner does not care if someone can connect as a superuser. But of course we all know there are lots of things a superuser can do, even if there is no valuable data in the database, and this is an example.
The Imperva article goes on to show the hacked Postgres superuser checking to see if the Postgres server has a graphics card that would make cryptocurrency mining efficient. The attacker then uses Postgres to download an image that has a cryptocurrency mining executable appended to it. It then strips out the executable and runs it on the Postgres server.
We encourage you to read this Hacker News thread as well, which illustrates and clarifies a lot of the confusion.
Simple Steps to Avoid Getting Hit
In short, if you want to avoid getting hit with this attack, here are a few simple guidelines. It is never safe to allow a Postgres server to be open to the Internet in an insecure way. The Imperva article makes the following recommendations:
-
Use a firewall to block outgoing network traffic from your database to the Internet
-
Make sure your database is not assigned with public IP address. If it is, restrict access only to the hosts that interact with it, such as application server or clients owned by DBAs.
-
Watch out for direct calls to lo_export or indirect calls through entries in pg_proc
-
Beware of functions calling to C-language binaries
And we are compelled to state the obvious:
-
Do not use a database server as your email or web client
-
Do not download content on to your PostgreSQL servers
-
Do not set production servers up for trust or peer authentication
If you have any additional questions, feel free to reach out to our team at info@edbpostgres.com for more information and guidance.
Marc Linster, Ph.D., is Senior Vice President, Product Development, at EnterpriseDB.