RCE Vulnerability on shared Windows 2012 server potentially exposed 520 websites

Timeline

;

Introduction/Backstory

Earlier in the week I was looking for a boat to rent for Kingsday (national holiday in Holland) on bootverhuur.nl, and noticed that the site had file upload functionality. So I made a mental note, so that when I had time, I could look at its security.

Vulnerability

I discovered that:

  1. It was possible to upload arbitrary ASPX files, and execute commands.
  2. The shared hosting server didn’t adequately restrict the permissions of isolated users.

Reconnaissance

File upload functionality
Image 1: File upload functionality

 
So lets try to upload our own “image” to the server.
 

Image 2: The response headers
Image 2: The response headers
 
The response headers indicated that it was running an ASP.NET site on an IIS server.
Lets make an “image” crafted for those specifications.

mage 3: ASPX payload that executes command in GET parameter when invoked and returns the output
Image 3: ASPX payload that executes command in GET parameter when invoked and returns the output
 

Testing

After uploading the ASPX payload, it would embed our file through a controller in order to resize our “image” dynamically, this does not allow use to execute the “image”, because the backend would simply try to parse our “image” as an image, resize it and return the resized image.

Image 4: Indication that our “image” made it past server-side validation.
Image 4: Indication that our “image” made it past server-side validation.
 
However, the original file extension (“.aspx”) was preserved, which was a clear indicator for me that it made it past validation.

We have to find what the true path of our payload is in order for our payload to execute.

I was looking in the HTML source code for clues that might reveal the true path of my uploaded payload, when I noticed the following

Image 5: Image path revealing pattern needed to get a direct reference to the payload
Image 5: Image path revealing pattern needed to get a direct reference to the payload
 
Now we know that the pattern is:

Default (through image resize controller,not what we want):
/mediadepot/[ORIGINAL FILENAME] &someparams&image=[UNIQUE ID].[FILE EXT] 
Absolute path (What we want):
/mediadepot/[UNIQUE ID]/[ORIGINAL FILENAME]

When we apply the absolute path pattern to our “image” we get the following result:

Default pattern: /mediadepot/test7.aspx&someparams&image=48594dcbae94.aspx
Absolute path pattern(applied): /mediadepot/48594dcbae94/test7.aspx

Lets test it out.

 Image 6: Now we know the absolute path of our payload. Which allows us to invoke it, and run commands on the server.

Image 6: Now we know the absolute path of our payload. Which allows us to invoke it, and run commands on the server.

Other relevant data

  1. Parsed list(Either marked OK for active or PARKED for parked domains)
  2. Saved HTML responses of the sites, so that you may verify the parsed list yourself.

Conclusion

The shared hosting was configured as the following.

For each (group of) website(s) a separate user was created. This user was restricted to their respective web root(s) on drive D: . The isolated user also had full read/execution (and in some cases write) access to the system drive. The access to the system drive is unnecessary. In some cases it might be required to give a specific application specific rights in order for it to operate (like execution rights to an executable on the system drive, so that the application may use this specific executable to, for instance resize images). It is difficult to setup shared hosting securely on Windows machines, since some access is required for the global assembly cache. Isolating websites via e.g. a VPS is my advise.

 

Q&A

Did you, in the process you described, endanger the site yourself?
The RCE-payload I uploaded was on the server between 15/03 22:30 and 16/03 12:00. After that it was removed by Tres. In order for someone to use my payload he would have to guess the combination of the unique id, filename and parameter name, within the mentioned time span. So no. It would be easier to find the RCE vulnerability itself.

Did you actually have access to the code/databases of all the other hosted sites?
No I did not. The process of doing this goes past the bounds of ethical hacking(things like starting a meterpreter session,infecting writable service executables with own payload) . I did not test it, so I can’t claim that I did. However, I can provide you with indicators that make me believe it might have been possible. I want you (the reader) to draw your own conclusions based on the evidence I provide in this disclosure.

What about the data of bootverhuur.nl?
Only one can be true, I’m leaving it up to you (the reader) to decide which one.

 

Image 7: Email from Tres, answering some questions I had asked them regarding the amount of affected bootverhuur.nl users
Image 7: Email from Tres, answering some questions I had asked them regarding the amount of affected bootverhuur.nl users
 

Image 8: Homepage of bootverhuur.nl
Image 8: Homepage of bootverhuur.nl
 
 

What did you do with the data?
When I do projects like this, I create a RAM disk where I store things like BURP sessions, Python data parsers to create the statistical information I provide in this disclosure. The contents of a RAM disk are lost when you power down the computer(assuming you don’t live in a freezer). All the obtained data is gone, with exception of some screen-shots and a tiny set of data as evidence(some command output in this case), which are stored on an encrypted drive.

Questions I asked them:

How did you verify the data wasn’t obtained by anyone else?

The Tres representative has told me that they have analyzed the log files and have come to the conclusion that I was the only person who gained unauthorized access to the server.

 

Author

Nelson Berg (Information Security Advisor @ Securify B.V)

Contact me

Follow me