Understand Your Server Security: Microsoft IIS ASP Multiple Extensions Security Bypass

Media: View the Video | Download the Samples

When you are done, check out the next post which provides a more universal solution regardless of where your site is hosted. Part 2 - A Real Solution for Microsoft IIS ASP Multiple Extensions Security Bypass

The purpose of this Video is to provide a bit more exposure and coverage of a severe and *long term* flaw which has existed within the Microsoft based web hosting service - IIS for a very long time, which only recently has been uncovered.

Known in small circles with no apparent broad public announcement as the the cryptic "Microsoft IIS ASP Multiple Extensions Security Bypass", this flaw allows any user who has the ability to upload a file to your server, the ability to attack that server, or in worse cases, make that server a drone in a very short length of time.

This video is meant to act as an understanding of the flaw, and most importantly demonstrate how to correct the issue. While the fix is simple to conduct, you must considera few specific topics which could cause residual issues in the future. The video will also demonstrate a possible residual issue and give you a bit more understanding of what to look for if you have been compromised.

First and foremost, let's take a look at the scenario. In this case, our website, running on Microsoft Windows Server 2003 R2 SP2, with IIS 6, provides a public wiki, allowing any registered user to provide content and updates.

In this case you see an ordinary File Input element on the site, not so ominous - right? The developers have been careful in this case to not allow a user to upload malicious extensions, settling on allowing only known images and text file extensions. As seen in this demonstration.

So, it won't let me upload the "Flawed.asp" file, because quite frankly that would be really bad as it is a known Script file extension!

But what happens if the file extension is the correct type?

Let's rename this first file, "Flawed.asp" to "Flawed.asp;image.jpg". As seen here I have appended a graphic filename preceeded by a semicolon to the original asp extension. Hence the "Multiple Extensions Security Bypass" label.

Now when I upload, you can see that the server allows me to perform the upload with ease!

Okay great, so I uploaded an Image, no harm no foul - afterall, Windows 7 detects the correct Icon and File type based on the name I just gave it locally right? Wrong - while my local environment is show it properly, the Windows Server reads the first half of the filename, the one ending with .asp and executes the Active Server Pages handler for the extension. If I hit the link, you can see that the file is executed!

Uh, oh. Now what? Well, consider the following demonstration files in sequencial order.

1. Obtain the security credentials to access the database. This can be done by reading the contents of the web.config file. Sample file: MyWebConfig.asp
2. With the retreived credentials, access the database. In this case I select the userid and username for the top 50 users in my site.

With the knowledge to conduct queries in the database, I could easily provide myself a textbox to now just ream the server with query after query, obtaining any peice of information I desire.

Now, as I mentioned there is a quick and simple way to plug the hole, taking only a few seconds. But, as I mentioned there may be some residual issues. This is demonstrated by the third example: Trojan.asp. If I stop the server from executing ASP pages, what stops me from creating my own ASPX page long before the hole is plugged? Trojan.asp generates a root file named "Verify.aspx", which when executed as seen here, allows me to pass a username via the url into the page. Knowing how the target server processes the Authentication logic, I am able to authenticate the user with full Super User permissions. Now, after the hole is plugged, I can still return to the site at any time.

Fixing the hole, as mentioned is simple, and can be performed in two ways:

1. Prohibiting ASP pages from executing globally across the server. To do this just navigate to the Web Server and click the "Web Service Extensions" folder. Then, after selecting Active Server Pages, click Prohibit. This stops the problem from happening entirely.
   
   
   
   
2. If you must allow Legacy ASP code (even though I would love to talk you into abandoning it entirely), you can disable script execution at a folder level on each folder which will allow user uploads. Do this by navigating to the folder in IIS. Right Clicking the file to get to the Properties, and then setting Execute Permissions to None.
   
   

Before you run around screaming that the sky is falling, use the provided tools to see if your server is allowing the ASP pages to execute. I recommend testing first by just copying the files into the server and hitting them. Because, while you may think you know every place file uploads are allowed on your front ends, you may be mistaken or you may have had a problem in a previous version of your site which did allow the ASP pages to be uploaded in this fashion. Knowledge is power, and this specific knowledge is far more powerful in your hands than in the hands of someone who might want to do you harm.