STE WILLIAMS

A ransom attack that wiped more than 27,000 poorly configured MongoDB databases in January sounded like it would be a pretty loud wake-up call for better open-source NoSQL security.

Apparently, not so much.

As was widely reported at the time, penetration tester Victor Gevers, of the Netherlands-based GDI Foundation, and Niall Merrigan, a Norway-based developer, noticed a huge spike in attacks on MongoDB installations, jumping from about 2,000 on January 3 to 8,542 on January 5 to about 27,000 a couple of days later.

The two warned that that the installations were seriously vulnerable: old MongoDB instances deployed via cloud hosting services, mostly on the Amazon Web Services (AWS) platform with a default configuration – and without password-protected admin accounts.

That’s what has long been known in the industry as “low-hanging fruit”. And eight months later, the fruit is still hanging low. So low that in many cases it doesn’t even require hacking to get at the data, since it is publicly available. It’s the online version of a wide-open door.

Not that MongoDB is the only instance of leaky database security, or that this is anything new. As Naked Security’s Kate Bevan noted this week, more than 4m Time Warner Cable customers in the US had their data exposed, apparently due to a third party – TWC’s technology partner BroadSoft – failing to secure an AWS S3 bucket.

Earlier this summer, Upguard reported that information on the resumes of thousands of applicants to the private security firm TigerSwan – almost all of them military veterans – had been exposed due to an AWS S3 bucket being configured for public access by a third party – a recruiting vendor for TigerSwan. Upguard said it took more than a month to secure the bucket: it had notified the firm on July 21, and the problem wasn’t fixed until August 24.

More than four years ago, a report on Amazon S3 storage buckets found that nearly one in six – 1,951 of the 12,328 identified at the time – were open to the public.

The list goes on – and on. Wired noted just a few months ago that MacKeeper data on 13m customers leaked in 2015. In April 2016, MacKeeper security researcher Chris Vickery found a database that had been exposed for seven months, containing personal and voting data on all 93.4m Mexican voters. And last October, hackers gained access to personal information on 58m customers of the data storage firm Modern Business Solutions.

All of which would cause one to think that if those involved were going to wake up to the threat, they would have done so long ago – especially since, as noted on the BigStep blog more than a year ago:

… while NoSQL is a powerful solution and a real redesign for the way databases have always been structured, it was not developed with security in mind. Security was more of an afterthought, and even then, an afterthought by the organizations that adopt NoSQL databases and applications, not the developers themselves.

Another problem is that, since the technology is open-source, MongoDB and other makers of NoSQL databases are not necessarily to blame for the exposures, since they don’t control how users set them up – and whether they do or don’t apply the security controls that come with the product.

It’s enough to make a brief rant from a commenter with the handle “FreedomISaMYTH” on the Naked Security blog after the January MongoDB attacks sound like the most likely explanation He (or she) wrote:

dbleaks.com has informed thousands of folks of this issue, less than 1% reply and out of that 1%… its maybe 1 in 100 that actually secure their databases… Hospitals, schools, doctor offices, applications (iOS/Andriod), etc… Security is the last thing these folks care about. You can tell them, they don’t care until it’s too late.

And perhaps the only way to make them care is to inflict some pain, in the form of sanctions or litigation, neither of which seem to be rising in the wake of the ongoing data exposures.

But if people do care, there is plenty of advice, starting with making sure that you read the security manual of whatever NoSQL database service you’re using, and implement all the available security controls.

Beyond that are best practices that amount to common-sense security hygiene:

• Make sure all of your data is backed up.
• Keep your database patched and up to date.
• Encrypt sensitive data.
• Sandbox unencrypted data.
• Establish and enforce strict user authentication policies.

In short, make sure your online database isn’t exposed to the rest of the internet – we don’t want to be writing about your security failure on Naked Security.

Follow @NakedSecurity
Follow @tarmerding2

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/7C7bEH1-sJU/