Tuesday, February 23, 2010

DotNetNuke Zero Day Vulnerability (semi-colon bug)

There is a major security loop hole in DotNetNuke versions 4.9.2 and below where DNN will allow an unauthorized user to upload almost any file onto the server. This loop hole combined with the IIS 5/6 zero day multiple extension exploit can allow a hacker complete access to your website.So if you are a DNN version that is not 4.9.4 and up – read on as this is huge hole in your website.
The DNN Issue:
If you browse to the following sub-folder on your DNN site “Providers/HtmlEditorProviders/Fck/fcklinkgallery.aspx”, you will see a page that looks like this:
The above page on its own is not too bad. But if you now paste the following javascript code into the address bar and hit enter: “javascript:__doPostBack('ctlURL$cmdUpload','')” you will see the following browse dialog which will allow you to upload almost any file onto the website (restricted to the list of files allowed by FCKEditor – typically images, documents, etc).
The above hack will typically lead to hackers dropping small txt files that have some kind of a notice saying that your website has been hacked!
It is hard to do anything substantial with this hack alone.
But wait there is more…..
The IIS Issue:
On December 25th of 2009, an “Ethical” hacker found a vulnerability in IIS 5 and IIS 6 called the “semi-colon” bug or the “multiple extensions IIS/ASP bug”. Read More.
The semi-colon bug allows any file that has .asp in the file name to execute as an ASP file. This bug occurs in all versions of IIS 6 and prior. This means that a file named “innocusFile.asp;.jpg” will be executed like an ASP file.
The big scary picture:
The 2 bugs on their own were bad, but it still would be hard for anything bad to happen. But together – they open up a can of worms that is going to make everyone in your organization pulling every fire alarm in the building. Here is the big picture:
1. Hacker fabricates an ASP file that uses COM objects such as the FileSystemObject to get complete access to your computer.
2. Hacker names the asp file as “myHack.asp;.jpg”.
3. Hacker navigates to the “Providers/HtmlEditorProviders/Fck/fcklinkgallery.aspx” file in his browser and uses the DNN loop hole to upload his myHack.asp;.jpg file. DNN complies because it thinks it is a simple jpg file. This is because DNN looks only at the last extension it finds in a file name.
4. The file uploads to the DNN website to the folder (WITHHELD – to protect unprotected DNN sites).
5. The hacker browses to the file that he uploaded. The file is delivered to the ASP processing engine by IIS and a page that opens up the entire computer to the hacker is displayed. This is because IIS has been coded such that it recognizes a file type based on its extension even if the extension is not the last part of the file name!!
6. The hacker uses his ASP page to get full control of your website (and I mean full control – all disk drives, connection strings, databases, registy, etc.). Nothing is safe after this.
Here is a sample ASP file called the “Smart Shell”, that basically shows the capabilities that an hacker can get over your website: (This kind of an ASP file is also called the 3fexe ASP hack).
How to mitigate:
Because there is no known fix, there are only ways to mitigate this attack (and hence it is a zero-day hack).
1. Rename the fcklinkgallery.aspx file
As fcklinkgallery.aspx is the entry point for this hack attack, the first thing to do is to rename this file. I suggest using a random file name – like a guid. After you rename the file, you will need to update the “LinksGalleryPath” setting in your config file. This will be found in the <dotnetnuke><htmlEditor><providers><add name="FckHtmlEditorProvider"> section. Just look for “LinksGalleryPath” and update the value to the newly named file name.
If the hacker cannot browse to the fcklinkgallery.aspx file, he will not be able to upload a ASP file onto your DNN site.
(Update: 03-30-2010) please note: Gabe has included an extra step that needs to be taken to get the link editor to work after renaming it. Please see the comments below. Basically you need to also rename the  "\Providers\HtmlEditorProviders\Fck\App_LocalResources\fcklinkgallery.aspx.resx" to match the renamed fckLinkGallery file.)

