How ASP.NET Security Vulnerability affects Kentico CMS

Hi there,

As you probably already know, there is a very serious bug in ASP.NET security that allows the attacker to get sensitive information from ASP.NET web site. You can find more details about it here:

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

and here are the FAQs:

http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

I didn't want to just mirror the same information that is already all around the internet so before I wrote this post, I spent the whole last day in checking the details of this issue, how it really works and what could be potential options to prevent that but keep your web site functionality intact. From the posts above, you see that the recommended solution is not exactly most friendly one in all cases. But I can definitely confirm that it works os it may be at least temporary solution. 

What is important is that this is in the core of the .NET, and heavily used feature (basically even standard WebForms model and AJAX are built on it), so everything out there is potentially affected by this, no matter if you use Kentico CMS, Sharepoint or CMSxyz built on ASP.NET.

What exactly is the security issue?

I do not want to judge any programmer that is responsible for this but the fact is that the creators of ASP.NET Framework let the door for the attackers half open.

What ASP.NET Framework provides is a handler WebResource.axd (or ScriptResource.axd, doesn't really matter), that provides a way how to retrieve physical files of any kind from your web file system. You can see how this is supported if you add something like this on your page:

<asp:ScriptManager runat="server" ID="manScr">
  <CompositeScript>
    <Scripts>
      <asp:ScriptReference Path="~/web.config" />
    </Scripts>
  </CompositeScript>
</asp:ScriptManager>

I intentionally used path to web.config, because that is exactly where reported the problem lies. If you look at the output of the page, it renders something like this:

<script src="/ScriptResource.axd?d=EfRKJEgW1Tec-zA1PuIaXerT9kpl0_QJyr7R4g6yvb-DNebY3LZEthKYxoQwNMMW0" type="text/javascript"></script>

And if you query the URL, you simply get the web.config code. This is how the attacker is able to get your sensitive data which doesn't have to be only the machineKey, but can be also your connection string to database or anything else for that matter.

As you surely guessed right, the "d" parameter contains the locator of the resource, somehow encrypted. So far, it seems fine until somebody is able to guess or encode the resource identificator. Once he can get the correct one or the encryption key, he can access anything and simply generate those keys.

This solution of theirs basically has only single point of breach which is the encrypted resource key itself. If there would be additional precaution, like allowing only certain types of files to be retrieved, the security issue wouldn't be that bad for everyone, but it unfortunately is.

How the attacker gets the key?

Although breaking the cipher via brute force may seem hard enough, there are ways how to get there quite easily, if the solution isn't robust enough to eliminate just every possibility.

What is typically used to break the ciphers is something called Side channel. Side channel is an information of any type that can leak out from the process and tell the attacker how his particular attack proceeded. Side channel can be really anything and it isn't anyhow based only on software implementation, it can be also part of the hardware. For example, if you try to hack the ATM with electronic device connected to your laptop simulating the credit card, even the time in which the particular request is processed (e.g. longer if succeeds, shorter in case of error, or specific number of cycles executed) can tell the attacker how successful he was until he breaks the cipher going the right way. The creators of sich devices fight against this by incorporating random waits or ensuring that any operation takes same amount of time using delayers. These side channel clues serve the attacker as some sort of oracle to reduce the number of options. Same thing with the software implementations. Any information that can leak out from any security process significantly reduces the number of options. If you want to know more about side channels, try to start here:

http://en.wikipedia.org/wiki/Side_channel_attack

In this particular case of ASP.NET vulnerability, the Side channel clearly is the difference between "Page not found" and "Cryptographic exception". You can get the first one if you link to the non-existing file, and the second one if you attempt to change the URL to the resource.

Very bad thing about AES algorithm that is used by these resources is that it already has known side channels specific to padding of the encrypted data so it is not that hard to break it as you can see here:

http://www.youtube.com/watch?v=yghiC_U2RaM&hd=1

This is exactly what an attacker can do.

One other issue of this is that the length of the encrypted resource key is depending on the length of the data value which means the attacker can use much shorter data to attack and further reduce the number of options. That is another side channel in this particular case.

So what the attacker does is he attempts to partial-guess (using the oracle) the machine key used for encryption of particular key, either one that he chooses or some default one (WebForms link script WebForms.js which has known format of decrypted data and is used on almost any web site implemented through ASP.NET). He basically requests the files until he gets 404 which means the cryptography part has succeded. Once he gets the machine key, he can generate any resource key he wishes. Specifically with the web.config, the decrypted key looks like:

Q|~/web.config|#|298f20c0

Not exactly sure what is the second part (timestamp or hash maybe) but clearly the first part locates the resource. So the attacker generates the URL using this resource locator, and requests the resource. Now he gets the web.config file with all the sensitive information or any other file your web site can access the same way.

How to prevent that?

Now you know how it works on the attacker side which is important so you can understand why the recommended solutions are the way they are. What we need to do is basically to close the side channel which in this case is the error reporting. That is why the official recommendation is to basically provide single error for any case. They suggest following settings:

<configuration>
  <system.web>
    <customErrors mode="On" defaultRedirect="~/CMSMessages/error.aspx" />
  </system.web>
</configuration> 

Note that do not even want to make a difference between Not found and other errors, since it would provide the same side channel.

While this seems OK, it may be a two-bladed sword. If you enable this on the whole web site, you may get some unwanted behavior because from that point on, all errors will be reported as the same giving the site visitor some false information (unless you can somehow cover all situations in your error file).

I understand why they are suggesting this, they want to prevent all potential bugs caused by the same thing in other locations.

So far, it seems to me like restricting the errors only for the particular files is also OK, because the errors we want to prevent come from these files only:

<location path="WebResource.axd">
  <system.web>
    <customErrors defaultRedirect="~/CMSMessages/error.aspx" mode="On" />
  </system.web>
</location>
<location path="ScriptResource.axd">
  <system.web>
    <customErrors defaultRedirect="~/CMSMessages/error.aspx" mode="On" />
  </system.web>
</location>

So adding this to your web.config should keep all your standard pages intact, while the side channel on those particular files is closed.

Other precautions

While all this may seem to be enough to do and you may think that you are safe, I am a little paranoic when it comes to security so I believe in quite opposite scenario. Hacking is a good businness nowadays and the hackers won't let such opportunity to slip between their fingers. You have implemented a precaution that itself is just a workaround and does not ensure you that it covers all potential side channels. Not only that, your web site could have been already compromised without you knowing that.

So definitely do not end here, but continue (in fact that is what you should always do, not only in this case):

• Backup your site more often until the patch for this from Microsoft is ready.
• When the patch is available, immediately apply it.
• Implement the recommended workaround. If it doesn't break your web site functionality, use it on the whole web site. If it does, at least use the option with locations.
• Check out all the news about this issue in case someone would find some other way that the workaround doesn't cover. You should do the same even after the patch is out just in case they didn't fix everything.
• Check your security settings on all servers, if possible allow only the web server IP to access the SQL server.
• If you have such option, use some flood control, as you could see on the video, it still requires a lot of requests in a short time, so if you prevent it in some way, you will have enough time to fight against it.
• Check out your event logs on a regular basis and search for any too frequent error patterns.
• If you have any suspicion that your web site could have been already compromised, require from all users that they change their passwords, change the machineKey and other passwords to other servers.
• With Kentico CMS, you may at least temporarily disable the admin UI if you know you won't need it with following web.config key: <add key="CMSDisableAdministrationInterface" value="true" />

The patch they are preparing will probably use one of these approaches:

• Limiting the files you can retrieve to just specific types (which may make some existing applications not work properly if they will use some "special" files, not Kentico case which is good).
• Implementing other algorithm for encrypting the resource keys (which will be supported anywhere but will probably need some configuration change).

One way or another, you need to be careful no matter if you use Kentico CMS or any other ASP.NET application at least until the patch is out and applied and few weeks after that.

Unfortunately, we cannot fix this since it lies in the core of ASP.NET so you need to go with the workaround at this point which may and may not be good enough. What may be calming for some of you is that there are currently thousands of buggy web sites out there more important for the hackers than yours, but you definitely shouldn't count with it as a sure thing, especially if you have some enemies behind you.

In case you know any update on this or can add some more imporant information, feel free to post it into the comments. Thank you!

See you later ... hopefully with some nicer topic