.png?width=667&height=667&ext=.png)
Kentico CMS and the recent ASP.NET Security Issue
Over the last few days I have read about a security flaw that many sites and blogs are reporting, that Scott Guthrie originally posted. In fact I am quite surprised that it has gotten so much attention, usually these things go a bit un noticed.
That attention prompted me to check out the default Kentico installation and see what the settings are in the web.config file, to see if the default installation was at risk.
Sure enough the default installation looks like this (ASP.NET 4)
<error statusCode="404" redirect="~/CMSPages/handler404.aspx"/>
customErrors>
Now Scott Guthrie’s workaround mentions that the mode attribute of the customErrors node is important in the that fact that it handles how errors are shown.
On specifies that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.
Off specifies that custom errors are disabled. This allows display of detailed errors.
RemoteOnly specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.
As you can see above Kentico’s default setting is Off. As a result all details of errors are being served. Scott goes on to say that if this setting is On, it avoids an attacker being able to differentiate why an error occurred on the server, and prevents information disclosure.
So yes the vulnerability is technically there in a Kentico installation, however you don’t want to take his full advice and just redirect every single error and status code to the same page because this might cause problems with Extensionless URLs, URL Rewriting, and/or the Page Not Found capability that comes with Kentico CMS. So leave the error child node in there.
My suggestion is that until Microsoft releases a patch, which should come soon, add in the error codes explicitly under the customErrors node and handle them all.
<error statusCode="400" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="401" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="403" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="404" redirect="~/CMSPages/handler404.aspx"/>
<error statusCode="405" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="406" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="408" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="412" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="500" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="501" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="502" redirect="~/CMSMessages/error.aspx"/>
<error statusCode="503" redirect="~/CMSMessages/error.aspx"/>
customErrors>
Disclaimer: This is the first thing I could think of on a Sunday morning before coffee, so please make sure you test this out in your own instances before using it in production.
I’d be willing to bet that Microsoft fixes the situation pretty fast, so hopefully this is a very temporary workaround that is needed. As always please leave me your feedback in the comments.
Update: Martin Hejtmanek posted Kentico's official recommendation
