Constrained environment breakout. .NET Assembly exfiltration via Internet Options

It’s not uncommon for developers to find that they need to help their end users. For starter, the business requirements for software can be highly convoluted and technical. Working with banking systems, insurance firms, actuarial services etc, most developers aren’t going to understand the process they need to add into their software.

As the software becomes more intricate, end users often find problems navigating the software, and that doesn’t help a business whatsoever. Without proper documentation, help desks are going to become overrun with requests that the developers think are easy, but end users are struggling with. So how do developers resolve this issue? They provide documentation in various ways to help their users.

This documentation is often a gold mine for penetration testers and security researchers alike. They give us an understanding of an API so we can hunt for rogue parameters. This software supports tasks which run on the underlying operating system? Looks like a quick win. Then there’s the breakout assessment, where help functions have assisted pen testers in bypassing security restrictions since Citrix first thought of Receiver.

We recently had a client come to us looking for us to test an application they’ve developed. Access to the application is allowed through an RD Web connection, and when you’ve successfully authenticated, you’re presented with their highly complex software with hundreds of sub-menus.

There’s no desktop, and they’ve restricted pretty much everything they can. However, the software is complex as I mentioned, and because of that, they’ve left open a little help function filled with CHM files. In this pop-out we see the start of our breakout.

Here we see that there are print and options menus. When we print to documents, we can start trying to view the file structure and overwriting files. However, this client is no slouch, so just directing accessing the C:\ drive through the file explorer isn’t possible. Also, our standard way of executing code on the remote host isn’t going to work, as we want an open, rather save function. Instead, there’s a better way.

Internet Options is available, and that’s much better. In your privacy tab, you can choose to import internet settings files. So initially, we’re going to look at basic enumeration of the underlying operating system. The more you enumerate, the higher chance you have of a successful exploit. We’ll use a well known method of bypassing  C:\ drive restrictions, which half worked but gave us a basic understanding.

First off we start a search:

Here we have the custom option, which allows us to bypass some restrictions. We open the custom search function and define the C:\ drive for our search location. From here, we can start seeing folders, but no actual files.

Great, we can enumerate some information now. We look at the programs files folders in order to see what’s installed, and we can look at the users directory, giving us some usernames. In this situation, the program files folder is more useful as we’re looking for some kind of command execution. Furthermore, by checking for other drive letters. We find the D: drive, and in there we find a folder named after the overarching application.

Next we’ll look at trying to get some code execution. Taking a look at the open file explorer prompt, I can see that my laptop drives are mounted as volumes.

This is a great start. From here we can drag and drop files onto executables, and if they’re not blocked, then it will execute on the server. Blocking is provided by the AppLocker configuration, so we’re looking to bypass these restrictions.

We start off simple, we create a folder in C:\ called temp so we don’t have to go down too many folder levels in order to get to the folder we’re testing from. Then we copy and paste WScript.exe into the temp file (other will work but WScript is usually unprotected in some way by AppLocker). Then we create a file called exploit.vbs. The code is simple.

MsgBox(‘Remote Code Execution’)

By entering *.* into the filename, we can view all files located in the folder. When we drag and drop the VB Script onto the WScript.exe executable, the application is blocked. We start looking at AppLocker bypasses, and the best way is to rename the file to some other executable which isn’t blocked and hope that the paths aren’t configured in AppLocker. How do we decide what we’re going to try? Well we’ll start with this list.

https://github.com/api0cradle/UltimateAppLockerByPassList

After some painstaking work, none of these bypasses work, and we now know that these guys have put the leg work in on their AppLocker policy. Next step then, if we can’t access the C Drive through the file explorer, we might be able to use shortcuts to the executables we are testing.

By dragging and dropping the VB Script onto the shortcut, the file is passed to the executable linked by the shortcut. Using the same list as before, we start creating these shortcuts. During this process, we can determine whether a file exists or not based on the error message.

This error confirms that the shortcuts are successfully bypassing the C:\ drive restrictions and allowing for the potential of code execution, if we discover an application that executes arbitrary code.

Due to the nature of the environment being tested, all calls outside the network the server is located on are blocked. Upon code successfully executing, if we are looking to create a reverse shell, we’ll have to rely on insecurely configured custom RDP channels, which would allow a connection back to our host device. This is further along than we’ve gotten so far, right now we’re looking for any code execution at all.

