How to remediate – MongoDB Unauthenticated REST API Detection

1. Introduction

MongoDB Unauthenticated REST API Detection refers to an open access point on a MongoDB database server allowing unrestricted data retrieval. This poses a risk to confidential information and can lead to data breaches. Systems running MongoDB with the HTTP interface enabled, particularly those exposed directly to the internet, are usually affected. Impact is likely to be high for confidentiality, low for integrity, and medium for availability.

2. Technical Explanation

The vulnerability occurs when the MongoDB HTTP interface is enabled without authentication. This allows anyone who can reach the server to query databases and collections directly via REST API calls. An attacker needs only network access to exploit this issue. There is no specific CVE associated with simply enabling the unauthenticated interface, but it’s a common misconfiguration. For example, an attacker could use curl to list available databases on the server. Affected versions include all MongoDB releases where the HTTP interface is enabled by default or without authentication configured.

• Root cause: The MongoDB HTTP interface is enabled with no access controls in place.
• Exploit mechanism: An attacker sends HTTP requests to the exposed API endpoint to enumerate databases and collections, then retrieve data. Example payload: curl http://:28017/
• Scope: All MongoDB instances running with an unauthenticated HTTP interface are affected.

3. Detection and Assessment

Confirming vulnerability involves checking if the HTTP interface is accessible. A quick check can identify open ports, while a thorough method involves querying the API directly.

• Quick checks: Use netstat -tulnp | grep 28017 to see if port 28017 (default) is listening.
• Scanning: Nessus plugin ID 10435 can detect this issue, but results should be verified.
• Logs and evidence: MongoDB logs do not typically record access attempts to the unauthenticated interface; network traffic analysis is more useful.

curl http://:28017/

4. Solution / Remediation Steps

Fixing this issue requires disabling or restricting access to the MongoDB HTTP interface. These steps are small and can be rolled back if needed.

4.1 Preparation

• Dependencies: Ensure you have access to modify the MongoDB configuration file. Rollback involves restoring the original configuration and restarting the service.
• Change window: A short maintenance window may be needed depending on service criticality. Approval from a database administrator is recommended.

4.2 Implementation

1. Step 1: Edit the MongoDB configuration file (usually /etc/mongod.conf or similar).
2. Step 2: Comment out or remove the line containing httpInterfaceBindIp = 0.0.0.0.
3. Step 3: Restart the MongoDB service using sudo systemctl restart mongod.

4.3 Config or Code Example

Before

httpInterfaceBindIp = 0.0.0.0

After

# httpInterfaceBindIp = 0.0.0.0

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of exploitation, while secure defaults reduce misconfiguration risk.

• Practice 1: Apply least privilege principles by restricting network access to MongoDB servers using firewalls and network segmentation.
• Practice 2: Use safe defaults by disabling unnecessary features like the HTTP interface unless specifically required.

4.5 Automation (Optional)

# Example Ansible task to comment out httpInterfaceBindIp in mongod.conf
- name: Disable MongoDB HTTP Interface
  lineinfile:
    path: /etc/mongod.conf
    regexp: '^httpInterfaceBindIp = 0.0.0.0'
    state: absent
  notify: Restart MongoDB

5. Verification / Validation

Confirming the fix involves checking that the HTTP interface is no longer accessible and verifying service functionality.

• Post-fix check: Run curl http://:28017/; expect a connection refused error or timeout.
• Re-test: Repeat the initial detection method (netstat, curl) to confirm port 28017 is no longer listening.
• Smoke test: Verify that database applications can still connect using standard MongoDB drivers and protocols.
• Monitoring: Monitor MongoDB logs for connection attempts on port 28017 as an indicator of potential regression.

curl http://:28017/

6. Preventive Measures and Monitoring

Updating security baselines and implementing checks in CI pipelines can prevent this issue. A sensible patch cycle ensures timely updates.

• Baselines: Update your server security baseline to include a requirement for disabling the MongoDB HTTP interface unless specifically needed.
• Pipelines: Add static analysis or configuration scanning to your CI/CD pipeline to detect unauthenticated HTTP interfaces in infrastructure code.
• Asset and patch process: Implement a regular review cycle of MongoDB configurations to identify and remediate misconfigurations like this one.

7. Risks, Side Effects, and Roll Back

Disabling the HTTP interface may impact applications that rely on it. Rolling back involves restoring the original configuration file.

• Risk or side effect 2: Incorrectly modifying the MongoDB configuration file can prevent the service from starting. Back up your config first!
• Roll back: Restore the original MongoDB configuration file and restart the service using sudo systemctl restart mongod.

8. References and Resources

• Vendor advisory or bulletin: https://docs.mongodb.com/ecosystem/tools/http-interfaces/
• NVD or CVE entry: Not applicable – this is a configuration issue, not a specific vulnerability with a CVE.
• Product or platform documentation relevant to the fix: https://docs.mongodb.com/manual/reference/configuration-options/#httpinterfacebindip