Mongo Express is a lightweight web-based administrative interface deployed to manage MongoDB databases interactively. It is authored using Node.js, Express and Bootstrap packages. This case study highlights the deployment of Mongo Express admin panels without authentication on the Internet and the various measures to prevent the exposure.
The authentication scheme
Mongo Express comes with a
config-default.js file. It primarily supports basic authentication, which encompasses the base64 encoded payload of a
username:password combination. This means that, if the basic authentication is configured, the HTTP request header
Authorization: Basic <payload> should be transmitted with every request to access different Mongo Express web components. Figure 1 shows the variables used to provide the basic authentication credentials.
Figure 1. Mongo Express web management console authentication variables
In addition to the web panel authentication scheme discussed above, the Mongo Express package supports database authentication credentials to be passed via environment variables. Passing credentials via environment variables can result in leakage of information at multiple places if the host is deployed using virtual machines or containers. Figure 2 shows the types of environment variables used to pass the values.
Figure 2. Environment variables for the Mongo database connection
The Mongo Express environment variables used to provide authentication are shown in Figure 3:
Figure 3. Docker environment variables for Mongo Express authentication
Overall, basic authentication is used for securing the Mongo Express web administrative panels and environment variables are used to store credentials for configuring back-end connections to the main MongoDB database.
Mongo Express: HTTP request/response
In the default state, Mongo Express transmits HTTP request and response headers as shown in Listing 1. The
mongo-express cookie parameter is created for storing session-related information.
Listing 1. HTTP request/response by the Mongo Express web server
set-cookie:mongo-express signature can be used to fingerprint Mongo Express deployments on the Internet.
There are thousands of Mongo Express web administration panels exposed on the Internet and they can be accessed without authentication. This means that that any remote user can access these interfaces and execute commands or retrieve sensitive information.
Here you can see the HTTP resource paths that can be used to scan for Mongo Express instances running on the Internet without authentication:
Direct web links
Listing 2 simply projects the output of the cURL request sent to access the resources used by the Mongo Express package:
Listing 2. Accessing the JSON dump of System.Users without authentication from a remote server
Here are a few examples from the real-time assessment of unauthenticated Mongo Express web administrative instances we conducted.
Accessing Admin Root: It is possible to access and edit the document containing details of the credentials such as
serverKey and other values. Figure 4 shows the same.
Figure 4. Extracting the roles and credentials of Admin.Root
Database deletion: Figure 5 and Figure 6 show that it’s possible to drop the databases by deleting all associated collections. The examples show the deletion of the
startup_log database from the insecure Mongo Express administrative panel.
Figure 5. Initiating deletion of collections from the database
Figure 6. Database dropped successfully
Information leakage: The logs can also reveal internal information about the build environment, as shown in Figure 7.
Figure 7. Information leakage about the build environment
The examples presented above highlight why it is important to secure Mongo Express instances deployed on the Internet. Here are some tips for preventing exposure:
1. Restrict access with strong credentials and deploy perimeter access controls.
2. Perform regular vulnerability assessment and penetration testing of exposed services on the network perimeter to ensure critical services are restricted and are not running insecure versions of software.
3. Develop strong and robust risk assessment program to ensure risks are known upfront and remediated accordingly.
4. Perform configuration reviews at regular intervals and incorporate the practice by developing a Security Impact Analysis (SIA) plan.