Performing some Silverlight penetration testing? I’m sorry for your luck. If you’re like me, you’ve invested some time into investigating just which tools and techniques are currently available and functioning. If not, I hope to save you some time by describing my approach. Of course, it should go without saying that your client/developers should be moving away from the platform, which will no longer be supported by the end of this year. Nevertheless, upgrading old platforms isn’t always immediately possible and it’s important to understand the risk of application flaws even if there is no one available to remediate them. Let’s get into it.
My Silverlight penetration testing environment:
- Windows 10 VM (VMWare Workstation)
- Burp Suite Professional
- Internet Explorer 😐 (with Silverlight installed)
- OS-wide proxy to Burp (127.0.0.1:8080)
- [Optional] SOCKS Proxy from Burp to my primary testing host (via PuTTY)
You should have no trouble configuring your environment in such a way if you so choose. You don’t have to do it this way, but you will – at very least – need a browser that can run Silverlight and proxy its traffic through Burp. Once you have your testing environment set up and start to intercept communication, you are likely to identify a few unique features of Silverlight:
- The application is likely supported by WCF (Windows Communication Foundation) Web Services, which offers support for a number of communication mechanisms and data format types. In the most annoying case, the Silverlight application will make use of NBFS, which is a .NET Binary Format. In HTTP, you will see the Content-Type of application/soap+msbin1.
- At some point, the application will download a .XAP file and possible additional .DLL files (or compressed as .ZIP). These are the Silverlight binaries that form the client-side logic of the application.
This informs us of the types of tools we are going to need to thoroughly examine the surface area of this application. First, we will need a way to view and modify NBFS content within Burp. For this, the extension that I found to be most up-to-date and stable with recent Burp versions is Jonathan Murray’s WCFDSer-ngng. You will have to follow the instructions provided to manually install this plugin along with the NBFS executable. I didn’t initially find this plugin from a search, but identified it on this great curated list of Burp plugins.
Once the plugin is installed, you should be able to directly decode NBFS HTTP content within various tools. For example, in Repeater, simply select the extensions drop down and click the “Deserialized WCF” plugin to switch from “Raw”:
The content of the window should change from HTTP headers with binary content (prefaced by the “VsaVD” string that appears to be the “magic number” conversion of the initial binary) to human-readable XML. You can now more easily tamper with request data and view the corresponding responses.
I did notice a stream of errors from the plugin, but this didn’t appear to have an immediate impact. If you experience the same and have some free time, I’m sure someone would be thankful if you identified and remediated the bug.
Unfortunately, when using the plugin, you will lose Burp’s recent capability to beautify different content, so the XML is likely to appear a bit messy within Burp. Especially for large requests, I would recommend beautifying with a tool like Cyber Chef at least to obtain an initial understanding of the structure in use.
Examining deserialized binary messages may be a good way to map the initial surface area of the application, but typically WCF Web Services will expose additional communication mechanisms that may be easier to test (and, quite likely, they may expose the API). For more on attacking WCF Endpoints, check out “Attacking WCF Web Services” by Brian Holyfield. Here is another talk by Chris Anastasio from 2019. If you intend to test beyond HTTP (NET.TCP), take a look here. There are many good resources accessible from a quick search as well.
In my previous test, the web service exposed WCF services as .svc files, which permitted a number of different interfaces for various data formats. For example, NBFS communication would use the path /WebService.svc/sl whereas I could also interface with regular XML (SOAP) via /WebService.svc. In most cases, it appears that these services should also expose WSDL via /WebService.svc?wsdl. For integration with Burp, I recommend the plugin WSDLer, which can parse the WSDL and provide you with prepared requests.
After you assess the security of the web services, your next task concerns the client-side portion of application, starting with the binaries – these are the files consumed by the Silverlight plugin that effectively replace what would typically be JavaScript/HTML implementations. To fully explore the functionality offered, you will have to reverse engineer these binaries. Searching for something like “Reverse engineering Silverlight XAP” in 2021 yields many results that point to outdated tools or tools that have since become paid. I recognize that I have already necessitated paid software (Burp), but I expect that most penetration testers already have a professional copy. I don’t expect most penetration testers to have a professional tool for reverse engineering .NET binaries. This may come in handy from time to time, but may not be worth the expense for you.
For this task, I used ILSpy – an open-source .NET assembly browser and decompiler. Based on my experience with the tool, I would recommend it. It was easy to setup, straightforward to use, and did everything I needed. To get started, you will need to unzip the .XAP file and then import the .DLLs of interest. What you are looking for and how valuable reverse engineering will be in your case is highly dependent on the application.
Finally, you will want to examine whether the Silverlight application is storing sensitive information on the client machine. In a Windows 10 environment, Silverlight Isolated Storage is likely to be located here: %userprofile%\AppData\LocalLow\Microsoft\Silverlight\is. There appears to also be a way to view application storage via the Silverlight Configuration application:
And that’s it! You may find at some point that you need to learn more about Silverlight itself. For that, here you go. Good luck!