search

Appsanity

hashtag
Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.47.100
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-31 12:15 EDT
Nmap scan report for 10.129.47.100
Host is up (0.0076s latency).
Not shown: 65531 filtered tcp ports (no-response)
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
5985/tcp open  wsman
7680/tcp open  pando-pub

Interestingly, WinRM is open, so evil-winrm might be used here. Did a detailed scan as well:

$ nmap -p 80,443,5985,7680 -sC -sV --min-rate 3000 10.129.47.100
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-31 12:17 EDT
Nmap scan report for 10.129.47.100
Host is up (0.0086s latency).

PORT     STATE SERVICE    VERSION
80/tcp   open  http       Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Did not follow redirect to https://meddigi.htb/
443/tcp  open  https?
5985/tcp open  http       Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
7680/tcp open  pando-pub?
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

I added meddigi.htb to the /etc/hosts file and started Burpsuite for some web enumeration.

hashtag
Web Enum

The website redirected me to the HTTPS version, and it shows a medical corporate website of some sorts.

There's a 'Sign In' option, and I created a new user and signed in to view the dashboard.

There's a password reset function, as well as a message sending function to the administrators of the site. The password reset had nothing interesting, but viewing the request did show me a JWT token.

When decoded, it gives these values:

Interesting. I played around with the other functions from this website but there was just nothing of interest. Next, I ran a directory scan with gobuster + feroxbuster and a subdomain scan with wfuzz. The latter picked up on a portal subdomain.

The portal subdomain just brought me to this separate login page:

hashtag
Doctor Account -> Cookie Reuse

When checking the requests proxied, I noticed that there was an AccType parameter in the POST request to Sign Up as a new user.

I changed this value to 2, and the dashboard now has a new function:

I created a new user and was able to assign them to this account:

When I logged in as the 'patient', I could see that I was assigned a doctor (test test)

There was nothing inherently interesting about this patient function, but by re-using the JWT cookie, I could login to the portal subdomain.

hashtag
Doctor Panel -> File Upload + SSRF

I took a look around the portal, and found some interesting functions. The most interesting was the file upload function:

This website was running on IIS, so uploading a .aspx shell might be the way in. When I tried to upload a .jpg file just to test, the website errored and said only PDFs are allowed.

Apart from this, there was also a Prescription Scheduler, which allowed me to enter links:

I entered my own IP, and found that it was vulnerable to SSRF:

When I entered http://127.0.0.1 as the URL, it returned the webpage itself:

I played with other ports, and found that port 8080 returned something interesting:

The very end of this had a link to /ViewReport.aspx?file=eefeccb8-4c86-45b4-a38d-81754324a11b_Cardiology_Report_1.pdf, which tells me exactly what I need to do. I just have to upload a .aspx reverse shell, and find a way to bypass the filter, then use SSRF to 'read' the report which would trigger the shell.

I first just downloaded some .aspx shell from Github.

Logoaspx-reverse-shell/shell.aspx at master · borjmz/aspx-reverse-shellGitHubchevron-right

Then, I tried various methods of file upload bypasses:

  • Null byte extension

  • Content-Type set to application/pdf

  • Double extensions

None of them worked, so I tried using Magic Bytes.

LogoBypassing File Upload Restriction using Magic BytesMediumchevron-right

Using hexeditor -b, I added the file signature of PDF files via Ctrl + A:

This worked! Now, I used the SSRF to access this report. When using SSRF to check the reports available, I saw a second report:

This shell works on port 21:

hashtag
Privilege Escalation

hashtag
Examination Panel -> DnSpy -> DevDoc

The svc_exampanel user had one interesting file within their directory:

Not too sure what this means, but I checked out the c:\inetpub\ExaminationPanel directory to find out more.

There's one custom .dll file there, which we might need to reverse. Copied this file back to my machine via smbserver.py, then broke it open in dnSpy.

This whole thing was massive, and it took quite a while to look through everything. The LogError function was the one that generated the file earlier:

Within some of the code, there's mention of an 'encryption' thing:

Reading this shows that it takes a key from the registry:

I used reg query to find this value:

Checking the C:\users directory, I could find a few other users:

Using this password, I could evil-winrm in as the devdocs user:

hashtag
Binary Analysis -> DLL Hijacking

When checking the C:\Program Files directory, I found an ReportManagement directory:

Checking the permissions on this file shows that devdoc has RX privileges over it:

Within this file, there's a ReportManagement.exe file:

I downloaded this to my machine via smbserver.py, and took a look at the decompiled version using this site:

LogoDecompiler ExplorerDecompiler Explorerchevron-right

There were some interesting things from the RetDec output. Firstly, there was mention of the Libraries directory when I searched for \\:

When checking the ACLs for this directory, I saw that devdoc has Write access to it:

Perhaps the application was using functions from a DLL file within there. I ran this binary on my Windows VM and started x64dbg to see what was happening. Within the Logs, I saw that mswsock.dll was being loaded.

This DLL is used for network communication via sockets, meaning this application could be opening a port or reaching out to somewhere. When checking the ports of my Windows VM and the actual machine, I noticed that port of them had port 100 listening.

netstat -a -b on my Windows VM confirms it:

Additionally, I found some extra information about the usage of this binary.

When it was run on my Windows VM, it generated the same reportmanagement_log.txt file I found earlier:

I tried connecting to it via nc, and it showed me the things I found earlier:

When trying to upload something, x64dbg tells me that the binary errors out due to some directories not being present:

I created each of these directories. Attempts to the upload or recover functions fail:

When I checked the decompiled output, I noticed that this error appears after trying to use CreateProcessW with a cmd.exe instance.

There's also this part here which mentioned externalupload:

Question, is why is it using that string for memcmp? The only guess I had was that it was being checked to see if it was being loaded, which means that it externalupload is the name of a DLL file. Makes sense since our user devdoc conveniently had write access to the Libraries directory.

Additionally, I was unable to run the actual .exe myself on the machine due to 'Access denied', indicating that it was owned (and probably run) by the administrator.

To exploit it, first I generated a malicious DLL file via msfvenom, then uploaded that to the Libraries directory. I tried a lot of payloads, and for some reason this one works.

Afterwards, I used chisel to forward port 100 to my machine so I could access the service, and then used nc to execute all the commands available. One of them eventually executed the .dll file and gave me a shell:

Rooted!

PreviousAnalyticsNextCodify

Last updated