Assistant Engineer
Assistant Engineer
  • UID634
  • Fans0
  • Follows0
  • Posts44

[Others]Why cloud services? - Lessons learned from the MongoDB security incident

More Posted time:Mar 28, 2017 9:22 AM
The railway department is not the busiest at the end of every year - thieves are even busier. Coincidentally a recent article about internet exposure of NoSQL broadened their train of thought. During the week following the release of this article, cases of self-built MongoDB being hacked, data being deleted and Q coins being required for recovery were widely reported. Today allow me some self-glorification: use MongoDB on the cloud for the sake of your database security. But before that, let's review the cases first.

Features of the attacked
The modus operandi cannot be claimed as advanced, so I would like to call them “bad guys” for the moment. But we cannot blame the “bad guys” only in these cases. The attacked self-built MongoDBs share two features:
1. Internet address is exposed, and some instances even adopt the default port number of 27017;
2. No authentication constraints are configured, namely everybody can access the database.

How is the attack launched?
This is equivalent to keeping your home door wide open to “welcome” “bad guys” to extort data. The “bad guys” usually do the following deeds:
1. Access the shadon website. The website intends to carry out internet data analysis and its principle is to scan the global IP addresses and ports and collects the statistical data of various devices or services through analyzing protocols. Unfortunately, the website is easily abused. These “bad guys” even don’t need to scan the port, and shadon has it all ready;
2. They tried to log in using the mongoshell or other management tools. Many companies didn't configure the authentication for their MongoDB databases, saving the attackers' effort to crack the password;
3. It is not quite helpful to damage the database solely. They usually dump the data to a local place and save a copy, or directly modify the set name or address and save them in a secret place; some “bad guys” just sabotaged the databases deliberately;
4. They blackmail the victim for Q coins or Bitcoins to recover the data (if any).

Whose to blame?
Look, this is really not a clever trick, but we really cannot blame them solely. Three parties are responsible for this incident. Why?
1. “Bad guys” should take 50% of the responsibility for blackmailing law-abiding persons;
2. The company should take 40% of the responsibility. Why did you use the internet address and why didn't you implement the authentication mechanism? If you open the door to your own house wide, you cannot claim innocence if your house is stolen from;
3. MongoDB should take 10% of the responsibility. It is indeed innocent to some extent. But the default configuration should have forced authenticated access. In addition, the official team should also keep educating the users (although the official side has clearly requested users to configure authentication in its English documentation to ensure security), as we cannot expect everybody to have security awareness. In addition, MongoDB started to change the authentication protocol from 3.0 onward and does not support 2.x version drivers. As a result, many users don't want to bother to upgrade the client, thus sacrificing authentication.

Better late than never
The incident has happened and complaints do not solve problems. Let's see how to solve the issue:
1. No matter whether your database has been attacked and is on the internet, you should check your authentication configurations to avoid more loss;
2. Close the internet access ingress to shut the door;
3. If you are an Alibaba Cloud user, you can try to recover the ECS storage image to restore the data as much as possible. Although the image can be restored, there is a risk that the data files recovered may be incomplete. Just try to repair it using the MongoDB repair command and pray;
4. Try your luck and check whether the data tables have been renamed. Data dumping costs some time and storage resources. You can check the capacity changes in the monitoring data if any to help determine if this is the case.

Well, use Alibaba Cloud MongoDB
Alibaba Cloud's cloud MongoDB has highlighted security from its design. We offer the following in the service:
1. Solutions based on MongoDB 3.2 compatible versions and enforce authentication. By default, no internet ingress is provided;
2. Alibaba Cloud provides VPC capability for cloud MongoDB. Network isolation is available even in Alibaba Cloud intranet;
3. Alibaba Cloud MongoDB provides a whitelist feature for you to allow access from only your own ECS instances;
4. Here comes the heavyweight which is not available in self-built databases: the incremental backup and recovery. If your data is deleted, or dropped accidentally by yourself, this feature helps you to recover your data to any time point;
5. Here comes another heavyweight which is the capability offered in the official version for enterprise: complete auditing logs. It helps you to clearly check who deleted the data, how he or she deleted the data and where the deleted data went - as clear as day;
6. Alibaba Cloud houses numerous security experts, and attackers also weigh the risk-income ratio;
In addition, it is worth noting that advanced languages such as PHP implement short connections for operations on the database. So the authentication will compromise a lot of performance after being enabled (mainly affecting the concurrency capacity). Alibaba Cloud MongoDB also implements some optimizations in this regard and improves the performance by ten times for short connection scenarios. At the same time, it also provides cloud migration service DTS. For details, visit our official website.