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