Unauthenticated MongoDB and Samba Badlock

A full service scan of the internal subnet returned an unexpected result: port 27017 open, service banner returning MongoDB 4.2, and — when the connection was attempted — no authentication prompt. No username, no password, no credential challenge. Full administrative access to every database on the instance, immediately. The service was not in the asset inventory. It had never appeared in a prior assessment because prior assessments scoped web applications, not supporting infrastructure.

Full access confirmed

The Nmap banner confirmed authorization: disabled. Connecting with the Mongo shell required no flags — the shell dropped in immediately and showed every database on the instance:

# connecting to the unauthenticated MongoDB instance — lab
mongo --host 10.10.20.30

# no authentication prompt — immediate shell access
> show dbs
admin     0.000GB
config    0.000GB
appdata   1.247GB
appstore  0.312GB
sessions  0.089GB

> use appstore
> db.records.count()
[several thousand]

# write access confirmed:
> db.records.insertOne({"name": "test", "tag": "lab-probe"})
{ "acknowledged": true, "insertedId": ObjectId("...") }

# acknowledged: true — full CRUD without any credential challenge

The instance held several thousand application records — names, emails, subscription status, and payment references — all readable and writable. Any host on the same flat corporate LAN could connect, dump the collection, modify records, or drop databases with no authentication challenge. The same network that hosted domain controllers and corporate workstations hosted an open database.

How it got here

The pattern is consistent across engagements. MongoDB is installed for an application or internal tooling. Authentication is left disabled during development to simplify connections. The service is deployed to a server on the flat network. Network-level controls are assumed to restrict access — but the assumption is never validated and the MongoDB port is never added to host firewall rules. No asset inventory entry lists the service. The version here — MongoDB 4.2 — is well past the era of unsafe defaults. The authentication was not missing because of a version issue. It was missing because it was never configured.

A second finding from the same engagement: Samba 4.2.x on a Linux file server, vulnerable to CVE-2016-2118 (Badlock), exploitable via MitM on DCERPC authentication negotiation using the LLMNR relay capability already established on the network.

The test timeline

Securing the instance

• Enable MongoDB authentication immediately. Add an application-specific user with minimum required privileges, set security.authorization: enabled in mongod.conf, and restart. Rotate all application connection strings to use the new credentials. Schedule a maintenance window if downtime is a concern — operating without authentication carries more risk.
• Bind MongoDB to localhost or specific application server IPs. Set net.bindIp: 127.0.0.1 if the instance is only accessed locally. If remote access is required, use host firewall rules (iptables, ufw) to restrict port 27017 to the specific source IPs that legitimately need access.
• Upgrade Samba and enforce SMB signing. Upgrade to Samba ≥ 4.2.11 and set server signing = mandatory in the Samba configuration. Signing eliminates both the Badlock MitM precondition and NTLM relay paths against the file server simultaneously.
• Expand internal assessment scope to include service inventory. Both findings here were invisible to scoped web application tests. A full-range Nmap sweep covering all RFC 1918 ranges in use would have discovered them in under thirty seconds.

The takeaway

Password-less database access requires no exploitation skill — any host on the same LAN is a database administrator. The MongoDB finding was not about a technical vulnerability in MongoDB. It was about a configuration decision that was never made.