From: Sozni [sozni@usa.net]
Sent: Thursday, October 21, 1999 8:09 PM
To: ntsecurity@iss.net
Subject: [NTSEC] WebFolders


TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
Contact ntsecurity-owner@iss.net for help with any problems!
---------------------------------------------------------------------------

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.

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, 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 will then silently request your current local user login and password. 
If that fails, Explorer will prompt you for a login and password to connect
with.  However, 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 will 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.

Unfortunately, when you install the FrontPage server extensions, there are no
security limitations implemented.  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?

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

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
