Hacking Silverlight part 3

This post should be called Hacking WCF as I will show some configuration hacks in WCF. Read part 2 here where I discussed the clientaccesspolicy.xml and crossdomain.xml files.

The Csla WcfPortal I discovered in part 1 (here) is my next subject. A WCF service can expose meta information to generate a proxy for access from code. The meta information is requested by adding the ?wsdl query to the service endpoint. An example: http://www.restfulwebservices.net/wcf/CurrencyService.svc?wsdl.

Fortunate for me the meta information is exposed. Now I can generate a proxy and use it in a console application. Gotta love the commandline 🙂 The first call gives and exception about the security settings. The response hands me a list of allowed security settings. After adding credentials (which I was given) my application can read records from the WcfPortal. I am in.

Why was the meta information exposed? The information is not needed for normal operation. Probably a developer forgot to turn the setting off in the web.config.

Now the fun part starts. Getting the WcfPortal to give me information it should not give by experimenting with the parameters. Every exception thrown inside the service is send back to my hacking application. Now I get a good sense of what is happening in the service.

Why are the exception details send back to my application? Again a setting in the web.config that should be changed.

<configuration>
  <system.serviceModel>
    <!-- Other stuff removed for clearity -->
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- set httpGetEnabled to false to stop exposing meta information -->
          <serviceMetadata httpGetEnabled="false" />
          <!-- set includeExceptionDetailInFaults to false to stop exposing exception details -->
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

In regard to the previous findings I rate these settings a higher security risk. They expose information you don’t want to expose and can even be seen as an open invitation to get hacked. The effort to change these two settings is nothing compared to the damage they could cause.

Posted in Security | Tagged , , , , , , , , | Leave a comment

Hacking Silverlight part 2

My trip down hackers lane continues. Read part 1 here where I discovered the Csla WcfPortal is used. Before starting my “attack” I do some recon.

Silverlight has a build-in security step that requests the clientaccesspolicy.xml file before allowing a connection to a network resource. When that request fails the crossdomain.xml file is requested. Both files exist on the host of the Silverlight Portal. I could host a XAP on a bogey server and no bells would go off accessing the WcfPortal.

Clientaccesspolicy.xml

The content of the clientaccesspolicy file below allows access to all network resources (like services) on the host. By editing the highlighted line to contain something like uri=”http://my.domain.com/&#8221; only a XAP file hosted on my.domain.com port 80 has access to the network sources.
💡 TIP: use the domain of the source parameter from the object tag in the html page that embeds the XAP.

<?xml version="1.0" encoding="utf-8" ?> 
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*" /> 
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" /> 
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Also the access to all resources is granted in the grant-to section on line 9. Maybe some restriction could be applied there as well. Like the Services directory where the WcfPortal lives.

Crossdomain.xml

Silverlight uses the Adobe file crossdomain as fallback when the clientaccesspolicy is not available. Only when the file grants unresticted access, like the code below, Silverlight uses the file.

<?xml version="1.0" encoding="utf-8" ?> 
<cross-domain-policy>
  <allow-access-from domain="*" /> 
  <allow-http-request-headers-from domain="*" headers="*" /> 
</cross-domain-policy>

No changes should be made, except maybe remove the file.

Are these files a security risk? They might be. Think about restricting access as another hurdle a hacker must take and how much it would be in your way.

Posted in Security | Tagged , , , , , | 2 Comments

Basic authentication in selfhosted mono service

I want to secure my selfhosted service on mono with basic authentication. This works with an Authorization header in the http request and can be setup with configuration for the binding. The setting BasicHttpSecurityMode.TransportCredentialOnly only encrypts the header and no SSL certificate is needed. See code below.

[ServiceContract]
public interface IPrintable
{
    [OperationContract]
    void Print(string textToPrint);
}
// service implementation
public class PrintService : IPrintable
{
    public void Print(string textToPrint)
    {
        Console.WriteLine(textToPrint);
    }
}
// selfhosted
static void Main(string[] args)
{
    // address for the service
    var baseAddress = String.Format("http://{0}:1234", Environment.MachineName);
    var host = new ServiceHost(typeof(PrintService), new Uri(baseAddress));
    // binding with encrypted usename/password in header
    var binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);
    binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
    binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.UserName;
    // create endpoint for serviceontract
    var endpoint = host.AddServiceEndpoint(typeof(IPrintable), binding, "/PrintService");
    // start the service
    host.Open();
    // wait for user to stop service
    Console.WriteLine("Host opened. Press <CR> to end.");
    Console.ReadLine();
    // stop the service
    host.Close();
}

