Pentesting Silverlight and WCF RIA Web Services

During a recent test I have encountered a Silverlight application with WCF RIA web services on the server side.

Silverlight application runs in the browser. It is conceptually similar to a Java applet. The compiled code is downloaded to the browser where it is executed in a sandbox. The client side communicates to the server. In case of the application I was testing, the server side was implemented as several web services.

Silverlight can use different means of communication to the server. The previous version of the app I wasa testing application used plain HTTP with JSON data in the body. That was pretty straightforward to test, as both requests and responses could be edited in an intercepting proxy, such as Burp.

The newest version however, used a binary communication format called MSBIN1. Editing it in an intercepting proxy breaks the message format, so the server discards the message. I have tried the Burp plugin that decodes MSBIN1 messages and allows editing them in Burp. It mostly worked well, except failing to decode some of the messages. It so happened that those were the messages that I particularly wanted to mess with, so I had to find another solution.

The good news is that WCF RIA web services offer several interfaces. Apart from Microsoft proprietary binary SOAP format, they can also be accessed via plain old SOAP.

So, I have fired up soapUI and fed it the WSDL for each of the web services used by the application. (By that I mean, first exploring the application in browser, while recording the requests and responses with Burp, then noting the web services URLs, which look like /Application/SomeService.svc , and then feeding URLs like http://www.example.com/Application/Service.svc?wsdl to soapUI). SoapUI retrieves the WSDL and constructs the sample requests to all discovered methods. You can send the request and look at the response.

My application required authentication, and used .ASPXAUTH cookie as session ID. soapUI allows adding arbitrary headers to the requests, so I logged in to the application with the browser, and copied the Cookie: header to soapUI request. This way I could send authenticated requests, edit them, and observe the results. A web service fuzzer may also be used to supplement manual testing.