A Deep Dive into Database Attacks [Part III]: Why Scarlett Johansson’s Picture Got My Postgres Database to Start Mining Monero

As part of Imperva’s efforts to protect our customers’ data, we have an ongoing research project focused on analyzing and sharing different attack methods on databases. If you aren’t familiar with this project, which we call StickyDB, please read Part I and Part II. There we explain this database honeypot net (Figure 1), which tricks attackers into targeting our databases so we can all learn from it and get more secure.
We just saw an interesting attack technique applied to one of our PostgreSQL servers. After logging into the database, the attacker continued to create different payloads, implement evasion techniques through embedded binaries in a downloaded image, extract payloads to disk and trigger remote code execution of these payloads. Like so many attacks we’ve witnessed lately, it ended up with the attacker utilizing the server’s resources for cryptomining Monero. As if this wasn’t enough, the attack vector was a picture of Scarlett Johannsson. Alright then. Let’s take a deep dive into the attack!

(Also, check out the whitepaper from the Ovum research team, “A Buydown for Risk: Why Data Security is a Must,”where you can learn how to invest in cost-effective data security strategy that better protects your most vital asset than core or edge security ever will.)

Figure 1: The StickyDB honeypot net environment

Establishing Remote Code Execution and Evading DAM Solutions

PostgreSQL, like other common databases, has a metasploit module to ease interaction with the operating system. The method used in this attack is very similar – creating a payload in runtime by dumping to disk the binary code using lo_export function. One slight change has been taken in this module and it’s inserting the lo_export function as an entry in pg_proc catalog instead of making a direct call. This is in order to evade some database audit monitoring (DAM) solutions that closely monitor privileged operations attempts like lo_export. So using obj6440002537 is basically an indirect call to lo_export (Figure 2).

Figure 2: Evasion technique of indirect call to lo_export

“OK, I took control of your database. Now which GPU do you have?

Now the attacker is able to execute local system commands using one simple function – fun6440002537. This SQL function is a wrapper for calling a C-language function, “sys_eval”, a small exported function in “tmp406001440” (a binary based on sqlmapproject), which basically acts as proxy to invoke shell commands from SQL client.
So what will be next steps of the attack? Some reconnaissance. So it started with getting the details of the GPU by executing lshw -c video and continued to cat /proc/cpuinfo in order to get the CPU details (Figures 3-4). While this feels odd at first, it makes complete sense when your end goal is to mine more of your favorite cryptocurrency, right?

Figure 3: Checking the GPU details

Figure 4: Checking the CPU details

Up until now, the attacker has gained access to the database, established a way for remote code execution as well as evading DAM solutions and learned about the system details. Now it is all set up to… download a picture of Scarlett Johansson?! Wait, what?

A malware payload masquerading as Scarlett Johansson’s picture

Attackers are getting more and more creative I must say.
In this case the attackers wanted to download their latest piece of malicious code, so they hosted it as an image in imagehousing.com, a legit place to host and share your images freely. However, the payload is in binary format and not an image. Renaming your binary to have an image extension will most likely fail during upload to the image hosting provider for the very simple reason that it is not a valid, nor viewable, picture – so no preview and no picture. Instead of renaming the file extension, the attacker appended the malicious binary code into a real picture of the lovely Scarlett Johansson (Figure 5). This way the upload succeeds, the picture is viewable, appears benign and the payload is still there.

Figure 5: The payload. When opening it, it appears as benign picture. No worries – this picture in this blog is clean, that’s for sure!

Do you see the binary code? It’s right below her left elbow! 🙂
We contacted imagehousing.com about the issue and the image has been deleted.

From downloading a picture to cryptomining monero

So downloading the image (art-981754.png) with the payload was easily done with wget. Extracting the executable out of this image was done with dd (data duplicator) command and setting execution permissions, actually full permissions (chmod 777) to the newly created file – x4060014400. The last step is to run this just newly extracted payload, and all in SQL, as follows –

Figure 6: How to use SQL to download a picture, extract binary payload out of it and execute it

The x4060014400 file creates another executable, named s4060014400. This executable’s goal is to mine Monero (XMR) to the Monero pool at https://monero.crypto-pool.fr/, IP 163.172.226.218 (Figure 7). This attack’s Monero address has done more than 312.5 XMR so far, valued with more than $90,000 to date. Its address is:
4BBgotjSkvBjgx8SG6hmmhEP3RoeHNei9MZ2iqWHWs8WEFvwUVi6KEpLWdfNx6Guiq5451Fv2SoxoD7rHzQhQTVbDtfL8xS

Figure 7: SQL statement to start mining Monero

And of course when done, clean up takes place –

Figure 8: Cleaning up file traces

From the attacker’s standpoint: Mission accomplished!

Do antiviruses identify these malicious pictures?

Using Google’s VirusTotal, we checked the detection rate of almost 60 antiviruses with three different forms of the cryptominer in this attack – the URL that hosted the malicious image, just the malicious image and just the cryptominer. The results are:

• The URL which hosted the malicious image: One antivirus alerted it is malware (Figure 9)
• The malicious image: Three antiviruses alerted on coinminer (Figure 10)
• The extracted cryptominer from the malicious image: 18 antiviruses detection (Figure 11)

Figure 9: One antivirus detected the malicious URL
 
Figure 10: Three antiviruses detected the malicious picture

Figure 11: Eighteen antiviruses detected the cryptominer
Using this trick of appending binary code to legit files (images, documents) to create such a mutated file is a really old-school method, but it still bypasses most of the antiviruses, which is shocking.
And creating such a mutated file is as simple as this one-liner:
Linux: cat myExecutableFile >> myImageFile.png
Windows: type myExecutableFile.exe >> myImageFile.png

How can an attacker find PostgreSQL databases?

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 can attackers find easier targets? What about publicly exposed PostgreSQL databases? We know it is bad practice, but are there any such databases out there? Well, yes, at least 710,000 of them, heavily hosted on AWS (Figure 12). And finding them is as easy as a Googling experience using online services like Shodan. So an attacker can easily find those, try to brute force the default postgres user in order to get in and then apply some of the techniques we described.

Figure 12: 710K PostgreSQL instances with public IP address. Credit: shodan.io

We’ll discuss more attacks in the next article in this series. The last article will be all about attack mitigations, but here are a few quick tips to help you avoid getting hit with this attack

• Watch out of direct calls to lo_export or indirect calls through entries in pg_proc
• Beware of functions calling to C-language binaries (as in Figure 2)
• 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 (application server or clients owned by DBAs)