asp.net padding oracle: impact on asp.net MVC and PHP

2 days ago, I wrote about how the padding oracle vulnerability related to getting various levels of access in ASP.NET.

Let’s see how all the items I mentioned on my earlier post relate to ASP.NET MVC (and some news):

• View State: We don’t use it
• Session cookies: Unrelated to the attack
• Authentication cookies: These are signed, so you have to actually get the keys to be able to get around it. Additionally, by using the Microsoft workaround, we make sure we don’t expose information on the decryption with it
• Custom encryption using the machine key. This is susceptible, make sure that if you are receiving anything unexpected out of the Decrypt call you throw an error / just like if it the Decrypt call had failed. That along with the Microsoft workaround will prevent decryption information being exposed. See Understanding Padding Oracle Attacks for more information on why that matters. For best results, consider if you can avoid sending it to the client altogether, or sign/validate the data
• WebResource.axd and ScriptResource.axd: These built-in are a huge problem in this vulnerability, but as we don’t use them, we disable them (see the side note below)
• HtmlHelper.AntiForgeryToken: uses the machinekey to encrypt the cookie but uses it with mac to make sure it hasn’t been modified. Not a problem if you use the Microsoft workaround / don’t disclose details on the error.
• I might be missing some, so pay attention to any other feature that uses encryption/decryption.

Additionally, use security best practices all around, don’t send sensitive data to the client, don’t assume anything you sent to the browser hasn’t been tampered, keep your connection strings safe, have a firewall that further prevents external access, act as if the web.config could be read from outside (protected sections or any other measure).

Beyond the ASP.NET features: You don’t need to be using anything at all of the ASP.NET platform, to be vulnerable in an IIS install that has ASP.NET enabled. If the framework is 3.5 SP1 or above, this means access to any special file in the site’s folder (including your aspx/php files, config files, embedded data files). Here is a blog post more specific to PHP in IIS: ASP.NET vulnerability affecting PHP sites on IIS.

ASP.NET MVC is impacted by the above as well. The access to any file issue, is caused by the built-in handlers I mentioned above: WebResource.axd and ScriptResource.axd. Exactly which handler config you need to disable depends on the IIS version / mode (classic vs. integrated) and the version, I don’t have a compiled list, but you can find the list of handlers added in the machine web.config (.NET Framework in the Windows folder) for the classic mode or the IIS applicationHost.config for integrated mode. It’s a good exercise to take a look at those anyway.

Removing the handlers means the attacker can no longer get to the special files (including web.config) in your site. That said, you still want to prevent the attacker from gaining ground into your site’s encryption/decryption protections related to the machine key. So, regardless of what we discussed above, go and apply the Microsoft workaround.