One of the biggest news stories of 2017 on the MySQL front was unfortunately not a good one. In February, hundreds of MySQL databases were erased and replaced with a ransom demand for 0.2 bitcoin, or about $234 US dollars at the time. At least it wasn’t as bad as the previous month, when tens of thousands of MongoDB installations were eradicated and replaced with ransom demands!
When bad things like this happen, it’s all-too-easy to start pointing the finger of blame. Was it the business’ fault? Did Oracle, the makers of MySQL, play a role? Perhaps the hackers were bad people? Perhaps. The fact is that cybersecurity is a complex and multi-faceted issue. As DBAs, we can control certain aspects of our databases infrastructure and not others. In today’s article we’ll explore how databases were compromised and extrapolate a few best practices for protecting our own MySQL installations from malicious entities and from falling prey to ransomware attacks.
How Hackers Infect Databases with Ransomware
Ransomware attacks are not all that different from traditional cyber-attacks except that the hackers leave a file on the infected machine with instructions for recovering the data.
The history of ransomware attacks can be traced back all the way to the late eighties, with the “AIDS Trojan”. Starting from around 2012 the use of ransomware attacks has grown exponentially. However, it was not until very recently that attackers began targeting databases, first MongoDB, then MySQL. The latest attacks relied on brute-force guessing of the root password for MySQL instances
In a surprising twist, it appears the attackers, whilst offering a promise to restore data, were in fact just deleting the database records. There is at least one documented incident in Adelaide where a business paid the ransom and NO data was restored.
There are three primary methods used to attack databases to either corrupt or tamper with data:
- SQL/NoSQL – inside attack:
By gaining access to the database, whether through brute force, a DBA account that was compromised or even a disenfranchised insider who already has access, an attacker can execute all admin operations – drop/insert/update – and hence modify or delete the data. This can be done with just a few simple SQL transactions/NoSQL commands.
- SQL/NoSQL – external attack:
A web application vulnerability to SQL Injection or NoSQL injection allows attackers to execute SQL statements with administrator-level privileges.
Another method for external attackers is to target databases with public IP. This can be easily done with online services like Shodan.
- Encrypting the database file:
The database file is where the database schema and data are stored. This type of attack is exactly the same as traditional ransomware attacks that target files. The only caveat, from the ransomware point of view, is that it must terminate the database process before encrypting, as it holds the database file, making it unmodifiable to other processes while in use.
Tips for Keeping your Data Safe
In a few cases, the ransomware attack capitalized on an unpatched vulnerability. However, upon reviewing the thousands of combined MySQL and MongoDB ransomware attacks in 2017, investigators determined that the underlying security weakness in the vast majority of cases was either gaping holes in security protocols or an almost complete lack thereof! It was as if businesses had installed nearly indestructible alloy locks, only to leave their doors wide open for anyone to come in and do whatever they wished with the data. To recap, these databases, which often housed sensitive and private information, were exposed to the Internet without even the most rudimentary of security mechanisms in place.
With those unsettling details out of the way, there is a silver lining, in that DBAs do not have to re-educate themselves on a bunch of new protocols and security measures; all they have to do is take the time to implement the same ole’ security precautions that have been public knowledge for years.
So how does an application database go into production with scarcely any security safeguards whatsoever?
According to Oren Eini of Hibernating Rhinos LTD, an Israeli-based company producing developer productivity tools for OLTP applications, it’s that developers typically setup the database in production, rather than the operations staff, which control and maintain the production environments for the organization:
In practice, in many cases, the person who developed the application is also responsible for setting it up in production. That can be a problem from a security point of view. The easiest thing to do is to simply repeat the same development setup procedure (after all, we know it works) in production and configure the database to accept remote connections as well.
Here are a few basic guidelines for MySQL-backed applications exposed via the Internet:
- Configure firewalls to prevent direct access to databases from the internet. Only allow connections from required applications and users;
- Ensure database admin accounts have complex passwords of at least 16 characters in length, consisting of as a minimum a combination of uppercase, lowercase and numeric;
- Check database user accounts that they do not have excessive privileges to delete database tables and records;
- Make sure your database backup and restore processes are tested;
- Ensure database logging of table/record deletions is sending appropriate alerts to IT support;
- Check with your third-party providers in case they are providing you web applications or online services which use MySQL to store your business information. If so, have them confirm they use a complex password policy for admin access and that they backup the database every day and have a 7-day cyclic procedure.
Conclusion
In today’s article we learned how MySQL databases were compromised by ransomware attacks in 2017 and outlined a few tips for protecting our own MySQL installations from malicious entities. As we saw, the key is to treat your data very differently when it is migrated from an internal development environment to the public production server(s).
