what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Oct 26, 1999
Authored by Sozni

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. 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.

tags | exploit, remote
systems | windows
SHA-256 | 01adda0b5af462be99d4d8071315e8516891937780a27b461c6b4e7ab4d80727


Change Mirror Download
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.


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
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.


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

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>
<p>method=server version:
<p>server version=
<li>major ver=3
<li>minor ver=0
<li>phase ver=2
<li>ver incr=1706
<p>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


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.,

To retreive a file, you send this as the POST data:

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.


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

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


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


Login or Register to add favorites

File Archive:

September 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    23 Files
  • 2
    Sep 2nd
    12 Files
  • 3
    Sep 3rd
    0 Files
  • 4
    Sep 4th
    0 Files
  • 5
    Sep 5th
    10 Files
  • 6
    Sep 6th
    8 Files
  • 7
    Sep 7th
    30 Files
  • 8
    Sep 8th
    14 Files
  • 9
    Sep 9th
    26 Files
  • 10
    Sep 10th
    0 Files
  • 11
    Sep 11th
    0 Files
  • 12
    Sep 12th
    5 Files
  • 13
    Sep 13th
    28 Files
  • 14
    Sep 14th
    15 Files
  • 15
    Sep 15th
    17 Files
  • 16
    Sep 16th
    9 Files
  • 17
    Sep 17th
    0 Files
  • 18
    Sep 18th
    0 Files
  • 19
    Sep 19th
    12 Files
  • 20
    Sep 20th
    15 Files
  • 21
    Sep 21st
    20 Files
  • 22
    Sep 22nd
    13 Files
  • 23
    Sep 23rd
    12 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    0 Files
  • 26
    Sep 26th
    30 Files
  • 27
    Sep 27th
    27 Files
  • 28
    Sep 28th
    8 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By