1

Whats the easiest way to avoid the recent mongodb-scam?

https://www.bleepingcomputer.com/news/security/mongodb-databases-held-for-ransom-by-mysterious-attacker/

I added a root user

mongo
use admin
db.createUser( { user: "root", pwd: "password", roles: [ "root" ] } )

Thought it was enough for the moment but today I got hacked again.

I don't have time to do advanced ip-tables stuff at the moment. Is there any temp-fix to this?

Joe
  • 4,274
  • 32
  • 95
  • 175

3 Answers3

0

Just change your bindId of mongodb to 127.0.0.1 in mongod.conf file which is in etc for further details visit MongoDB database deleted automatically this will be a fix to your problem.

Community
  • 1
  • 1
Shumi Gupta
  • 1,505
  • 2
  • 19
  • 28
  • What such bad advice if you split out your stack which you should in any secure environment – Sammaye Jan 17 '17 at 09:14
  • 1
    Also the attacks don't happen because MongoDB accepts external connections they happen because they are not secured with even something as simple as auth – Sammaye Jan 17 '17 at 09:19
  • @Sammaye can you please be more clear ? changing your bindIp to 0.0.0.0 it allows you to access the database from any server but if you will set that then only your localhost will be able to access your database. – Shumi Gupta Jan 17 '17 at 09:23
  • 1
    *changing your bindIp to 0.0.0.0 it allows you to access the database from any server but if you will set that then only your localhost will be able to access your database*. This is just plain wrong. Did you even try this? – ares Jan 17 '17 at 09:27
  • Binding to a loopback interface suggests that you have everything on one server. That is the worst setup for a hack I can ever imagine. – Sammaye Jan 17 '17 at 09:31
  • @ares yes i have tried this in one of my project I had my source code on different server and database on different one so if you want to access data on the other server you need to change your bindIp to 0.0.0.0 or server ip if you don't do that you cant access database from different server. – Shumi Gupta Jan 17 '17 at 09:36
  • @Sammaye yes exactly so if you have everything on one server don't you think setting bindIp to 0.0.0.0 allows you to access database from other servers to which is of no use as well ?. So won't is be good if we set bindIp to 127.0.0.1 and as user have not mentioned here that he have any such scenario of multiple server so it will be good if user can set bindIp to localhost – Shumi Gupta Jan 17 '17 at 09:40
  • Read up on basic stack splitting and you will realise why I said what I did. – Sammaye Jan 17 '17 at 09:42
  • ok do share me some links where i can read it from. Let me have a look that what you want me read. – Shumi Gupta Jan 17 '17 at 09:44
  • It might solve it for a specific case which actually is insecure in itself, however, the real problem is that the MongoDB install is "open" – Sammaye Jan 17 '17 at 10:53
  • Last time I got hacked I also installed mongo 3.4 where the local binding is set to 127... Apparently it dit not work anyway. – Joe Jan 17 '17 at 13:45
  • @PerStröm Mostly since if the port is open it will still allow external connections on a loopback device – Sammaye Jan 17 '17 at 15:15
  • @ShumiGupta: To calrify my comment, changing the bind IP to 0.0.0.0 will bind mongodb to all network interfaces which are available. And then if you are connnected to internet and don't have any firewall (which you definately should), then anybody over the internet can connect. http://stackoverflow.com/questions/17588876/mongodb-conf-bind-ip-127-0-0-1-does-not-work-but-0-0-0-0-works – ares Jan 19 '17 at 09:35
  • @ares **changing the bind IP to 0.0.0.0 will bind mongodb to all network interfaces which are available** now this is what i was trying to say if you set your bindIp to 127.0.0.1 no one can access except your localhost I am not trying to say we should not use any firewall we surely should but this is an aditional think which we can do. **And about your cant connect to ec2 you can check this please.** http://stackoverflow.com/questions/4961177/how-to-listen-only-to-localhost-on-mongodb – Shumi Gupta Jan 19 '17 at 10:23
0
  1. Do not leave your mongo port open for all. You must have to set proper
    inbound rules.
  2. Run mongo in a custom port, avoid 27017.
  3. Enable auth as early as you can.
  4. Check GridFS if the hackers have left any malicious file.
Probal
  • 90
  • 12
  • Running MongoDB on a custom port won't help too much since a simple port sniffer can find it automatically – Sammaye Jan 18 '17 at 12:24
0

I just had a similar issue where my mongo instance got hacked (no valuable data on it) while I thought the port was securely behind ufw firewall.

It turns out that if you're running docker and have ufw as your firewall, docker inserts iptables rules that bypass ufw. e.g. When you run:

docker run -p 27017:27017 ...

Docker inserts the firewall rule (https://docs.docker.com/network/iptables/):

$ sudo /sbin/iptables -L DOCKER
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:27017

Which opens 27017 to the outside, so although you think everything is nice and secure behind ufw, it is not.

If everything that uses mongo is all on one machine, binding docker to 127.0.0.1 instead of the default 0.0.0.0 is one 1st step to prevent outside connections. e.g. Instead of:

docker run -p 27017:27017 ...

Use:

docker run -p 127.0.0.1:27017:27017 ...

While this prevents non-local connections, it still doesn't prevent docker creating the rule. Therefore port 27017 is still technically open and if you delete the rule, docker will recreate it again.

You should certainly consider the other security measures above as well, but it was a bit of a shocker when I realized this can happen with docker and ufw, so watch out for this.

I'm not seeing too many great solutions either:

https://www.techrepublic.com/article/how-to-fix-the-docker-and-ufw-security-flaw/

https://github.com/chaifeng/ufw-docker

(e.g. what happens if you move it onto a different box years later and forget to apply the fix to iptables)

XYZ
  • 331
  • 3
  • 4