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
Newest First  |  Oldest First  |  Threaded View
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Look Beyond the 'Big 5' in Cyberattacks
Robert Lemos, Contributing Writer,  11/25/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I think the boss is bing watching '70s TV shows again!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7335
PUBLISHED: 2020-12-01
Privilege Escalation vulnerability in Microsoft Windows client McAfee Total Protection (MTP) prior to 16.0.29 allows local users to gain elevated privileges via careful manipulation of a folder by creating a junction link. This exploits a lack of protection through a timing issue and is only exploit...
CVE-2020-15257
PUBLISHED: 2020-12-01
containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that...
CVE-2020-9114
PUBLISHED: 2020-12-01
FusionCompute versions 6.3.0, 6.3.1, 6.5.0, 6.5.1 and 8.0.0 have a privilege escalation vulnerability. Due to improper privilege management, an attacker with common privilege may access some specific files and get the administrator privilege in the affected products. Successful exploit will cause pr...
CVE-2020-9117
PUBLISHED: 2020-12-01
HUAWEI nova 4 versions earlier than 10.0.0.165(C01E34R2P4) and SydneyM-AL00 versions earlier than 10.0.0.165(C00E66R1P5) have an out-of-bounds read and write vulnerability. An attacker with specific permissions crafts malformed packet with specific parameter and sends the packet to the affected prod...
CVE-2020-4126
PUBLISHED: 2020-12-01
HCL iNotes is susceptible to a sensitive cookie exposure vulnerability. This can allow an unauthenticated remote attacker to capture the cookie by intercepting its transmission within an http session. Fixes are available in HCL Domino and iNotes versions 10.0.1 FP6 and 11.0.1 FP2 and later.