webfolders.txt

`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:  
<html><head><title>vermeer RPC packet</title></head>  
<body>  
<p>method=server version:3.0.2.1706  
<p>server version=  
<ul>  
<li>major ver=3  
<li>minor ver=0  
<li>phase ver=2  
<li>ver incr=1706  
</ul>  
<p>source control=0  
</body>  
</html>  
  
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  
  
  
`