Several thousand MongoDBs without access control on the Internet [pdf](cispa.saarland)
cispa.saarland
Several thousand MongoDBs without access control on the Internet [pdf]
http://cispa.saarland/wp-content/uploads/2015/02/MongoDB_documentation.pdf
44 comments
I'm not surprised. I've never actually gotten replication groups and access control to work properly with MongoDB. So I gave up and relied on network/firewall-level security. I guess some people don't even bother with that.
Very interesting article, thanks for the submission.
* MongosDB
German IT-news-site heise.de is reporting on it, I guess there'll be an english translation soon.
http://www.heise.de/security/meldung/Studenten-entdecken-Tau...
Original (German language) press release is here: http://www.uni-saarland.de/nc/en/news/article/nr/12173.html
http://www.heise.de/security/meldung/Studenten-entdecken-Tau...
Original (German language) press release is here: http://www.uni-saarland.de/nc/en/news/article/nr/12173.html
And it's not just small stuff either, 8 million phone numbers and addresses in one case. That is beyond embarrassing.
What is even more embarrassing, is the lack of proper acknowledgment from the French Telecommunication provider (Bouygues Telecom?) regarding the safety of their customers' data.
Lol I remember finding back in 92 that the ITU's gopher server had all of my employers x.500 directory - a more inocent time :-)
Someone posted a list to a .onion site indexing these on FD in early 2014.
http://seclists.org/fulldisclosure/2014/May/43
Edit: Oh, seems like the site is still up at http://un1c0rn.net/
http://un1c0rn.net/search?q=tags%3Amongo
http://seclists.org/fulldisclosure/2014/May/43
Edit: Oh, seems like the site is still up at http://un1c0rn.net/
http://un1c0rn.net/search?q=tags%3Amongo
This can also happen with Memcached, Redis, and for that matter SQL databases. If you find it on your servers, you should be very, very alarmed. (Assume that any attacker with arbitrary access to any of these owns the box. [+]) One easy-ish way to make sure you don't inadvertently leave a port open is to use iptables and deny inbound connections to everything but 22, 80, and 443 by default.
This is part of the Slicehost VPS setup guide that PickledOnion wrote back in the day, and it's still one of the first things I do when I get a new box. (Typically right after locking down SSH with a key requirement.)
Edit to add:
http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-p... http://articles.slicehost.com/assets/2007/9/4/iptables.txt <-- make sure you change the port 30000 on the SSH to whatever you use on your boxes
[+] You might think "Well, that requires the existence of both a vulnerability in the server and a local privilege escalation exploit", but in practice, you can assume that the attacker has access to both of these. They also probably aren't trying to get into your box, specifically -- your box is merely one of the several thousand Redis instances on the Internet that they're firing e.g. a specially corrupted Unicode string to get a buffer overrun on, at which point they will -- in a mostly automated fashion -- run metasploit (or similar ratware) and turn that into a root shell.
This is part of the Slicehost VPS setup guide that PickledOnion wrote back in the day, and it's still one of the first things I do when I get a new box. (Typically right after locking down SSH with a key requirement.)
Edit to add:
http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-p... http://articles.slicehost.com/assets/2007/9/4/iptables.txt <-- make sure you change the port 30000 on the SSH to whatever you use on your boxes
[+] You might think "Well, that requires the existence of both a vulnerability in the server and a local privilege escalation exploit", but in practice, you can assume that the attacker has access to both of these. They also probably aren't trying to get into your box, specifically -- your box is merely one of the several thousand Redis instances on the Internet that they're firing e.g. a specially corrupted Unicode string to get a buffer overrun on, at which point they will -- in a mostly automated fashion -- run metasploit (or similar ratware) and turn that into a root shell.
> This can also happen with Memcached, Redis, and for that matter SQL databases.
No one else binds to all interfaces by default.
No one else binds to all interfaces by default.
Once I somehow had an /etc/hosts that said something like
127.0.0.1 localhost
192.168.1.8 localhost
Memcached does, for one. This is (sensibly) turned off if you do "apt-get install memcached" or similar.
Only if you compile memcached from source. They can afford to do this because distro package maintainers give it sensible defaults on their behalf.
MongoDB fucks this balance up by recommending you use their package repositories instead of distro maintained packages.
MongoDB fucks this balance up by recommending you use their package repositories instead of distro maintained packages.
Just to add:
http://memcached.org/downloads
https://www.mongodb.org/downloads
Are identical in having normal binary downloads as the primary installation option.
And you seem to be implying that vendor supplied repositories are somehow unusual. They absolutely aren't.
http://memcached.org/downloads
https://www.mongodb.org/downloads
Are identical in having normal binary downloads as the primary installation option.
And you seem to be implying that vendor supplied repositories are somehow unusual. They absolutely aren't.
> Are identical in having normal binary downloads as the primary installation option.
I don't believe I said that MongoDB recommended their packages over compiling from source.
> And you seem to be implying that vendor supplied repositories are somehow unusual.
Nope.
I don't believe I said that MongoDB recommended their packages over compiling from source.
> And you seem to be implying that vendor supplied repositories are somehow unusual.
Nope.
[deleted]
There are some security disadvantages to running things like SSH on non-privileged ports. If it's running on a port > 1024, it's a lot easier to replace with a malicious keylogging version (for example...).
[deleted]
[deleted]
Similar, but with memcached (2010): http://www.sensepost.com/blog/4873.html
How do I know if my access control is just local? I have a few small (pet) mongoDB projects on Digital Ocean, never spend too much time updatng and/or securing them actually.
Assuming you have the mongo client installed on your laptop or similar, use this in a command shell:
> mongo server.address.or.ip.goes.here
If this connects successfully, that is problematic.
> mongo server.address.or.ip.goes.here
If this connects successfully, that is problematic.
I'd first make sure that MongoDB is locked down in your firewall. Only open port 27017 to the IPs that need it (app, secondaries, etc).
I've found Mongo's authorization setup to be pretty unintuitive, but you can find some information here: http://docs.mongodb.org/manual/core/authorization/ (IIRC, you need to setup the permissions first, then set "auth=true" in mongod.conf and restart the service.)
I've found Mongo's authorization setup to be pretty unintuitive, but you can find some information here: http://docs.mongodb.org/manual/core/authorization/ (IIRC, you need to setup the permissions first, then set "auth=true" in mongod.conf and restart the service.)
Please spend a little bit more money and hire a professional who knows what he is doing instead of just following installation tutorials.
webscale2015(2)
We take security seriously at MongoDB. Here is a response on security best practices from the MongoDB CTO & Co-Founder:
http://www.mongodb.com/blog/post/mongodb-security-best-pract...
http://www.mongodb.com/blog/post/mongodb-security-best-pract...
The first point in your article is:
> "The most popular installer for MongoDB (RPM) limits network access to localhost by default."
The first download for Linux at https://www.mongodb.org/downloads is:
> https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.7....
At the bottom of the page there are alternate links to packages. Here is the description:
> "MongoDB is included in several different package managers. Generally speaking, it is easier to simply install the prebuilt binaries from above."
If the properly packaged versions have secure defaults, maybe you should steer people towards them?
> "The most popular installer for MongoDB (RPM) limits network access to localhost by default."
The first download for Linux at https://www.mongodb.org/downloads is:
> https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.7....
At the bottom of the page there are alternate links to packages. Here is the description:
> "MongoDB is included in several different package managers. Generally speaking, it is easier to simply install the prebuilt binaries from above."
If the properly packaged versions have secure defaults, maybe you should steer people towards them?
As I understand things based on the OP it seems however your documentation promotes the insecure way of setting up mongodb. It's even true that mongodb doesn't even ask to create db credentials during the installation,something it should do by default.
the real problem is lack of network protections. there are many things on the internet unprotected. this article is not news. dont put your database on the internet.
Security is a matter of layers, like an onion, it's not just an either-or. Any sensible database or database-like software does not come with authentication disabled by default. Yes, your DB should be behind a firewall, but if RedHat installed out of the box without a root password you wouldn't say "well your server should be behind a firewall anyway."
they are probably all Meteor tutorials.
I meant they are definitely not meteor tutorials.
# 1st: accept connections from localhost
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 27017 -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 28017 -j ACCEPT
# 2nd: drop from all others
iptables -A INPUT -p tcp --dport 27017 -j DROP
iptables -A INPUT -p tcp --dport 28017 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 27017 -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 28017 -j ACCEPT
# 2nd: drop from all others
iptables -A INPUT -p tcp --dport 27017 -j DROP
iptables -A INPUT -p tcp --dport 28017 -j DROP
FYI, the Security section of the MongoDB manual has a checklist (http://docs.mongodb.org/manual/administration/security-check...) and example firewall configurations for iptables on Linux and netsh on Windows: http://docs.mongodb.org/manual/administration/security-netwo....
# 3rd: change bind_ip from 127.0.0.1 to whatever in mongod.conf
curl $SHODANURL |grep -i class=\"ip\" |cut -d ’/’ -f 3 \ |cut -d ’"’ -f 1|uniq >db.ip
The author at CISPA (in the linked pdf) states to 'paste the html code' however using shodan from the command line, one only has access to 6 verbs that shodan understands. Shodan reveals 34309 mongo databases. I can download their ips but that requires 'query credits' using shodan. How does one use curl here?