2. Remove Execute permission on the Portals folder of your DNN site.
The sub-folder “Portals” in your DNN site typically does not need to be able to run ASP files or any other files. So remove “Execute” permissions on that folder.
Open up IIS.
Expand the website node for your DNN site.
Select the Portals node in the explorer view on the left.
Right click on the Portals node and open the Properties dialog.
Chose the Directory Node.
Set Execute Permissions to “None”.

3. Remove access to FileSystemObject.
This falls into the excessively precautious as it is not really required for you to do. An important note: Do not do this if you know that you have some ASP apps on your site and if those ASP apps use FileSystemObject – you might end up hosing those apps.
There are 2 ways to do this: Remove access to this COM object from the security principal used to run your IIS website (typically ASPNET) or to completely unregister the dll.
1. Registry access:
Open registry editor.
Browse to “HKEY_CLASSES_ROOT\Scripting.FileSystemObject”, right click and under permissions deny access to the ASPNET user.
2. Completely disable FileSystemObject
Run regsvr32 scrrun.dll .u in the C:\windows\System32 folder.
Remember – step 3 is really not required to be done.

The only Fix:

The only “true” fix is to upgrade to IIS 7 or higher and a DNN version of 4.9.4 or higher.
Securing IIS 6.0:
One way hacking (which is what the above type of hack is known as):
Restricting information available to anonymous users:
DNN LinkGallery Remote File Upload without Extension:
DNN Failure to revalidate file and folder permissions correctly for uploads:
IIS Security Vulnerability and DNN


Unknown said...

One of our webservers was compromised using this very hack. Until we can upgrade both DNN and IIS, we decided to use the suggestions to mitigate the attack. Doing so, however, caused a little problem.

After following Step 1, renaming the fcklinkgallery.aspx file and updating the web.config, the text 'Use selected link' in the Link Gallery dialog was missing, rendering it pretty much useless.

As it turns out, the dialog gets its text from an .resx file that has the same base file name as the fcklinkgallery.aspx file. After renaming the base file, it couldn't locate the associated .resx file.

To fix the problem, we renamed ~\Providers\HtmlEditorProviders\Fck\App_LocalResources\fcklinkgallery.aspx.resx to match the new Link Gallery filename.

For example, if you rename fcklinkgallery.aspx file to fck1234.aspx, simply rename the fcklinkgallery.aspx.resx file to fck1234.aspx.resx. Voila! Fixed!

Thanks for the detailed post. It was immensely helpful. Hopefully someone will find this little addition helpful, too.


Ale said...

Question : Im running IIS7, but my dnn was older and a hacker uploaded a .asp;.jpg file. I tried to open the file and it opens a blank picture with that little red cross, it doesnt "run" the asp i think... is that the normal behavior in iis7?

Raj Rao said...

Ale: IIS 7 might be allowing the file to upload because it has a jpg extension. The real test it to try and browse to the file in a browser and see if it gets executed. From your comment - it looks like it is not - so you should be good.
Remember the issue is that DNN allows you to upload the file because it thinks its an image file, but IE5 and IE6 execute it because they think its an asp file. It looks as though IE7 has closed the loop hole by going off of the last extension in the file name.
Hope that helps.

Ale said...

Hello Raj, thanks for the quick answer.

Im not really concerned about the uploading, since this is the last dnn im using and soon i will stop using it.

I tried browsing the hackers file and it tries to open a image, since there is no image it opens a blank page with the little red cross image.

I then tried to open one asp file that is mine (i put the ;.jpg in the end and it oppened as a text...

Can you please check both files and tell me what you think ?

This is my file renamed :

and this is the hackers file :

Rick Hein said...

Just a quick note: This appears to work for my sites: Put this line in the Wildcard settings for IIS, under Home Directory, Configuration for the site in IIS.

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll, uncheck the make sure file exists check box.

This feeds EVERY request to the .NET framework dll, which will see a request for a .jpg file, and try and parse it approriately.

This results in a file not found (404) being returned to the user when they try to browse that file.