Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:00 PM
Ron Bennatan
Ron Bennatan
Connect Directly
E-Mail vvv

Three Easy Ways to Avoid Meow-like Database Attacks

The largest problem facing database security today is the disconnect between security teams and DBAs beginning from the moment of configuration and continuing throughout the database lifecycle.

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: 

  • Use strong authentication practices in every situation where databases are concerned.
    In most instances, the vendor's product defaults to requiring authentication. Oftentimes DBAs and developers are in a rush to get a tool up and running and are tempted to cut corners to make a tool more easily accessible and meet a deadline. This is always a bad idea. Don't skimp on security.
  • Ensure that key people in the organization know who is responsible for database security.
    Frequently the people who own, configure, and manage these environments have no database security background. DBAs and developers need to communicate with and learn from their security teams to do things like define users, roles, and privileges based on principles of minimum-privileges to make databases as secure as possible. They must also decide who is accountable for overall database security.
  • Assume all the data in your database is potentially sensitive data.
    Identifying and securing sensitive data is something that even experienced security teams struggle with and some data often slips through the cracks. Security teams should work diligently to secure every database you install, regardless of what data you think it may contain. Better safe than sorry.

Ron Bennatan is CTO and co-founder at jSonar Inc. He has been a "data security guy" for 25 years and has worked at companies such as J.P. Morgan, Merrill Lynch, Intel, IBM and AT&T Bell Labs. He was co-founder and CTO at Guardium which was acquired by IBM where he later ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
Modern Day Insider Threat: Network Bugs That Are Stealing Your Data
David Pearson, Principal Threat Researcher,  10/21/2020
Are You One COVID-19 Test Away From a Cybersecurity Disaster?
Alan Brill, Senior Managing Director, Cyber Risk Practice, Kroll,  10/21/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-26
libtac in pam_tacplus through 1.5.1 lacks a check for a failure of RAND_bytes()/RAND_pseudo_bytes(). This could lead to use of a non-random/predictable session_id.
PUBLISHED: 2020-10-26
An out-of-bounds read in the JavaScript Interpreter in Facebook Hermes prior to commit 8cb935cd3b2321c46aa6b7ed8454d95c75a7fca0 allows attackers to cause a denial of service attack or possible further memory corruption via crafted JavaScript. Note that this is only exploitable if the application usi...
PUBLISHED: 2020-10-26
Ruckus through is affected by remote command injection. An authenticated user can submit a query to the API (/service/v1/createUser endpoint), injecting arbitrary commands that will be executed as root user via web.py.
PUBLISHED: 2020-10-26
Ruckus vRioT through has an API backdoor that is hardcoded into validate_token.py. An unauthenticated attacker can interact with the service API by using a backdoor value as the Authorization header.
PUBLISHED: 2020-10-26
In the git-tag-annotation-action (open source GitHub Action) before version 1.0.1, an attacker can execute arbitrary (*) shell commands if they can control the value of [the `tag` input] or manage to alter the value of [the `GITHUB_REF` environment variable]. The problem has been patched in version ...