Serious Security: Don’t let your SQL server attack you with ransomware

If crooks want to sneak into your system, they have quite a few choices.

They could do some serious hacking, using vulnerabilities and exploits to bypass the security checks you already have in place and tricking your servers into running software they’re not supposed to.

Or they could find out how to get in without any low-level jiggery-pokery, using an official entrance and using official system commands.

That’s a bit like taking a taxi to a bank robbery instead of using a stolen car – it’s not a very gangster thing to do, but you won’t trigger any licence plate cameras on the way.

As regular readers will know, one of the popular vehicles for malware crooks at the moment is Windows RDP, short for Remote Desktop Protocol.

Sadly, we’ve written many times in recent years about RDP security lapses that allow crooks to come into your network as if they were real sysadmins…

…except that instead of fixing things, they break them instead, and then demand money to make good the damage.

But RDP isn’t the only popular way in for crooks.

We recently published honeypot research looking at SSH attacks, where SSH stands for Secure Shell, a remote access system that’s even more widely used on Linux and Unix than RDP is on Windows.

(SSH is also popular on Windows servers, but doesn’t have the close-to-100% adoption that it does on their Unixy cousins.)

Our research painted a clear picture of just how much energy cybercrooks are prepared to expend to get into your network using unexceptionable methods.

Using otherwise legitimate tools for illegal entry not only opens up cybercrookery to a much wider set of attackers, but also sidesteps the risk of triggering exploit detections or causing a server crash.

Unfortunately, the crooks aren’t satisfied just using SSH and RDP as general-purpose attack tools.

There are many other online services – including some you might not expect – that are as good as a command prompt, if only you can connect to them in the first place.

For example, an insecure MySQL server isn’t just the road to a data breach.

It’s also a highly effective, if unorthodox, alternative to RDP or SSH for running software remotely.

Here’s a fascinating example captured recently by a SophosLabs honeypot that was listening out on TCP port 3306, the default access port for MySQL.

The mocked-up server pretended to be an insecure instance of MySQL that hackers could find, probe and connect to.

Honeypots deliberately attract hackers in order to keep track of the attack techniques that crooks are currently using – within limits, of course, because the honeypot mustn’t allow the crooks to do any actual harm.

Honeypot operators have to be careful to be part of the solution without becoming part of the problem. For example, if you’re trying to lure in spammers with what looks like a zombie computer that’s ready and waiting to blast out unwanted emails, you need to go far enough to let the crooks construct the messages they want to send, to add the attachments they want to distribute, and to reveal how many people they want to spam. But you mustn’t allow any of the dodgy messages to get out, or else you’re giving the crooks a free spamming service.

In the SQL-based attack captured by SophosLabs, the crooks tried to turn the honeypot’s MySQL server into a remote code execution robot, using a sequence like this:

1. Connect to the server.
2. Guess the credentials of an authorised user and log in.
3. Create an innocent-looking database table and add a text record consisting of text that’s actually a Windows executable file in hexadecimal.
4. Decode the hexadecimal data and save it as a local file called cna12.dll. (A DLL is a special sort of Windows program designed to be loaded by an application that’s already running to add extra features.)
5. Instruct the server to load the new DLL as a MySQL plugin known as a User Defined Function (UDF),
6. Call a function in the new plugin to fetch and run malware using HTTP.

Simply put, the crooks used MySQL as a general-purpose remote code execution zombie, thanks to MySQL’s official UDF plugin system that allows additional features be sucked into the server at runtime.

The attack wasn’t particularly sophisticated because the crooks failed to notice that the honeypot was running Linux, and uploaded executable code specific to the Windows version of MySQL.

Nevertheless, if the server had been running Windows then the HTTP download in step 6 above…

…would have unleashed ransomware known as GandCrab.

For a detailed breakdown of the techniques used in this attack, and for IoCs (indicators of compromise) you can use to check for similar probes on your own servers, please read the technical analysis on our sister site, Sophos News.

What to do?

Received wisdom says you shouldn’t be vulnerable to this sort of attack.

The massive global outbreak of the SQL Slammer virus back in 2003 should have taught us all to keep our SQL servers insulated from the internet, and the abuse potential of MySQL’s UDF feature has been well-documented for about as long.

But the fact that we’re still capturing unsophisticated, automated attempts to break in via internet-facing SQL ports is a reminder that we’re still making old mistakes.

So here’s what to do:

• Make sure your SQL servers aren’t directly accessible from the internet. If they are, that’s almost certainly a mistake. If it isn’t a mistake, it’s such a bad idea that you need to find another way to access them remotely. Consider using a VPN or SSH as the first point of entry instead, and insist on 2FA for all your users.
• Pick proper passwords. The attack described here can’t be pulled off by an unauthenticated user, so don’t take chances with weak passwords. Even if your SQL server is only accessible internally, you don’t want just anyone to be able to login easily, especially as a privileged user.
• Check your MySQL access control settings. Only users with INSERT rights into the core mysql database can load new UDFs, so anyone who could mount this attack already has enough power to do plenty of other bad things. (It would be nice to have the option to turn UDFs off if you never use them, but we can’t find a way to do that. The only trick we can find to inhibit UDF loading is to build your own statically-linked version of mysqld from source code.)
• Consider penetration testing. You probably know all the defensive strategies listed above, and try to follow them, but it’s worth checking that you have applied them correctly. Mistakes happen, and if you don’t look out for them, someone else certainly will.

Stay secure – batten down the hatches, and then check that the battens were fitted correctly.