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
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16632
PUBLISHED: 2021-05-15
A XSS Vulnerability in /uploads/dede/action_search.php in DedeCMS V5.7 SP2 allows an authenticated user to execute remote arbitrary code via the keyword parameter.
CVE-2021-32073
PUBLISHED: 2021-05-15
DedeCMS V5.7 SP2 contains a CSRF vulnerability that allows a remote attacker to send a malicious request to to the web manager allowing remote code execution.
CVE-2021-33033
PUBLISHED: 2021-05-14
The Linux kernel before 5.11.14 has a use-after-free in cipso_v4_genopt in net/ipv4/cipso_ipv4.c because the CIPSO and CALIPSO refcounting for the DOI definitions is mishandled, aka CID-ad5d07f4a9cd. This leads to writing an arbitrary value.
CVE-2021-33034
PUBLISHED: 2021-05-14
In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value.
CVE-2019-25044
PUBLISHED: 2021-05-14
The block subsystem in the Linux kernel before 5.2 has a use-after-free that can lead to arbitrary code execution in the kernel context and privilege escalation, aka CID-c3e2219216c9. This is related to blk_mq_free_rqs and blk_cleanup_queue.