Earlier this week, news surfaced about a possible security vulnerability in the default encryption mechanism used to protect the cookies normally used to implement Forms Authentication in Microsoft ASP.NET.
A couple of security ‘researchers’, Thai Duong and Juliano Rizzo, publicly claimed that their attack could ‘compromise’ millions of applications that are built on the ASP.NET platform. One of them even did a Twitter post asking for which ASP.NET application should be used as a demonstration, and given our reputation as the most widely deployed web application for ASP.NET, DotNetNuke was chosen as the "lucky" target.
Utilizing the extremely limited information which was provided, the DotNetNuke Security Team led by Cathal Connolly and Brandon Haynes immediately set to work trying to pinpoint the attack vector and determine the magnitude and severity of the vulnerability. Unfortunately, the lack of technical details and tools made it impossible to reproduce the issue. Initially we even suspected that DotNetNuke may be immune because of our default configuration settings; however this later proved to be incorrect ( Cathal managed to get in touch with the ‘researchers’ directly and they confirmed DotNetNuke was vulnerable but were unwilling to share details ). Regardless by mid-day Friday, Brandon and Cathal had come up with a few potential solutions which they felt would theoretically mitigate the ASP.NET forms authentication vulnerability. But rather than rush out a solution to a problem which was not yet fully defined, we decided it would be wise to wait for more details to emerge. On Friday afternoon we were contacted by a program manager from Microsoft Vulnerability Research (MSVR) who provided us with a few more details and assured us that Microsoft was taking the issue very seriously and would keep us in the loop.
Late Friday afternoon, in a security conference in Buenos Aires, Argentina, the security ‘researchers’ demonstrated how to exploit the vulnerability, using DotNetNuke as the target application. They created a YouTube video of the steps involved, and even threw 3 pen drives containing the tools to accomplish this exploit into the crowd.
We take the privacy of our users very seriously, and based on the potential threat that this vulnerability demonstrated to our community, we decided to take immediate and extreme action. We took our main websites offline, including www.dotnetnuke.com. Such drastic action obviously has an effect on our business, but we thought it was the safest approach as we needed some time to fully assess the severity of the situation. We did not expect that the sites would need to be down for an extended period, as we had faith that Microsoft would move quickly to issue a workaround.
The actual exploit utilized a few techniques which nobody had previously anticipated. But once the details were out in the open, it was then possible to come up with an effective mitigation strategy. Microsoft moved quickly to make information available to the community - in fact many of the principals in the Web Platform & Tools team, including Scott Guthrie himself, were up almost all night providing feedback and working in real-time to provide utilities to expedite the patching of affected systems ( I know this because I am on the ASPInsiders mailing list and there was plenty of activity from 1AM - 5AM PST this morning ).
The official advisory can be viewed at:
And a more understandable version written by Scott Guthrie can be viewed at:
Cathal has posted a detailed blog on how to apply a workaround to ensure your DotNetNuke web sites are protected immediately.
We have already followed these workaround steps for our own web properties and brought them back on-line early Saturday morning. We encourage other folks to do the same ( Microsoft will likely push out a server level patch at some point in the future through Windows Update but the exact timing is still not known ).
We will also be expediting the release of a 5.5.1 version this week which will include the patch as well as a seamless upgrade mechanism to ensure your web assets are protected. We will also create a utility which would enable people to apply the patch on legacy versions without requiring an upgrade to the latest DotNetNuke product - however this should utilized with caution as the only way to be assured of the integrity of your site is to keep up with all security patches.If you do not feel comfortable making technical changes such as this to your sites, there is also the ability to opt for a commercial edition of DotNetNuke , where our expert support technicians can provide direct assistance.
We appreciate your patience and will keep you informed as further information becomes available.