未加星标

The MongoDB hack and the importance of secure defaults

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

If you have a MongoDB installation, now would be the time to verify that it is secure . Since just before Christmas, over 28,000 public MongoDB installs have been hacked. The attackers are holding the hacked data ransom, demanding companies pay using Bitcoins to get their data back. From the looks of it, at least 20 companies have given in and paid the ransom so far . This post explains the hack, how to protect yourself, and what we can learn from it.

Understanding the hack

The hack itself is alarmingly simple. In versions >= 2.6.0, MongoDB includes a default configuration file that binds MongoDB to 127.0.0.1 by default. As a result, the database will only listen to local connections.

Before version 2.6.0, that wasn’t true. By default, MongoDB was left open to remote connections. Authentication is also not required by default, which means that out of the box installs of MongoDB before version 2.6.0 happily accept unauthenticated remote connections.

Users could still restrict access to local connections if they took the time to configure the install but that meant manually adding a line to their mongodb.conf file. Since that wasn’t the default configuration, many existing installs never included this critical step.

Making matters worse is that it’s easy to identify potential MongoDB attack candidates. MongoDB’s default port is 27017. Using a search engine such as ZoomEye , you can query for MongoDB installs, see what port they’re available over, and find around 100,000 vulnerable candidates.

The vulnerability itself is hardly new. The issue was first raised back in 2012 and released somewhere around 2015. Also, in early 2015, John Matherly made some noise when he reported finding around 30,000 insecure installs of MongoDB . In other words, this is something that everyone could have known about for a while.

The trouble with insecure defaults

The lack of insecure defaults is no minor issue. Study after study after study has shown that most people stick to the defaults a system presents to them. Defaults matter.

Now, some folks might argue that some of these insecure defaults are an attempt to balance usability and security, and that they are based on reasonable assumptions. If you can safely assume a database will be installed behind a firewall in the vast majority of cases, for example, then you may decide that not binding a database to local connections would be a reasonable default.

But assumptions like that are dangerous because when not if someone does something that breaks that assumption, they’re now vulnerable to attacks―and they may not even know it. Understanding of the potential security risks presented by these defaults is not exactly mainstream knowledge. Unless a company has security experts in place reviewing each decision (a good idea, but not a given), these insecure defaults can―an often do―remain overlooked.

Tracking insecure defaults

The trouble with insecure defaults gets worse.

Let’s say you’re a responsible organization and use a tool, like Snyk, to scan your tools and dependencies for vulnerabilities. Those tools won’t report this issue because insecure defaults are typically not considered vulnerabilities. This is because the issue itself here isn’t a bug or vulnerability in the code itself―it’s a configuration issue.

It makes sense, to an extent, but it does raise the question: should there be an official identifier and database for insecure defaults?

On the one hand, a service reporting insecure defaults would undoubtedly produce some noise. There are a lot of insecure defaults and some organizations will have already addressed them. These organizations would need to determine if the issue still applies to them, which isn’t always a simple task. If it doesn’t, they could safely ignore the issue and move on.

But reporting insecure defaults could be invaluable for those users who haven’t already identified these concerns. For them, it may alert them to security risks that would otherwise remain unnoticed and untouched―potentially (as in the case of the MongoDB issue) for years.

Flagging known insecure defaults in an open-source database (the same way we flag known vulnerabilities) would not have stopped this attack, but it could have prevented at least some of the databases from being affected.

So what happens next?

First of all, go secure your MongoDB installation . We’ll wait.

Now that you’re back, what this hack demonstrates is the massive importance of secure defaults. Security is too important to leave to chance. Just as the industry has been shifting to accept that sites should be served over HTTPS by default, package authors should be doing their best to ensure that their packages are secure by default. An insecure default setting can result in just as much damage as a known vulnerability. While it’s understandable that developers of these tools want to default to an install with the least amount of friction, the danger is that if that default is also insecure, we end up with situations like the one people are dealing with now for MongoDB.

The other question these attacks pose is whether it’s time to start tracking insecure defaults in an open-source database. At Snyk, we repeatedly discuss whether we should mark such flaws as vulnerabilities or not, and we will probably continue that conversation for a long while. If you have a strong opinion either way, do let us know―either byemail or on Twitter .

本文数据库(综合)相关术语:系统安全软件

主题: MongoDBTwitter
tags: defaults,insecure,MongoDB,default,The,issue
分页:12
转载请注明
本文标题:The MongoDB hack and the importance of secure defaults
本站链接:http://www.codesec.net/view/523419.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(91)