Risk Of Using Default Setup Configuration & Vulnerability Assessment of MongoDB
While working in the IT environment, we often have to work with different sorts of tools and software. Although setting them up might be easy as a one-click installation just like WordPress was used to create this website but a default configuration in the software often makes it vulnerable to cyber-attacks.
When adding systems to a production network, default configurations might occasionally leave them less secure than suggested. Big companies have come up with different techniques in protecting the default configurations for their tools; unfortunately, penetration testers and attackers still discover many systems installed with default configurations. Many of the default options may simply allow attackers to learn more about the underlying operating system and other components. Obtaining information from a variety of information disclosure-related vulnerabilities, on the other hand, might be crucial to an attacker’s success in subsequent assaults.
Most risky default settings that make your environment vulnerable:
Attackers may exploit a system by targeting the default settings of a system for instance the administrator password; as strange as it may seem, the most powerful accounts usually have the weakest passwords. Local admin accounts in networks, for example, are used to set up servers in a network. However, most of the time, it is the extent of their responsibilities. These accounts are left with default or predictable passwords, making them easy targets for hackers. Although the passwords of admin accounts in settings like Active Directory (AD), Azure, or Amazon Web Services (AWS) are safe, they are frequently repeated or shared across network users.
Often the time root cause behind an attack is also a weaker policy, The network’s security policies are critical for controlling user access and dictating what a user may do on the network. There are several security policies that aren’t enabled by default and must be activated, or vice versa! Now, we all know that not all default settings are bad, some might be unnecessary or rather time-consuming to change. So how do we find out the vulnerabilities of certain tools?
There are plenty of free and premium tools that we can use to find out different vulnerabilities of a network or a tool, in particular, to find that out. It will also list other vulnerabilities it may have that are beyond the default configuration. In the below steps, I will talk about a vulnerability assessment of one of the popular database software MongoDB and how to prevent those.
Vulnerability Assessment of MongoDB in Linux container using different tools
MongoDB is a document-oriented NoSQL database for storing large amounts of data. This sort of database management system employs dynamic schemas, which allow us to generate entries without previously specifying the structure, such as fields or types and their values. By adding new fields or removing existing ones, MongoDB allows you to modify the structure of records, which we call documents. A key difference between this and MySql is that in MongoDB the results are shown as JSON-like documents instead of traditional tables and rows. Many find this convenient but the default settings often leave it vulnerable to attacks.
In order to find the vulnerabilities, we created a testbed installing Ubuntu Linux 18.04 on using Oracle Virtual Box. After installation of the operating system, a Docker Engine, as well as Singularity Engine, was installed. After the necessary configuration to set up, the MongoDB server and the client were installed to put into test.
The step below shows the installation of OpenVas (A vulnerability scanner):


Once logged into the OpenVas dashboard, I created a task defining the host to conduct the scan, and the results are shown below:


Another tool that I used to conduct the security assessment was Nessus, although the results were similar had more detailed information and mitigation techniques listed.


The main purpose of writing this article is to demonstrate and give an idea in short; of how a default configuration can be a reason behind security attacks and some of the tools that can be used to simply eradicate those issues. I have worked on a project using multiple different tools to conduct a vulnerability assessment and the mitigation efforts with steps written in detail if you are interested you may download it here and contact me for the full version.