Three Easy Ways to Avoid Meow-like Database Attacks

In the recent Meow attacks, more than 1,000 exposed databases on the Web were wiped by unknown actors who deleted entire repositories, leaving only the word "meow" behind. To the average person the deletion of entire databases, and the leaving of a calling card each time, sounds like the work of master hackers with catastrophic potential. While theatrical and a blow to the database owners to be sure, these attacks happen a lot and should not come as such a huge surprise.

Upon closer examination these breaches affected the database providers' "light versions" rather than the full versions. A light version has limited functionality and is made available for free on a website. DBAs and developers that aren't security focused and don't have a team/process for thinking through security controls tend to set up in these light versions, storing sensitive data but generally neglecting to turn on important but basic security features such as authentication. As a result, anyone can log in - you don't even need a username. 

Serious DBAs, people who truly care about database security, generally do not install anything – freemium or otherwise – without requiring authentication. They also don't generally install things on the public Internet. The people whose data was destroyed by Meow attacks hadn't even addressed the bare minimum for security, let alone what would be described as adequate security. So a breach is not all that surprising.

Those Who Know Don't Speak
Databases by their nature are where companies store their data, and so any attack against them is more serious as it could expose sensitive information, and a lot of it. When the headline reads "1000+ Databases Deleted in Mysterious Attack," it makes sense that the story would catch the public's attention. It's a sexy headline that would interest even a general reader, however, in this particular case the headline is more dramatic than the actual event. 

The overall level of sophistication with these attacks is relatively low and poses little threat to properly configured and secured databases. In this case the breach was as simple as scanning a default port in the servers and taking advantage of a situation where no username or passwords were required. It's something that doesn't take more than basic to average hacking awareness.

History shows us that the real issues around database security are far more sophisticated than what we see here, and breaches into properly secured databases are usually not readily acknowledged let alone discussed. In fact, even when a company is required to acknowledge a breach, they often won't discuss what exactly happened. Neither the company with the breach nor the company helping them with the investigation can discuss particulars, and so ironically the important attacks are not headline grabbing or publicly known. 

The largest problem facing database security today is the disconnect between the security teams and the DBAs beginning from the moment of configuration and continuing throughout the lifecycle of the database. If the person responsible for the configuration of the database were a security professional, then they likely would have paid greater attention to the basic security safeguards and ensured proper configuration. Unfortunately, in these cases the person who owns, configures, and manages these databases is a DBA or developer who needs the database. And because they often have no security background, they make obvious mistakes related to basic security issues.

Following the configuration, there remains a lack of clarity as to who is responsible for database security. Is it the person who created and uses the database or is it the security team? The answer should be a mix because ultimately neither is suited to the job alone. The DBAs responsible for creating and maintaining the repository don't know enough about security because it's not in their training, however security teams often don't understand the complexity of the data repository. When you secure operating systems in a typical environment, you are securing two operating systems, Windows and Linux. With databases you can be securing dozens, each with a different model and learning curve.

There is a major skill gap that exists in the world of database security. So few teams possess the institutional knowledge of how to secure the growing lists of databases in use today, and the issue is growing as the complexity of our environments continues to grow. That reality combined with poor security practices from DBAs, even on the most basic level, enables simple hacks like Meow to succeed and achieve far more than they ever should. While perhaps not as significant or eye opening a breach as many that we will never hear about, the flashy Meow breaches give us an opportunity to draw attention to the major underlying issues in database security to ensure that correct measures are put in place before real damage is caused.

Until then, DBAs or anyone managing a database should undertake the following three steps to significantly lower the chances of a breach like Meow: