@JaredBusch not necessarily abnormal but surely a mix of 3 independent repos.

@Romo said in Extortionists competing to get paid for the same databases!:

Explanation of the vulnerability

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.

That's not a vulnerability, that is STILL a half configured system AND no firewall on the server. And MongoDB 2.6 is relatively old, we are on 3.3 these days. This is a database cluster component, not a complete database piece on its own. Whatever "security" professional is writing this piece clearly isn't aware of what they are writing about. What they write is half true, 27017 is listening on 0.0.0.0, but it does so for a reason and is only vulnerable in places where someone did not finish setting up their database AND their server. It's not a vulnerability in the product.

For those looking through the logs, this is the key entry to notice:

error: Error creating index Index with name: _key_1_value_-1 already exists with different options

@scottalanmiller said in Installing MongoDB 3.2 on CentOS 7:

Just tested and deployed to CentOS 7.2 on Linode.

This failed me, so I went to the mongo docs and the baseurl contains the variable $releasever.

using that results in redhat//mongodb in the file, which is why I assume you hard coded that bit.

Escaping the $ fixes it.

cat > /etc/yum.repos.d/mongodb-org-3.2.repo <<EOF [mongodb-org-3.2] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/\$releasever/mongodb-org/3.2/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc EOF

gte and lte values create the "bounds" of the query. Adjust accordingly to change the date range. Value is "epoch time."

Fix was pretty easy:

export LC_ALL=C

Aww.. I thought someone reached out to them and said "hey we are talking about you over at ML, why not stick your head in?"

Sucks that we will not have a chance to get MongoDB 3 ahead of Friday's event. Would have been awesome to put it through its paces.

I never even had a chance to know that it was broken.

A year later and no one posts.

Just came across this today. Did not realize that Rackspace has added a Redis and MongoDB product!

http://objectrocket.com/