Category: CommunityThe MacKeeper Debacle Shows The Danger Of Poor Database Configuration

Share this post...Tweet about this on TwitterShare on Google+0Share on Facebook0

The Mackeeper DebacleSecurity researchers recently showed that the company behind the MacKeeper application exposed the data of millions of its users. We’re used to hearing about such security breaches, but in this case it didn’t happen because of a software vulnerability or a clever social engineering attack. It happened because the MongoDB database used by the company was exposed to the open internet. Anyone who knew it was there could have queried the server and received a complete listing of the data it held.

MacKeeper is essentially a scareware application that uses dodgy marketing tactics to peddle software that purportedly makes your Mac run faster, but the nature of the software isn’t the most important point here. What’s interesting is the way that the security hole was discovered. The researchers used Shodan, a search engine that searches through millions of Internet connected devices. It’s a useful — and terrifying — service that indexes thousands of unprotected webcams, database servers, traffic lights, power stations, and a host of other infrastructure that should absolutely not be on the open internet.

The researchers were able to find tens of thousands of MongoDB database servers with hundreds of terabytes of data exposed to anyone with the IP address, which can be discovered on Shodan. In the MacKeeper case, the researchers notified Kromtech, the app’s developers, who fixed the problem in short order. But that leaves many thousands of database servers, many likely to be storing sensitive information, open to the wilds of the internet.

This issue seems to have been created by a combination of less than competent database admins and a rather unintelligent default setting on the part of MongoDB’s developers, but it’s worth keeping in mind that this isn’t a problem impacting only MongoDB. Any database server can be misconfigured in the same way.

The lessons to be learned? Firstly, there is almost never a good reason to have a database server accessible to the open internet. Access to databases should be offered via an API with a rigorous authentication mechanism. Database servers should be accessible directly only on internal networks.

Secondly, this incident shows the value of thorough risk assessments. Companies holding private data should proactively audit their risk portfolio and the risk of databases exposed to the open internet should be be high up on any security checklist.

Thirdly, if you don’t know a lot about database management or the specific database application you’re using, it might be better to seek advice before you fill it with the private data of your users. Otherwise there’s a good chance that you’ll put those users at risk.

Image: Flickr/why137

Jan 14, 2016, 11:29 amBy: Corey Northcutt (0) Comments

Leave a Reply
Surround code blocks with <pre>code</pre>

Your email address will not be published.


Sign up to receive periodic InterWorx news, updates and promos!

New Comments

Current Poll

  • This field is for validation purposes and should be left unchanged.