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.

Attacks/Breaches

8/25/2020
02:00 PM
Ron Bennatan
Ron Bennatan
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comments
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Russian Military Officers Unmasked, Indicted for High-Profile Cyberattack Campaigns
Kelly Jackson Higgins, Executive Editor at Dark Reading,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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
CVE-2020-24847
PUBLISHED: 2020-10-23
A Cross-Site Request Forgery (CSRF) vulnerability is identified in FruityWifi through 2.4. Due to a lack of CSRF protection in page_config_adv.php, an unauthenticated attacker can lure the victim to visit his website by social engineering or another attack vector. Due to this issue, an unauthenticat...
CVE-2020-24848
PUBLISHED: 2020-10-23
FruityWifi through 2.4 has an unsafe Sudo configuration [(ALL : ALL) NOPASSWD: ALL]. This allows an attacker to perform a system-level (root) local privilege escalation, allowing an attacker to gain complete persistent access to the local system.
CVE-2020-5990
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to 3.20.5.70, contains a vulnerability in the ShadowPlay component which may lead to local privilege escalation, code execution, denial of service or information disclosure.
CVE-2020-25483
PUBLISHED: 2020-10-23
An arbitrary command execution vulnerability exists in the fopen() function of file writes of UCMS v1.4.8, where an attacker can gain access to the server.
CVE-2020-5977
PUBLISHED: 2020-10-23
NVIDIA GeForce Experience, all versions prior to 3.20.5.70, contains a vulnerability in NVIDIA Web Helper NodeJS Web Server in which an uncontrolled search path is used to load a node module, which may lead to code execution, denial of service, escalation of privileges, and information disclosure.