Basic authentication works as follows:

  1. The client sends a request
  2. The server responds with a HTTP401 (Unauthorized) and the accepted authentication methods in the header [WWW-Authenticate: Basic realm=””]
  3. The client resends the request with the Authorization header containing the username and password [Authorization: Basic VGVzdDpQYXNzd29yZA==]
  4. The server processes the Authorization header and services the request, the response is a HTTP200 (OK)

Hosting the service on mono 2.6.7 this works as described. But on mono 2.10.8 this is broken. Inspecting with fiddler showed the server responds with a HTTP401 in step 4 without the accepted authentication methods in the header. fiddler screenprint of failing basic authentication on mono 2.10.8
See client code below and try for yourself.

// client
static void Main(string[] args)
{
    // address the service is listening on
    var url = String.Format("http://{0}:1234/PrintService", Environment.MachineName);
    var address = new EndpointAddress(new Uri(url));
    // binding with username/password in header
    var binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);
    binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
    binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.UserName;
    // contract
    var factory = new ChannelFactory<IPrintable>(binding, address);
    // create the proxy with username and password
    factory.Credentials.UserName.UserName = "Test";
    factory.Credentials.UserName.Password = "Password";
    var proxy = factory.CreateChannel();
    // invoke the print operation
    proxy.Print("Hello world");
}

Submitted bug 4993 to xamarin.

Posted in Development | Tagged , , , , , , , , , | 6 Comments

Hacking Silverlight

Someone asked me to hack his Silverlight portal. The goal was to test the security and to give some recommondations for future projects. This is part one of my trip down hackers lane.

As a Microsoft developer I know Silverlight is an simplified version of the .NET framework. The XAP file contains the assemblies and a manifest file with some meta information. Changing the extension to ZIP wil reveal te contents of the file. The same trick applies to DOCX and other office files, so you might call it Microsoft behavior.

My first step is to obtain the XAP file. The file must be send to the client to be executed, so check your browser cache. I opened the source view of the webpage hosting the XAP file and found the url. An example of what to look for is below

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
  <param name="source" value="ClientBin/portal.xap"/>
  <param name="background" value="white" />
  <param name="minRuntimeVersion" value="4.0.50401.0" />
  <param name="autoUpgrade" value="true" />

The contents of the XAP file showed me the use of

  • Telerik controls, used to make it pretty
  • MvvmLight, used for guidance of mvvm
  • Csla, used to standardize data access

Hmm, would the Csla WcfPortal be used? To find out I decompiled the assemblies using Reflector and found a class called DataPortalHelper with the following code:

public static string GetProxyUrl(StartupEventArgs e)
{
  // less important stuff removed ...
  return string.Format("{0}/Services/WcfPortal.svc", str2);
}

Looks like the WcfPortal is used. I need to investigate further. For now the question is: Standard components like Csla save time in development and maintenance, but you open up the books of what happens on the server. Can we live with that or is this too much of a security risk?

Posted in Security | Tagged , , , , , , , | 2 Comments

Fileless activation without svc extension (sort of)

Hosting WCF services in Windows Azure is easy:

  1. create service contract and implementation,
  2. add serviceactivation to web.config of the Role you’re hosting the service in.
...
  <system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" >
      <serviceActivations>
        <add relativeAddress="calculator.svc" 
             service="CalculatorServiceImplementation"/>
      </serviceActivations>
    </serviceHostingEnvironment>
  </system.serviceModel>
...

The serviceactivation needs a registered extension (svc) to be activated. When you want to do this without an extension use the IIS Url Rewrite extension and add the rewrite of the url without the .svc to the web.config. This extension is default available and activated in Windows Azure.

...
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <rewrite>
      <rules>
        <rule name="Calculator Rule" stopProcessing="true">
          <!-- Match Calculator on the end of the url -->
          <match url="Calculator" />
          <!-- Redirect to the .svc url where the service will be activated -->
          <action type="Rewrite" url="Calculator.svc" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
...

The .svc url is still available and is actually used to activate the service. But that is what the sort of in the title is for 😉

Posted in Development | Tagged , , , , , , , , | Leave a comment