If you have installed Microsoft Office 2000 or keep current on your Windows Updates, you may have noticed a new WebFolders namespace in Windows Explorer. WebFolders are a new concept designed to give Microsoft Office and FrontPage users the ability to publish and work with web content. The concept is that a web site becomes a part of Windows Explorer so that you can work with web content as if it were located locally or on a network drive. The fun part is that WebFolders have some significant weaknesses (inherited from FrontPage) and are such a new concept that it turns out they make a great entry point into a remote server. In fact, when you connect to a web folder you are doing exactly the same thing that FrontPage does when it connects to a remote web site. This vulnerability is nothing new and I doubt there will be any patches forthcoming because it mainly exploits ignorance and smugness more than server applications. Okay, so this is really about FrontPage and for some of you this may just be a review. Nonetheless, I am surprised how few people seem to understand how FrontPage security works. USING WEBFOLDERS As I mentioned previously, WebFolders work the same as FrontPage when connecting to web sites. Essentially when you add a new WebFolder, Explorer will send a Post request to /_vti_bin/_vti_aut/author.dll (among others), which is installed as a part of the FrontPage Server extensions. So when you are using WebFolders, you are really just using the FrontPage Server extensions. If as an anonymous user you do not have read and execute access to that file, the server try to get an NTLM or Basic authentication from you. If any of those credentials succeed, you will now have a new WebFolder mapped to the remote server's web root. Even better, if you are able to get to this point, you should have at least authoring rights on the server, which means that you will be able to do just about anything you want on this web site. And when this is used in combination with other known exploits, one can easily achieve full admin access to a server. Before getting into the technical details, lets look at what this all means and some of the issues involved here: 1. Someone can remotely access at least a portion of your file system, including read, write, and execute permissions; 2. Since it all works on port 80, this exploit could easily work through many firewalls configurations and intrusion detection systems; 3. Since all file access is done through posts to author.dll, the specific files accessed will not show up in any logs and therefore you won't really know how much the attacker really did or what files he accessed (or installed); 4. The exploit can easily be performed through proxy servers to more easily disguise the originating IP address; 5. The login prompt is a good place to perform a brute-force attack (whether it shows up in the Event Log or triggers account lockouts, I have not yet tested). Another related fact is that in order to connect to a WebFolder, FrontPage requires that the author's account have the ability to log on locally. So if you do connect to a WebFolder you will be locally logged on to that server (something to think about); 6. The permissions you have as the web author will normally be greater than those given to IUSR_MACHINE; 7. Passwords are often stored in global.asa and other files which may be used to attack other servers; 8. Most people do not realize that they are vulnerable since a default FrontPage installation does not implement any security restrictions and many people do not understand how to setup FrontPage security. HOW IT ALL WORKS On Windows NT and IIS, FrontPage security is basically controlled by the access rights to the three files Admin.dll, Author.dll, and Shtml.dll. These rights respectively determine administration, authoring, and browsing rights. For example, if a remote user is able to read and execute Admin.dll, then that user is able to administer the web site. The authentication dll's are structured as follows: Web Root \_vti_bin shtml.dll \_vti_aut author.dll \_vti_adm admin.dll When the post to author.dll succeeds, the client will then be able to browse the web site as if it were browsing the file system. And since an author has full authoring capabilities, he can also do things such as place executable files in the _vti_bin directory or other executable directories. Having user read, write, and execute access is just one step away from having full admin access. Properly called the FrontPage Remote Procedure Call Protocol, the exact procedure for connecting is as follows: First, Explorer sends the remote server an OPTIONS / HTTP/1.1 (I suppose to figure out if it can post). At this point it is sending a User-Agent of "Microsoft Data Access Internet Publishing Provider Cache Manager", although in later requests it sends a User-Agent of "MSFrontPage/4.0." So far I have seen few servers that dissallow the POST method so this usually succeeds (which makes me wonder why they even do it). Then it sends GET /_vti_inf.html HTTP/1.1. This is the basic configuration file for the FrontPage extensions. This tells Explorer that the FrontPage server extensions are installed and it looks for the line FPAuthorScriptUrl="_vti_bin/_vti_aut/author.dll". On IIS it will be author.dll and on all others it will be author.exe. Of course, if the file isn't there, we get a 404 and we know this server doesn't have FrontPage support. After it knows the location of the authoring binaries, it sends POST /_vti_bin/shtml.dll/_vti_rpc HTTP/1.1. Shtml.dll is the browse binary and is available to everyone. The post data is: method=server+version%3a4%2e0%2e2%2e2611, to which the server responds something like this: vermeer RPC packet

method=server version:

server version=

