What does the Asp.Net security vulnerability mean for Web Services and Wcf?

@YaronNaveh

The "padding oracle" Asp.Net vulnerability will surely affect many production web sites. Does this have any effect on web services and Wcf?

To put this in concrete terms, can a web service become a "padding oracle"?

Without getting too much into details, I believe it is possible in some situations. The best way to protect against this is to ensure all your messages are digitally signed. With Wcf this behavior is actually built in to the framework and you cannot send messages which are encrypted but not signed. With older frameworks such as Wse, and some non-MS soap stacks, this is possible, so you might want to check any relevant production application.


Regardless of this it is always a best practice to sanitize customer facing error messages.

I have actually did a little test. I have configured a Wcf service to emit debug information in error responses (this is the most verbose response Wcf is capable of). I have then created a valid encrypted request, manually altered the encryption to make it not valid, sent it to the server and got this soap fault:

An error occurred when verifying security for the message.

No secret data is enclosed here. I have then changed my server implementation to throw a logical exception:

public string GetData(int value)
{
    throw new Exception("Data is not available");
}

I initiated a legal request and this time got this response:

<Message>Data is not available</Message>
<StackTrace>
at Service.GetData(Int32 value) in C:\Users\naveh\Documents\Visual Studio 2008\Projects\WCF Self Hosted Service37\WCF Self Hosted Service37\Service.cs:line 23
at SyncInvokeGetData(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
</StackTrace>

So Wcf did return a full stack trace with an application exception. This means that Wcf shields us from verbose errors when security exceptions are thrown.


So are we safe?
You never are. For this reason take these precautions when using Wcf:

Disable debugging information in responses
Even though we saw Wcf tries not to disclose security information you should still protect from such information leaking into application level exceptions (or Wcf bugs). Just make sure your service has this behavior:

 <behaviors>
        <serviceBehaviors>
          <behavior name="ServiceBehavior">
               <serviceDebug includeExceptionDetailInFaults="false" />
          </behavior>
        </serviceBehaviors>
      </behaviors>

Protect your trace files at all cost
They may contain the detailed exceptions hackers look for.

What about Asp.Net web services?
Asp.Net web services (asmx) are inherently insecure (WRT message level) unless Wse is used with them. You should apply the same technique and sanitize your Wse error messages as explained in this walkthrough.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Asp.Net critical security vulnerability

@YaronNaveh

Edit: Some information in the original version of this post was not correct. I have fixed it.

A few hours ago Microsoft had publicly disclosed a critical Asp.Net security vulnerability. In short, a hacker can get sensitive data from an Asp.Net application in a few minutes. This information includes any file on the server (e.g. web.config) and any viewstate data even if it is encrypted. To block this attack, site owners should immediately direct all errors to a single page (custom errors redirect).

If you have a production Asp.Net system read this now and go fix it.

How does the vulnerability work?

Without making this a walkthrough to my hacker readers, this is the general flow:

Some common encryption algorithms (among them TripleDes and AES) divide the encrypted data to blocks of equal size, where the last block is padded with additional data to make all blocks equal. A few years ago a security researcher had published an article explaining how to hack such an algorithm provided that a "padding oracle" exists. What is a padding oracle? It is an application (or some abstract... oracle) which tels us if the padding of an encrypted data is in the correct format.

Well, it turns out that Asp.Net uses TripleDes, and that some specific feature of Asp.Net turns it into a "padding oracle", you get the idea...


How to avoid this?

1. The single most important rule is this:

When there is an error in your application, never let the end user know what it was. In particular never allow an end user to distinguish between 404 and 500 status codes.


The way to do it is to redirect all errors to one page.
ScottGu's post explains how to do it.

2. The hacker that found this hole wrote his in this twitter account:

error message setting is irrelevant. no error? there's always HTTP status. always the same HTTP status? there's always big timing different

He means that even though we hide from him the real Http status (by redirecting to a single error page) the real status still "leaks" by computing the response time.

This means that adding a random wait before sending the error page can help us. ScottGu's post has the details too.


If you are really interested in the bits & bytes (&blocks) of this kind of attacks this is a nice introduction.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!