Unstoppable information leakage problems

At the end of 2016 and the beginning of 2017, large amounts of database selling information gradually appeared on public networks and the dark web, in which a large part of the databases were the popular NoSQL database MongoDB. A feature of the NoSQL database is that it can be used effectively on unstructured data, and it was one of the main databases wildly used by enterprises. Its popularity also caused MongoDB to become one of most favorable targets for attackers recently.

Figure: List of databases sold on the deep web

The looks of various leaked information

        The data content saved in so-called databases is obviously related to the services provided by enterprises, in which they are no other than sensitive information including personal information of members, accounts and passwords, credit card purchase information, transaction orders and logistics information etc. The purpose for attackers to steal these type of information earlier is to sell them for profit; some attackers will integrate the database acquired into their own social database (hacker’s Big-Data) and then sell doxing services, and of course there are also a few collectors who only want to backup and store the databases as treasure.

As ransoms become more and more popular in recent years, some attackers already switched their early business modes into kidnapping; just like how ransomware will encrypt important information in personal computers, mobile phones and tablets and then ask for ransom, attackers will first steal and backup important databases of enterprises, and when backup is complete, they will maliciously attack and delete the enterprise’s database and then send Emails to the victimized enterprise and use the previously backed up captive to blackmail the victim for profit. This is exactly what happened at the beginning of 2017 where a certain hacker group attacked global MongoDBs and performed kidnapping for ransom.

Figure: Example of how data looks in databases

Culprit
        As for the main reason that caused so many MongoDB to be stolen, kidnapped and ransomed, after investigating and analyzing several actual cases, it was discovered that most of them were related to security misconfiguration. If follow-up security setting adjustments were not made for earlier versions of MongoDB and access restrictions were not properly set on firewalls, this might lead to attacks on MongoDB. For example, the default service port (Listen Port) TCP 27017 of MongoDB before version 3.0 could be accessed by public networks; therefore if the MongoDB server has a public IP address and the administrator did not perform ACL access control for TCP port 27017 of MongoDB, attackers could access this database directly through the internet. In addition, the preset of earlier versions of MongoDB had the problem of allowing it to be accessed without the need for account and password, so attackers can simply use the mongoexport instruction to export and backup the entire database and cause data leakage.

Countermeasures
From the example described above we can understand that a series of security misconfigurations could cause major hazards; if administrators noticed any one of the misconfigurations and improved it immediately, there might just be one less entry in the list of databases sold by attackers. Even though later versions of MongoDB already eliminated some of the possibilities that might cause information security problems during default installation, we still need to learn the experiences from past failures and set countermeasures. The following are reference recommended countermeasures:
Countermeasure One: Read the manual
The operation manual should be read carefully before installing and using any application servers; most of the manuals explain the settings and practices that can make the installed server safer. The security can be improved significantly if the application server was configured more carefully.
Countermeasure Two: Usage separation
The usage of the application server should be confirmed; application services such as databases and system management usually should not be opened for direct external access, and be careful when setting the rules for firewalls. If it must be opened to the outside due to business requirements, other safer practices should be referred to; for example, restricting the source IP address or access through VPN etc.
Countermeasure Three: Encryption protection
Stricter encryption methods or data masking must be used for important data saved in the database (such as personal information, password and credit card number etc.). Sensitive information such as personal information and credit card number etc. could be encrypted and protected using AES 256 / RSA 2048 or above, and SHA2 or adding SALT can be used for passwords to prevent it from being cracked. If sensitive information cannot be protected with encryption, it should not be saved in the database directly using plain code without masking either; also consider whether this information has to be saved. Avoid saving too much unnecessary information in the database; this way the problems that might be caused if the data was stolen can be reduced.
Countermeasure Four: Take the initiative
Use active testing (such as vulnerability assessment or penetration test) regularly to test the information security of external services, and compare the tested actual situation with the expected situation to identify erroneous links and have subsequent discussions to correct the improved overall security.