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.<p>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.)<p>Edit to add:<p><a href="http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-1" rel="nofollow">http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-p...</a>
<a href="http://articles.slicehost.com/assets/2007/9/4/iptables.txt" rel="nofollow">http://articles.slicehost.com/assets/2007/9/4/iptables.txt</a> <-- make sure you change the port 30000 on the SSH to whatever you use on your boxes<p>[+] 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 <i>your</i> 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.
Similar, but with memcached (2010): <a href="http://www.sensepost.com/blog/4873.html" rel="nofollow">http://www.sensepost.com/blog/4873.html</a>
German IT-news-site heise.de is reporting on it, I guess there'll be an english translation soon.<p><a href="http://www.heise.de/security/meldung/Studenten-entdecken-Tausende-offene-Firmen-Datenbanken-im-Internet-2545183.html" rel="nofollow">http://www.heise.de/security/meldung/Studenten-entdecken-Tau...</a><p>Original (German language) press release is here: <a href="http://www.uni-saarland.de/nc/en/news/article/nr/12173.html" rel="nofollow">http://www.uni-saarland.de/nc/en/news/article/nr/12173.html</a>
Someone posted a list to a .onion site indexing these on FD in early 2014.<p><a href="http://seclists.org/fulldisclosure/2014/May/43" rel="nofollow">http://seclists.org/fulldisclosure/2014/May/43</a><p>Edit: Oh, seems like the site is still up at <a href="http://un1c0rn.net/" rel="nofollow">http://un1c0rn.net/</a><p><a href="http://un1c0rn.net/search?q=tags%3Amongo" rel="nofollow">http://un1c0rn.net/search?q=tags%3Amongo</a>
We take security seriously at MongoDB. Here is a response on security best practices from the MongoDB CTO & Co-Founder:<p><a href="http://www.mongodb.com/blog/post/mongodb-security-best-practices" rel="nofollow">http://www.mongodb.com/blog/post/mongodb-security-best-pract...</a>
I tried to verify the results but am getting stuck at this:<p>curl $SHODANURL |grep -i class=\"ip\" |cut -d ’/’ -f 3 \
|cut -d ’"’ -f 1|uniq >db.ip<p>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?
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.
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.