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