Sharing Too Much
The Dangers of Hosting on Windows NT
By Chuck Newman
I often maintain my Web sites by accessing an ASP script that lets me work remotely with files. I call the script my Windows Based Web Explorer (WBWE). With WBWE, I don't need to use telnet; I can just log in from any computer with a Web browser, and start modifying files on the Web server. The interface for WBWE is shown in
Figure 1. The GUI is similar to that of my local copy of Windows Explorer except, like I said, I'm using a Web browser and the application resides on the same server as the files I want to access.
At the heart of my application is the File System Object (FSO). This object performs a number of tasks in ASP scripts, such as listing, reading, and writing files on the server's hard drives. Albeit useful, FSO can leave your site and its databases wide open to hackers if misconfigured.
FSO is one of a group of objects in the Scripting Type library, Scrrun.dll, that is included with the Microsoft Windows NT 4.0 Option Pack and IIS 4. Many hosting companies, including the one I was using on the day I gained access to an entire hard drive's worth of Web sites, use such a setup for their shared NT servers. The fact that the servers are shared is important, because it means that a number of Web sites are often hosted off one computer. Unfortunately, most hosting companies haven't properly secured their shared systems, and so any client who knows how to access FSO can list, read, or write to files in any directory on the server's hard drives -- in other words, a person like me can get at proprietary source code and credit card databases that reside on another Web site.
There are actually two problems with FSO. The first is the ability to modify files in other virtual Webs. The second is the ability to modify files anywhere on any connected hard drive -- including the root directory. Although both are serious problems, the latter gives attackers access to the entire server and all the processes running on it.
"This is definitely not the way it should be," insists Josh Rivel, Systems Administrator in charge of security at DTI (www.dti.com), a boutique hosting service in Manhattan. "The ability to look at any file on the server is not good behavior. NT is harder to secure because most NT people just want 'everything opened up' on their boxes."
When it comes to opening everything up, Microsoft is quite accommodating. By default, FSO allows anyone to access any directory on the hard drive, including the root level. Even though hosting companies can take a number of precautions to limit clients only to the directories within their respective sites, the majority of hosts that support ASP have not done anything at all. As a test, I contacted a number of hosting companies, and in every case but one (Verio), I was able to upload a simple script that uses FSO to peek at the available drives and files on the system. The script I used appears in
Listing 1.
Of the seven hosts that I surveyed, only three now provide secure use of FSO. Two un-named hosts still have the FSO security hole and one host blocks FSO altogether.
Secure Hosts
Two of the largest hosts, Verio (home.verio.net) and Hiway Technologies (www.hiway.com) are now one. All of Verio's new NT shared hosting accounts are served from Hiway's facilities in Boca Raton, FL. Verio is the only service to pass my test right form the beginning. I could not see their C: drive or any other virtual Webs.
Interland (www.interland.net), on the other hand, had both problems at first. I could see all available drives and all the other virtual Webs. Shortly after notifying them of the problem, they blocked me from seeing the drives. Surprisingly, I had to ask Interland for FSO access in the first place. Apparently, they make the object available to their clients only on request. They exercise this practice for other objects as well.
By April, all new Interland accounts will be placed on Windows 2000 servers along with new security arrangements. All existing customers will be migrated over time. The most notable change to security is that each virtual Web gets its own Anonymous User Account. This is used to prevent access to all files and folders outside of the virtual web. But access is still needed for the WinNT folder. To secure that as well, Interland will not accept the default Windows Folder name. Additionally, Interland is working closely with Microsoft to develop a thorough security standard.
Smaller Hosts
I should note that not all hosts were happy to have me looking around for security holes. "We have no interest in your services or your article," was the reply from a sales representative for one of two smaller hosts. The other host became irate when I explained my plan. I can accept their grievances; given the tight competition among hosts and the current sensitivity to security issues these days, bad news like this could sink a small host.
That is not to say smaller hosts are not secure. HiSpeed Technologies (www.hispeed.com) restricts FSO from all anonymous visitors. This is a reasonable solution considering FSO is not in their list of features. In fact, it was not listed as a feature for any of the hosts I tested. Taking away all FSO privileges may not be the ultimate solution, but it is simple. "The way to restrict FSO is by using regedt32 on Scripting.FileSystemObject, in HKEY_CLASSES_ROOT, and choosing Permissions from the Security menu," explains Chris Porter, System Administrator for HiSpeed. He adds that security for classes can be used to grant access to FSO on an as-needed basis.
Another one of the smaller hosting services, Intermedia (www.intermedia.net) proved to be quite knowledgeable about the problem. Although I could browse their C: drive, they had already implemented a separate Anonymous User Account for each virtual Web which restricted me from seeing any other virtual webs. They do deserve an additional compliment for their friendly control panel which includes several security features such as setting NT privileges for users and DLLs by folder.
Patching Holes
The first hole -- the ability to browse other virtual Webs -- is caused during the installation of Microsoft's IIS Web server, when an Anonymous User Account (IUSR_machinename) gets created and added to the Guests group. This account gets associated with any new virtual Webs that are created. Ultimately, visitors to one site are using the same account as visitors to any other site on that server. Ken Tegels, an MCSE and Web Techniques contributor, further explains, "The install process sets up [the account settings] for the default Web. When a new virtual site is created, it inherits the account used in the default Web."
The other hole -- the ability to see the root directory -- is caused by the way NT includes the Everyone group in the security permissions for all resources. This means anyone, including an anonymous visitor, has access to all drives, files, and folders on the server. According to Microsoft, this is not an actual security hole, but a problem with the way people configure the server. A good MCSE should know to adjust the settings for the proper security. Regardless, one would think that the default IIS settings would not create an insecure configuration.
The obvious solution is for server administrators to change the security permissions manually. But be warned. Such changes can cause access problems. It is best to keep a complete audit of the settings before making any changes so that they can be restored in the event of a problem. And of course you should thoroughly test your procedures on a non-production server.
To summarize, the steps a company should take to secure its shared host are outlined below:
-
Give each virtual Web its own Anonymous User Account and restrict the access of those accounts to within their own virtual Web. You can change the account associated with a virtual Web through the Internet Service Manager. The association is in the Directory Security Properties Sheet of the virtual Web.
-
Remove the Everyone group from all files and folders. (Note that this may not be practical for some special folders like Windows, System, and the temporary files folder.)
-
Restrict access to files in special folders as much as possible.
-
Define Temporary Files so that they are placed in their own separate folder, instead of the Windows folder.
-
Do not accept the default Windows folder name during installation.
-
Grant FSO access only to the clients who request it.
Responsibility
It would be unfair to hold hosts entirely responsible. The fact is, shared hosting is inherently insecure. There are still other ways to break in. This one happens to be particularly powerful.
It is important for Internet-based businesses to fully research their hosting companies before buying services. Such businesses need to know that any data they put on the server is at risk. "If a customer is storing large amounts of sensitive information like credit card numbers, they really should be moved to a dedicated server," notes Chris Bell, Director of Network and Systems Operations for Interland.
The general public, too, needs to learn and demand more from the growing number of sites that collect sensitive data. Even in cases when SSL is used to securely transmit credit card numbers and other personal information, it's possible for the data to be stored where other parties can access it.
The fact that FSO holes still exist, so long after the object was first introduced, shows that we must continue to pay close attention to security. The responsibility to stay informed and aware lies on all sides -- the Web hosting company, the Internet business, and the end user.
Chuck is a Web developer who specializes in database enabled applications.
You can download a copy of the Web Based Windows Explorer from his site at
www.newmanservices.com.
Previous Page |
1
|
2
|
3
