Pen-Testing Silverlight+RIA with SoapUI

I was recently given the task of ensuring that a Silverlight+RIA application that could contain private information was secure for deployment to a public web site. So I started searching for automated pen-testing tools that could work against Microsoft’s Binary SOAP protocol (msbin1, a.k.a application/soap+msbin1) and found only disappointment. For various reasons, it’s significantly more complex to pen-test an application using msbin1 than traditional SOAP + WSDL.

To properly test the services, I had to make a compromise: temporarily modify the application to expose a SOAP endpoint. While this changes the state of the application and thus reduces the validity of the tests, it does provide a reasonable way of testing the web services to ensure that they are behaving as intended.

The recently released SoapUI Pro 4 adds new security testing tools that makes this a viable (and attractive option). To get this working, there are a few small changes that need to be made to the solution:

First, you’ll need to add a reference to Microsoft.ServiceModel.DomainServices.Hosting.EndPoints which is part of the RIA Services Toolkit; this allows you to expose different End Points for the service such as SOAP and OData.

Next, you’ll want to add the following configSections entry to your Web.config:

<configuration>
     <configSections>
       <sectionGroup name="system.serviceModel">
         <section name="domainServices"
          type="System.ServiceModel.DomainServices.Hosting.DomainServicesSection,
          System.ServiceModel.DomainServices.Hosting,
          Version=4.0.0.0,
          Culture=neutral,
          PublicKeyToken=31bf3856ad364e35" />
       </sectionGroup>
     </configSections>
     ...

Finally, to expose the SOAP end point:

<configuration>
     ...
     <system.serviceModel>
      ...
      <domainServices>
       <endpoints>
        <add name="Soap"
         type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
         Microsoft.ServiceModel.DomainServices.Hosting,
         Version=4.0.0.0,
         Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
       </endpoints>
      </domainServices>
      ...

Finally, just follow the instructions for SoapUI to set up your tests, and you can feel (just a little) more confident in your application. Passing with flying colors obviously doesn’t mean your application is bulletproof, but it helps to confirm that web service code is solid.

Now, while this does provide some insight into your application and should help find common issues, it’s not a replacement for a professional assessment by a qualified auditor. If you are handling credit cards or other highly targeted information, please consult a security specialist before a public deployment.

Update: Another option is a Burp plug-in offered by Gotham Digital Science, and can be found here. It’s a more complex workflow, but allows testing without an exposed SOAP end-point – which is great if you don’t have source code access.

Adam Caudill

Security Done Wrong: Leaky FTP Server

Update: I’ve just spoken to AMI, and received some very important information; so here are the key points and clarifications: To clarify, the ‘vendor’ I refer to is a customer of AMI; it is this customer’s public FTP server that exposed this information. Per AMI, the signing key included in the ‘Ivy Bridge’ archive is a default test key; AMI instructs customers to change the key before building for a production environment.

Thoughts on the iPad, from an Apple hater

Before I get started, let me make a couple of things clear: Apple is evil; pure and simple. I’m fully convinced that Steve Jobs has weekly planning meetings with Lucifer himself1. Apple’s policies are anti-everybody. From bloggers to developers2, Apple seems to make life as hard as possible for those that use their products for profit. With these facts in mind, I tend to shy away from their products when I have a choice (which isn’t always the case); though a while back I decided to buy an iPad for some reason.

Whose CVE Is It Anyway?

The latest vulnerability causing headaches across the world is CVE-2023-4863, issued by Google Chrome and described as “Heap buffer overflow in WebP in Google Chrome prior to 116.0.5845.187 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page”. This same CVE is cited by a number of other vendors as they are impacted as well. But, is this really a Google Chrome vulnerability?

Trojan Source and Why It Matters

Yesterday the news hit of a new vulnerability that threatens the security of all code; dubbed Trojan Source by the researchers from the University of Cambridge. From an initial analysis, it does seem to impact just about everything, and the status of fixes is very hit or miss at this point. But the real question is, does this even matter? Is this issue worth spending your time on? Let’s look closer.

Declaring War on Ransomware

It’s time for everyone from the industry, developers, and the government to declare war on ransomware and make it as hard as possible for them to ply their insidious trade. There have been false starts and baby steps, diligent fighters without enough resources, and vendors that have only given a nod to the issue. It’s time to use every tool reasonably available to stop this scourge. For so many in the industry that have dedicated so much of their time and effort to this fight, this statement may seem to diminish their efforts, but that is not my intent.