I mentioned in my last blog that I would post an update once we were successfully able to work through the security issues reported last week. The most important update is Version 4.8.3 was released this past Tuesday and fully addresses each of the reported items. You can get it now from the Downloads page on our site.
I would like to mention that there was a huge amount of effort invested in analyzing the issues, constructing solutions, testing, packaging, and publishing this latest security release. In addition, there was a tremendous amount of communication in both private and public channels regarding the issues. I would like to take this opportunity to thank the Core Team and specifically, Cathal Connolly, for their dedication and professionalism in managing the many security inquiries.
Between my last blog and Joe Brinkman's recent security blog, a lot of information has been published regarding the security policy of the DotNetNuke project. It is important for the community to know that we take security very seriously. It is also important for the community to understand the process and expectations around how security incidents are managed.
One item which I do not think has been well documented previously, and may be of interest to the community, is the communication strategy we employ for security issues. I refer to this as our 'Isolation and Containment' strategy and I would like to share some additional information on this topic.
When it comes to security issues, it is important to recognize that in their early stages, a vulnerability is typically not common knowledge. Usually it is identified by a single party who then needs to make a decision on what they wish to do with their discovery. A period of time may elapse as they struggle with the ethical or moral dilemmas, but the critical item to remember at this stage is that an individual generally does not pose a huge security risk to the majority of users of an application. Even if the individual decides to use the exploit maliciously, the number of sites affected will start small and grow gradually. And usually those sites who are exploited first will immediately report the problem to the application provider.
Some people jump to the conclusion that the application provider should immediately alert all of their users so that they can patch their sites and prevent further exploits. The problem is, how can you only communicate this sensitive information to the correct parties? Almost any mode of communication has some level of leakage, which may actually provide more hackers with the details they need to perform the exploit. If this occurs, then the exploit can quickly become an epidemic.
Therefore, in general it is usually better for the application provider to focus on determining how to reliably reproduce the problem, performing a severity risk assessment, and working as quickly as possible towards a general solution. Once the general solution is available, then you can feel much safer sending out security notifications to your users.
In the recent security issues, it was the communication strategy oulined above which was not followed successfully. Unfortunately in these case, the individuals who identified the vulnerability decided to publish the information publicly, and as a result the isolation and containment was completely out of our control. This means that a lot more users were put at potential risk. We have taken steps to contact the individuals involved and educate them on professional security etiquette and we hope the same mistake will not occur in the future.
Based on the feedback over the past week, we also concluded that we should do a better job at communicating security details to our users. As a result we have decided to take the following actions:
1. We have created a http://security.dotnetnuke.com web alias which goes directly to the Security Policy page on our site.
2. We are going to enhance our Upgrade Service within the DotNetNuke application so that when the icon is displayed to signal the availability of a new version, it will be color coded according to the severity of any security issues which exist in the current version installed. We currently have three severity levels, so the color coding will be Red for Critical, Orange for Moderate, and Yellow for Low, and Green icon if no security issues exist for the version.
3. We are going to enhance the Solutions Explorer within the DotNetNuke application so that there is an additional Security tab. This tab will display a feed pulled directly from our published security bulletins.
We hope the improvements outlined above will provide higher quality, more timely, and more accurate, security notifications to our users in the future.
Digging into the specifics of the security issues in the 4.8.3 release, there are basically 2 different scenarios which we had to contend with.
Two of the vulnerabilities were reported by a hosting company. The reports ultimately were verified to be serious but it was the means by which the information was submitted to us which proved to be the bigger problem. The reports were only submitted after major public protesting was voiced by the community, and I made a personal phone call to engage them. The old adage that "Knowledge is Power" seemed to be pushed to the extreme in this particular case. Although these issues were categorized as Critical, the are actually no documented exploits which leverage these particular vulnerabilities.
The other two vulnerabilities were reported to us by a variety of community members. Most people simply recognized the fact that a text file ( ie. ISCN.txt ) had been uploaded to their site without authorization. Finding the actual attack vector ended up being much more complicated then we expected and it was ultimately Tomotoshi Sugishita from the Japanese DotNetNuke User Group who provided us with full exploit details. Once these were known, we were able to assess the severity level and it turned out that attackers could only upload to a specific group of folders, and could only upload files with 'safe' extensions ( based on the white list definition in Host Settings ). This realization downgraded the risk factor. Unfortunately, while we were constructing a solution, the hackers were busy publishing all of their exploits to the web. The exploit was classified as a 'defacement attack' however the defacement was only visible of a user knew the exact URL to the uploaded file. By publishing the URLs of their victims, the hackers could take credit for their defacement. With many documented exploits, this issue grew in stature, even though the actual risk was low.
After all the turmoil last week, I must admit I am happy to be making some forward progress once again. Thank you for you perseverence and patience through all of this.