source control=0 Now Explorer knows the version (although it could have extracted this from the _vti_inf.html file) and can start its work. It sends a POST to /_vti_bin/_vti_aut/author.dll, which is the authoring binary. The post data is method=open+service%3a3%2e0%2e2%2e1706&service%5fname=%2f (notice how it now uses the server's version). This is where the authentication comes in. If the ACL of author.dll permits this request, the server responds with a bunch of settings, which is basically the /_vti_pvt/services.cnf file. There is nothing very interesting here, although some of the information could be used along with other exploits. The good part comes in this next request: POST /_vti_bin/_vti_aut/author.dll HTTP/1.1 MIME-Version: 1.0 User-Agent: MSFrontPage/4.0 Accept: auth/sicily Content-Length: 241 Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive method=list+documents%3a3%2e0%2e2%2e1706&service%5fname=&listHiddenDocs=false&li stExplorerDocs=false&listRecurse=false&listFiles=true&listFolders=true&listLinkI nfo=false&listIncludeParent=true&listDerivedT=false&listBorders=false&initialUrl = This is where we get the good stuff. Of course as you can see, Explorer is being pretty nice (notice also the version number in the request). What we really want to do is change some of those settings like listHiddenDocs=True and listExplorerDocs=True and listLinkInfo=True and listIncludeParent=true. And of course, to browse other directories, you change the initialURL value (i.e., initialUrl=cgi%2dbin). To retreive a file, you send this as the POST data: method=get+document%3a3%2e0%2e2%2e1105&service%5fname=&document%5fname=about%2fd efault%2ehtm&old%5ftheme%5fhtml=false&force=true&get%5foption=none&doc%5fversion = In all I have found many commands you can send. I haven't tested them nor do I know their exact parameters and I'm not sure if they can all be used remotely, but there is certainly much room for exploring. And some commands are limited to admins while others are available to authors as well. In fact, some commands are available to everyone. Thats how FrontPage is able to list subwebs of a site without logging in. FRONT PAGE SECURITY Unfortunately, when you install the FrontPage server extensions, there are no security limitations implemented. And it is very easy to get confused because the whole thing is based on the ACLs of a few files. It would be very easy even for even an experienced admin to overlook FrontPage security. Imagine this scenario: A company is using FrontPage to author their public web site. Their web server is considered very secure and the administrator has taken many steps to keep hackers out. The network firewall restrictions are very tight, so that web and FTP access is all that anyone gets. The administrator knows that the FrontPage server extensions aren't as strong as they should be so he has the web developer author the web site on his own Windows 98 computer then use FTP to upload to the server. The web developer has installed the personal web server that comes with FrontPage so that he has his own local copy of the web that he uses for development. His computer is on the internal network and is not exposed to the internet. In fact, it is nowhere near the internet since it is in his office which is across the building from the server. Then along comes a hacker that is trying to break in to their web site. He sees that main web server is very secure so he does a zone transfer for that company and finds they own a whole class c network. He scans the internal network but his pings fail and it appears that a firewall is in place. He then scans their network for port 80 and sees that it isn't being filtered. In fact, he has located several ports open, one on a seemingly insignificant box. He types that address into his browser and finds that it seems to be a mirror of their main site. But then he tries to create a WebFolder with that address and it immediately connects without even prompting for a password. He starts his work, grabbing global.asa to get their SQL Server password, installing a few trojan ASP pages, one which allows querying the SQL Server database and then the usual cmd.exe, nc.exe, getadmin.exe, and/or perl.exe executables. About an hour later he has everything he wants (whatever that may be) as well as a few extras, such as this company's login to the Microsoft's Solution Partner area and some porn he found in the developer's internet cache. When he's done, he deletes his files and doesn't even bother with logs since it's not even logging (why should it, its just a development system?). He does leave in one inconspicious trojan ASP page hoping that it will eventually make its way to the main web server then he closes the WebFolder and he's done. Sure, some of you may say that this vulnerability is dependent upon some misconfigurations and oversights but unfortunately (or fortunately, depending on who you are) these misconfigurations and oversights are way too common. If FrontPage doesn't prompt you for a password when you open your site, it won't be prompting anyone else either. And what if someone just installed FrontPage to check it out but never used it? This site will still be vulnerable even though they may have never created a FrontPage web. Or what if the web author gets sick of entering a password each time he connects so just sets his password blank? The sad fact is that as long as there are passwords, there will always be bad passwords. How secure is that copy of FrontPage you run on your own system? Have you checked? To test a site, you can either open it in FrontPage, add it as a WebFolder, or here's another way: Create a file named listdocuments that contains the following (you will want to change the host): POST /_vti_bin/_vti_aut/author.dll HTTP/1.1 MIME-Version: 1.0 Accept: auth/sicily Content-Length: 219 Host: www.yourhosthere.com Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive method=list+documents%3a3%2e0%2e2%2e1706&service%5fname=&listHiddenDocs=true&lis tExplorerDocs=true&listRecurse=false&listFiles=true&listFolders=true&listLinkInf o=false&listIncludeParent=true&listDerived=false&listBorders=false Then using NetCat, do something like this: nc -v www.targethost.com 80 < listdocuments Another interesting point is that since FrontPage security is based on ACLs those three FrontPage dll files, a file system such as FAT that doesn't have ACLs will be completely open to WebFolder connections no matter what you do. Another thing I would like to point out is that since WebFolders and FrontPage connect to sites the same way, you could also use the FrontPage Explorer to connect to a site. The benefit of using the FrontPage Explorer is that you can also change permissions on files and view hidden directories and files. Another interesting point is that ADO 2.5 provides OLE DB access to web folders so it would be very easy to write a script or application that will scan networks for vulnerable servers. And of course you could also use any Office 2000 application and VBA to connect to remote servers. Finally, interactive and network accounts can list the directories (rx) of the web root. This is so that the FrontPage Explorer can list the sub webs. If you use FrontPage Explorer to connect to a web site, you will be given a list of sub webs to connect to as well. This can be done by anyone without any authentication Given some thought, one could take these concepts a lot farther. Here are some other concepts to ponder: 1. Administrators are always given full admin access to FrontPage webs so that may be a good user to use in a brute-force attack; 2. FrontPage has executable access to many system dll's including msvcrt40.dll, netapi32.dll, rpcltcl.dll, samlib.dll, and wsock32.dll; 3. If IIS is set to run dll's in-process, then one could replace the FrontPage dll's with a trojan. These dll's do not even have to be in the same location, just named the same; 4. A user's local login and password may be sent to the server using basic authentication without the user knowing it The FrontPage is a wonderful world full of unexplored exploits and vulnerabilities. Its a shame more time hasn't been spent exploring this more. It also goes to show that the more we try to close doors, the more software vendors open up new ones. Forget BO2k and NetBus, Microsoft did a much better job. .sozni