Skip links

What’s worse than paying an extortion bot that auto-pwned your database?

Publicly exposed PostgreSQL and MySQL databases with weak passwords are being autonomously wiped out by a malicious extortion bot – one that marks who pays up and who is not getting their data back.

Origin unknown, the bot is routinely breaching poorly protected databases within hours of exposure to the internet, according to security researchers at Border0.

In repeat experiments that involved running a PostgreSQL server on a VM, all while using weak credentials (user: postgres, password: password), the bot was successfully compromising the dummy databases multiple times a day.

The investigation started after programmer Amos Wenger, tweeted (X-ed?) about his database apparently getting ransomed “immediately” after accidentally exposing their Postgres server.

The bot scans the internet for PostgreSQL and MySQL servers before looking inside for databases that can be brute-forced. 

Once inside, the number of tables available is determined and a snapshot of the database is taken before all tables and databases are deleted using ‘DROP TABLE’ and ‘DROP DATABASE’ commands.

The bot also terminates all backend processes connected to any database other than its target, which is presumably done to prevent admins from interrupting the attack.

After the damage is done, a ransom note is left behind, instructing victims to pay a fee to regain access to their data.

The ransom note begins with: “All your data is backed up” – which is a lie, researchers discovered. Analyzing the bot’s queries showed that in “backing up” the data before dropping all tables, it only saved the first 20 rows for each table, meaning victims that do pay the ransom will never recover all of the deleted data.

A glance at the blockchain reveals the bot has indeed managed to trick some victims into paying, netting just over $3,000 from six victims in just one week.

Once paid into the digital wallet specified in the ransom note, the crypto is shuttled to a separate wallet stocked with $2,950,489 worth of Bitcoin, at least at the time of writing. 

The secondary wallet has been up and running since August 25, 2021, and routinely receives multiple daily payments in the thousands of dollars, suggesting the possibility that the database bot is being run by an individual or group that engages in other, more lucrative avenues of cybercrime.

Although the experiment was run using only Postgres servers, the researchers also discovered a similar campaign targeting MySQL databases with traffic originating from the same /24 range.

The IP address is from Dutch hosting provider Limenet but the inclusion of a Russian domain in the ransom note suggests the attacker is trying to conceal their true location.

As with the Postgres campaign, the MySQL bot claims to back up all the victim’s data, but instead only saves the first ten rows of each table and demands a recovery fee of 0.017 Bitcoin – roughly double the fee demanded by the Postgres bot.

“As a last step, the bot attempted to bring the MySQL server to a halt using the ‘SHUTDOWN’ command – a clear sign of its calculated and destructive intent, something that will undoubtedly get your attention,” the Border0 team said.

Security expert Kevin Beaumont additionally highlighted that similar bots are targeting SQL databases too, but offered no further details.

This type of malware isn’t novel – Unit 42 at Palo Alto Networks drew attention to similar activity last year – but the speed of the exploits has surprised onlookers.

Reg readers will know, generally speaking, that it’s best to avoid exposing a database to the public internet, although we all know that it very occasionally happens from time to time to time to time

There are millions of public-facing Postgres and MySQL servers: Shodan scans carried out by Border0 found more than 800,000 for Postgres and more than 3.2 million for MySQL.

Granted, some of these may be honeypots but in all likelihood, that’s still a nice big pool of targets for an extortion bot.

“It’s not surprising to see many open database services in the public cloud,” the researchers said. “If you run your database in say DigitalOcean or even AWS, then these cloud providers don’t always make it easy to access your database from your desktop, or even a workload running in a different region or provider. You may have no other option than to open it from anywhere. And so, while bad practice,  it’s not all that surprising that there are that many open databases.

“Also, for Docker users, it’s important to know that using docker run -p to publish a container’s port alters your iptables rules for DNAT-based port forwarding. This Docker feature manages external communication for containers, overriding any default deny settings in your iptables INPUT table, thus making the port accessible publicly.”

For those who do insist on publicly exposing their databases, using a strong password to protect it will go a long way in preventing you from becoming a victim of ongoing brute force attacks. ®

Source