After exhausting the AppLocker bypass list, we’ll look at other potential options that logically work for the idea of executing programs on the C:\ Drive. The application we are using should execute, as it needs to be in the allow list for AppLocker or the application won’t run when we login. Furthermore, within the help options there’s a link to a corporate portal using Internet Explorer, so we know Internet Explorer should also be available for execution.

By using the errors mentioned above and inspecting the file structure of the D:\ drive using the custom search function, we can test whether we can find the application executable. Creating a shortcut to the name of the application as an executable located in the D:\ drive folder which was discovered to be named the same as the application and dragging and dropping the VB script to the shortcut, appears to have no effect.

The implication here is, the file does exist, because otherwise we’ll get an error stating it doesn’t, and it isn’t blocked by AppLocker, or another error will occur saying the executable is blocked. Instead the executable has set to only run once on an instance, and with the application being live, nothing happens.

Secondly, we look at Internet Explorer. Creating a shortcut means we should be able to open arbitrary files from our own C:\ drive.

Next we create a basic html file, and I add some JavaScript with a basic payload.

<script>alert(1)</script>

Looking at the file name, we can see that Internet Explorer is opening a file over a volume. This means that the JavaScript is actually being executed on the client’s server, not my own device. So we essentially have Server Side XSS. What’s interesting about Server Side XSS is there’s basically no documentation out there on the subject, and where you do find information, it’s in a different context.

Server Side XSS is usually found in dynamic PDF generators, where you can supply an input that is generated into a PDF file, that can then be downloaded. If the input is not filtered correctly, you can perform multiple attacks by supplying the correct payloads. These include read files on the device, or perform Server Side Request Forgery attacks.

First we’ll try a little more advanced, but still pretty basic exploit. We’ll try to get the application to spit out a user-agent on error, using the following payload.

We start testing for the other Server Side XSS exploits. The file read does not work, and we don’t get the information we wanted, similarly, we attempt an SSRF exploit, still not displaying anything we’re looking for. Not great, but we can approach this in a different way.

When I discovered Internet Explorer was available and could attempt to access the help portal and failed, I looked into exploiting it for my own purposes. The URL bar had been restricted, so you can’t just change the URL as you normally would. However, the RDP channel you connect to the application allows for the clipboard to be mirrored on the application.

This is great, because you can bypass the address bar restriction using Internet Explorer shortcuts. Ctrl+Shift+L takes whatever is in your clipboard and launches it in the address bar. So, your standard breakout methodologies apply. For example:

File://C:\Windows\System32\cmd.exe

Smb://127.0.0.1/c$/Windows/System32/cmd.exe

When launching these in internet explorer and modifying the location from cmd.exe, I keep getting blocked. So we look at abusing our shortcuts further. We start with a shortcut to the application executable, similar to the Internet Explorer shortcut which we use to open html files.

This doesn’t work as expected, as Internet Explorer launches a download prompt, which is good, but for the LNK file we have created, which is bad. We basically download the shortcut we created, no real disclosure there. Instead, we create an internet shortcut, and use the file structure to try and bypass the restrictions.

When we drag and drop this shortcut on the Internet Explorer shortcut, we get a file download for the underlying executable. I change where the file is downloading to my mounted C:\ drive, and as it downloads pray this is the actual executable that we want.

Opening the executable in DNSpy shows us this is the assembly for the application we’re testing! And on top of that, the code is not obfuscated, so we can browse through the code as we see fit. From here, there are configuration files listed, associated DLLs, source code for API endpoints used by the backend of the web applications packaged into the product.

Some interesting items discovered included a GRAPHQL API endpoint that appears to render Razer, which could’ve been a quick move into Server Side Template Injection if the users we had been given were able to authenticate. The assembly itself was huge, and unfortunately, as is the world with pen testing, we had time limits on the amount of time we could spend analysing the assembly. The client also resolved the issue as it was reported, limiting the amount we could exploit the file read that was discovered.

There was therefore, a lot of potential for a malicious actor who decided not to disclose this vulnerability to find further exploits given an extended timeframe. Furthermore, this application is sold as SaaS, and the source code of the web applications are also included.

Stealing all the source code we can find, then repackaging the application with our own brand, we could’ve sold our own version of the application, and the amount of time and expense to code the application would be minimal in comparison to our client’s.

Conclusion

So what are the lessons here?

• Well first off, Internet Options allows for easy methods of executing code on the server, so definitely restrict access if you can.
• Secondly, AppLocker can be bypassed, so make sure your settings are extremely well inspected.
• Thirdly, Internet Explorer can be used to exfiltrate data, so the link to the help portal may cause you more problems than you realise.