Critical Security Update - Please Read

Just scanned my sites and one was compromised on Sunday 5/22 from this vulnerability. I deleted the new superuser and am still trying to assess whether there was any further damage done.

Hi Will. A couple of questions:

1. I followed your link to the security center and found that there are a few more files that might be in the install folder that need to be removed: DotNetNuke.install.config, DotNetNuke.install.config.resources, InstallWizard.aspx.designer.cs, UpgradeWizard.aspx.designer.cs, Install.aspx.designer.cs. Can you confirm this?

2. You 4th item -- are you indicating that any file with an .aspx extension might be suspicious?

Hi Will. A couple of questions:

1. I followed your link to the security center and found that there are a few more files that might be in the install folder that need to be removed: DotNetNuke.install.config, DotNetNuke.install.config.resources, InstallWizard.aspx.designer.cs, UpgradeWizard.aspx.designer.cs, Install.aspx.designer.cs. Can you confirm this?

2. You 4th item -- are you indicating that any file with an .aspx extension might be suspicious?

Thanks for the update Will. On part 2 I notice that I have ascx. Should I just remove that also?
Also if we are on 8.0.3 we don't have to worried about the security issue anymore is how I read this.

Can someone help me understand why the Install and UpgradeWizard related files even remain after a successful install and/or upgrade? Was this considered after the last related critical issue?

If these files are such a source of potential exploits, why aren't they automagically deleted? When we upgrade DNN by overwriting the files, the upgrade archive contains the needed ones, making it unnecessary for the old ones to remain as a ticking time bomb.

I realize this is an exceptional issue, but for developers like me to wake up and realize that I need to go through dozens upon dozens of client sites (many which are not under maintenance) and delete files that are dormant at best and critical at worst is unnecessary.

Maybe this should be revisited before DNN v08.01.00 is released.

@Jim Yes, you can delete those files as well. The best thing to do is to search your file system for files with asp,aspx or php extension. I would then sort the results by date. Any that has a modified/created date within the past couple weeks should be inspected. In some cases, we are also seeing that Default.aspx is being modified. You don't want to delete that file, but you should inspect it for any embedded IFRAMES.

As a follow-up, I'd like to show my appreciation to the team for having the install and upgrade-related files removed on update. I hope this will continue to be the process in the future.

I am extremely appreciative of DNN's proactiveness and diligence in light of security issues. IMHO, other CMSs pale in comparison.

Could a feature be added to DNN's Security Analyzer for a white list and checksums of approved files (e.g. aspx) to compare against? Maybe the DNN manifest could also have entries added to this list helping to make security scanning easier.This way we might be able to zero in on changed scripts that can affect security or XSS vulnerabilities.

It could also be further enhanced to check for the app's ability to run ASP and PHP files, and alert to their presence and capability for launching.

@Chris, DNN depends heavily on ASCX. At this time, we have no evidence of the exploit altering .ASCX files. However, if you feel your site has been compromised you should look for any files that were added or deleted after the intrusion occurred or you should restore from a backup prior to the intrusion. If you restore from a backup, be sure to immediately perform the mitigation steps.

@Philip, That is a very reasonable question. The files were supposed to be deleted after upgrade and install starting with the 7.4.1 release, but we found that this was happening in certain environments. Additional code has been added to DNN Platform 8.0.3 and Evoq 8.4.2 to ensure the files are deleted. We have also added additional defense code to prevent this from happening again in the event that the files can't be deleted automatically.

@Will - if we delete install.aspx - then presumably the automated install url (http://www.mywebsite.com/install/install.aspx?mode=installresources) will no longer work.

Is install.aspx firmly implicated in this vulnerability or is deleting it just precautionary?

In looking at all of the available posts and security bulletins, and then from the feedback from my clients, it sounds like a previous policy may have been shut down. I don't recall seeing an announcement though.

Security updates have always been back-ported to the previous release series after a major release, for the next 12 months after a major release. In this case, security updates are not being back-ported from version 8.x to 7.4.x. Instead, people are being told that the only way to be secure is to upgrade to version 8.0.2.

Are there any plans to continue to back-port security updates, like the project has done since it was first released in 2002?

@Will Many users have told us that they don't want to go through the entire upgrade process for this fix. Especially since the fix is very straightforward using the mitigation steps we have provide. However, we are making updates to Security Analyzer module, which will be available to 7.x users. The Security Analyzer module will also properly delete the files upon install.

@Richard Removal of install.aspx is simply precautionary at the moment. We know some people that are renaming the file, and only make it available again if they need it.

-Will

Thank you so much for the pro-active communications and instructions. it's helped us and our customers a lot. Thumbs up 100x