| Service | Port | Notes |
|---|---|---|
| Samba | 139/tcp, 445/tcp | Version 3.0.20, "username map script" command injection (CVE-2007-2447) |
Why It Exists
Samba's smb.conf supports an optional username map script directive, intended to let an administrator run a custom script that maps client-supplied usernames to local system accounts. Versions 3.0.20 through 3.0.25rc3 passed the client-supplied username straight into a shell command without sanitizing shell metacharacters first. Rapid7 enabled this option and left the vulnerable Samba version in place specifically so learners have a real, historically significant remote-code-execution bug to study, not just a permissions problem.
How the Command Injection Mechanism Works
Because the raw username reaches a shell invocation unescaped, a client can supply a username containing shell syntax — such as backticks or a subshell expression — instead of an ordinary name. Samba then executes that syntax as part of the mapping script's command line, running whatever the attacker embedded with the privileges of the Samba service itself. No valid password or prior authentication is required, since the injection happens during the username-mapping step, before normal authentication would even occur.
How It's Identified
Version enumeration is the first signal:
nmap -sV -p 139,445 192.168.56.101
Reports the Samba version. "3.0.20" falling inside the 3.0.20–3.0.25rc3 range is what flags this specific CVE as applicable, the same way "vsftpd 2.3.4" flags the FTP backdoor.
SMB share enumeration (with tools built for that purpose) is still worth doing separately, since permissive share configuration is a real, additional finding on top of the command injection issue — the two are distinct weaknesses that happen to sit on the same service.
The Lesson
This is a textbook example of why user-supplied input should never reach a shell command without strict sanitization or, better, without invoking a shell at all. It's also a reminder that a single optional configuration directive — not a core protocol flaw — can turn an otherwise-reasonable service into a full remote-code-execution path. Misconfiguration and unpatched code aren't separate categories here; this vulnerability is both at once.
How Defenders Mitigate It
Patch Samba beyond version 3.0.25rc3, or disable the username map script option entirely if it isn't specifically needed. More broadly: never pass unsanitized user input to a shell invocation; use parameterized system calls or safe subprocess APIs that don't interpret shell metacharacters at all. Apply least-privilege share permissions as a separate, additional control, and disable legacy SMB protocol versions (SMBv1 in particular) wherever they aren't required by old hardware.
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 legacy services page for more protocols in this same category, and the FTP page for a second historically significant, specifically-versioned vulnerability on this image.
FAQ
Is SMBv1 still found on real networks?
Yes, particularly on older printers, NAS devices, and legacy line-of-business systems that were never upgraded, which is exactly why this remains a relevant lesson.
Does disabling SMBv1 break anything modern?
Almost never. Current Windows, macOS, and Linux systems default to newer SMB versions; SMBv1 is typically only needed for very old hardware.
What CVE covers the Samba vulnerability on Metasploitable 2?
CVE-2007-2447, a command injection flaw in Samba's "username map script" feature, affecting Samba versions 3.0.20 through 3.0.25rc3. Metasploitable 2 ships Samba 3.0.20.
How does the Samba username map script vulnerability work?
When the "username map script" option is enabled, Samba passes the client-supplied username to a shell command without sanitizing shell metacharacters. A crafted username containing backticks or shell syntax can inject and execute arbitrary commands with the privileges of the Samba service.
Why is this considered one of Metasploitable 2's most well-known vulnerabilities?
Because it results in unauthenticated remote code execution with no login required, and is one of the most commonly taught first exploits in introductory penetration-testing courses using this VM.