[BreachExchange] If You Want to Stop Big Data Breaches, Start With Databases

[Inga Goddijn]

https://www.wired.com/2017/03/want-stop-big-data-breaches-start-databases/

OVER THE PAST few years, large-scale data breaches have become so common
that even tens of millions of records leaking feels unremarkable. One
frequent culprit that gets buried beneath the headlines? Poorly secured
databases that connect directly to the internet.

While companies commonly use these databases to store tempting troves of
customer and financial data, they often do so with outdated and weak
default security configurations. And while any type of database can be left
open or unprotected, a string of breaches over the last few years have all
centered around one type in particular: open-source “NoSQL” databases,
particularly those using the popular MongoDB database program. Of course
there are many types of hacks that can ultimately lead to data breaches,
like using spear phishing to gain access to a network, but securing exposed
databases is a relatively easy and concrete step organizations can take to
strengthen their data defense.
All Your Database Are Belong To Us

Traditional relational databases concentrate data in one or a handful of
related servers. By contrast, the newer NoSQL generation of databases
scales quickly by arranging massive amounts of data across many servers.
Because these databases are open source, anyone can easily implement them.
That’s good for attracting customers and getting developers up and running
quickly when they’re on deadline, but it also means that MongDB and the
other companies that make NoSQL databases don’t have control over how users
set up and secure them.

That disconnect has led to extensive fallout. Memorable unprotected
database breaches include the 2015 MacKeeper incident
<https://krebsonsecurity.com/2015/12/13-million-mackeeper-users-exposed/> in
which usernames, passwords and other data leaked for more than 13 million
of the security scanner’s customers. In April 2016, security researcher
Chris Vickery discovered an exposed database containing the full names,
addresses, birthdays and voter registration numbers for all *93.4
million* Mexican
voters
<http://www.networkworld.com/article/3060778/security/personal-info-of-all-94-3-million-mexican-voters-publicly-exposed-on-amazon.html>,
which had been accessible online for seven months. Also in April, hackers stole
user data for 1.1 million people
<https://www.wired.com/2016/04/beautiful-people-hack/> from the insecure
database of the dating website BeautifulPeople.com, and in October hackers
compromised personal data from 58 million customers
<https://arstechnica.com/security/2016/10/breach-exposes-at-least-58-million-accounts-includes-names-jobs-and-more/>
 of the data storage firm Modern Business Solutions. And those are just
some of the most publicized hacks.

The attacks have also not only continued, but evolved. At the beginning of
2017, a rash of “ransomware” incidents hit exposed MongoDB databases. In these
cases
<https://www.bleepingcomputer.com/news/security/mongodb-databases-held-for-ransom-by-mysterious-attacker/>
 attackers actually just deleted a database’s files, but made it seem like
paying a Bitcoin ransom worth a few hundred dollars would trigger data
restoration.
Open Source, Open Sesame

Security experts have been warning about NoSQL configuration insecurity
<https://www.trustwave.com/Resources/SpiderLabs-Blog/Mongodb---Security-Weaknesses-in-a-typical-NoSQL-database/>
 for years, and MongoDB specifically has suffered from two issues. First,
it used to have some problematic defaults, like not requiring password
authentication and granting users overly broad privileges. MongoDB updated
these configurations a few years ago. But, second, because MongoDB is open
source, it’s easy to find installers online that incorporate outdated or
misguided security settings. Someone who doesn’t have a lot of tech
experience, or just isn’t paying attention, can easily wind up accessing
and relying on flawed configuration files while setting up a database.

“It’s not as though attackers have exploited any flaw in these
technologies, they haven’t exposed any flaw in MongoDB,” says Mat Keep, the
director of product and market analysis at MongoDB. “What’s happened is
there have been a very small number of users who have not applied the
security controls that come as standard with the database and they’ve
exposed those databases publicly to the open internet.”

Unprotected databases are also trivial to find. Both criminals and
researchers alike use network visibility tools like the search engine
Shodan, which indexes internet-connected devices, to get a sense of how
many exposed databases are out there. Currently searching “MongoDB” on
Shodan reveals more than 50,000 exposed databases. They may or may not be
vulnerable to attack, but simply being visible increases their risk.

The ubiquity of outdated MongoDB installers and tutorials contributes to
the problem, but databases built with current MongoDB releases have been
breached as well, usually because whoever set up the database intentionally
disabled the default security protections. Security researcher Chris
Vickery, who has identified many high-profile database leaks over the last
few years, says that poor institutional communication and planning are a
hurdle when groups create NoSQL databases. “A problem is that somebody will
set up a MongoDB in an insecure way, but safely behind a firewall. And then
for whatever reason the device gets plugged in in front of the firewall or
the firewall goes down and then all of a sudden the database is exposed,”
Vickery says. “The people who set it up never thought it would be exposed
to the world, and they never talked to the people who are now taking down
the firewall.”

This problem also applies to databases on test servers that are built
quickly, with intentionally few security measures in place so that it’s
easy to work on development projects. If that project becomes a legitimate
service without anyone remembering to update its security settings, the
database goes from being a private testing ground to a public exposure.
“All these servers were placed on the internet without any authentication
and Shodan indexed them,” says Niall Merrigan, a solutions architect who
compiles information about exposed databases. “This meant that there was an
easy way to find open servers.”
Course Correct

Despite MongoDB’s improvements, researchers say that they haven’t yet seen
an overall decline in exposed NoSQL databases. “We have tried to be very
proactive in enabling people to get the most out of our security features,”
MongoDB’s Keep says. “It’s frustrating for us that despite being warned, a
tiny minority of people are still failing to apply the most basic
protections to their databases.”

At least, though, the years of working to raise awareness, by researchers
and companies like MongoDB, has resulted in mainstream recognition of the
problem. “This issue has been known in the security community for a long
time, and it’s really not just a Mongo problem, but it was difficult for us
to get anybody to care about it at first,” says John Matherly, the creator
of Shodan, who has been tracking MongoDB exposure for years.

Unfortunately, the urgency of evolving threats like the recent “ransomware”
hacks is providing much of that belated motivation. Previously, an exposed
database could cause an embarrassing breach, but didn’t seem to pose a risk
beyond that. The threat of losing entire databases that companies rely on
for daily operations, though, has forced people to pay attention. “The
whole MongoDB ‘apocalypse’ situation is bad for PR, but it made such a big
splash that everybody will hear about it in the tech community, and then
maybe it’ll spread awareness faster about securing your Mongo databases.
Otherwise, there are real consequences,” Vickery says.

Of course, there were always consequences for the millions of people whose
data was exposed. But now that companies feel those pressures too,
something might actually be done about it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170329/d126b4bd/attachment.html>