| Service | Port | Notes |
|---|---|---|
| MySQL | 3306/tcp | Version 5.0.51a, root account with no password set |
| PostgreSQL | 5432/tcp | Version 8.3, default install credentials unchanged |
Why It Exists
Both databases were left in their out-of-the-box configuration: listening on all network interfaces rather than just localhost, with default or blank credentials never rotated after install. This is one of the most common real-world misconfiguration patterns — a database installed correctly, then never hardened afterward.
How It's Identified
A port scan finds the database ports open to hosts other than the application server that should be their only legitimate client:
nmap -sV -p 3306,5432 192.168.56.101
Confirms both ports are open and reports the version banners. A direct client connection attempt with the documented default credentials then confirms the exposure without needing any exploit code.
The Lesson
A database almost never needs to be reachable from anywhere except its own application layer. Exposure this direct is one of the most consistently seen root causes in real breach postmortems — not a sophisticated exploit, just a service that was never told to stop listening on the public interface.
How Defenders Mitigate It
Bind databases to internal-only network interfaces (or localhost, if the application runs on the same host), enforce strong unique credentials rotated from any default, and firewall database ports from general network access so only the application tier can reach them. Least-privilege database accounts — never a shared root/superuser login for application traffic — limit the damage even if one layer of defense fails.
Only interact with this service inside your own isolated Metasploitable 2 lab. Testing it against a system you don't own or have written permission to test is illegal in most jurisdictions.
Related: the misconfigurations page for the broader pattern this exposure fits into.
FAQ
Is this specific to MySQL and PostgreSQL as products?
No — both are solid, widely used databases. The issue here is entirely the configuration Metasploitable 2 ships with, not a flaw in the software itself.
Would a firewall alone have fixed this?
In this case, yes — restricting database ports to the application server's address would have closed this exposure without changing the credentials at all, though fixing both is the safer real-world practice.
What database versions run on Metasploitable 2?
MySQL 5.0.51a and PostgreSQL 8.3, both from the same era as the rest of the image and both left in their default post-install state.
How would I check a database connection without exploiting anything?
A standard client connection attempt with the documented default credentials is enough to confirm the exposure. No exploit code is required; the finding is the fact that the connection succeeds at all from outside the application tier.