by Rik Farrow <rik@spirit.com>
Some people consider Web site defacement a trivial thing, equivalent to the 'tags' spray-painted by street gangs. But there is another very reasonable way to view Web defacements, and that is as a measure of Web site security. It doesn't take a rocket scientist to understand that if someone can replace your Web server's home page, you have a security problem.
I had recently come across Attrition's page that lists Web server defacement statistics. What really caught my eye was that consistently, it is NT servers getting defaced. Averaging 60%, and hitting 64% in April 2000, NT was certainly the champ when it comes to being defaced. If you lump all Linux distributions together, they come in second with an average rate of 17%, followed by Solaris at 10% per month. And the rate of Solaris defacements has been declining, even as the NT rate has gone up.
Perhaps the high rate of NT defacements has to do with it having become the predominat Web server platform. But it is not by a log shot. Netcraft's Web site survey shows that the Apace Web server outnumbers all Microsoft-based solutions by almost three-to-one. In other words, even though NT Web servers are not the most popular, they are defaced much more frequently than any other Web server platform.
Regardless of the platform you decide to use for your Web server, you do want to secure it carefully. Just running your Web server on a platform that has a reputation for security obviously isn't working. While this column focuses on things you can do to secure NT-based Web servers, it also makes suggestions for UNIX or Linux-based servers.
The first thing you will notice when you search the Internet is that there is a lot more information available for securing UNIX and UNIX-based Web servers than for NT (see Resources). UNIX systems in general offer many more potentially vulnerable network services, and have features not present in NT that make it easier to elevate privileges once you have broken into the system.
If NT has better (potential) security than UNIX or Linux, why does it get hacked so often? The problems lie no so much in NT itself, but in IIS (Internet Information Server). IIS attempts to do a lot more than Apache, and this has been one cause of problems.
Last year, a buffer overflow attack for IIS was discovered, and an exploit published by eEye (http://www.eEye.com), a Southern California-based security team, that permitted the attacker to upload and execute the code of his/her choice. While this attack relied on the buffer overflow within IIS (yes, you do want to upgrade your server if you haven't within the past year), it also relied on other features of the Win32 API, that makes it simple to do things like upload code (a single function call).
The Apache Web server has not suffered from buffer overflows in many years. NCSA 1.3, the early codebase for Apache, did have a buffer overflow used in a spectacular hack of GE Plastics back in 1994. But within the last year, the only security patch to Apache had to do with the CERT advisory warning that error messages sent back by Web servers could include scripting if an attacker creates the Web page used to access the Web server (CERT Advisory CA-2000-02). Microsoft also released a patch to deal with this issue in IIS.
Besides the buffer overflow, Rain Forest Puppy (RFP) released a Perl script that could execute arbitrary commands on IIS servers that had one of a variety of sample scripts on them (his second advisory in 1999). Coincidently, Attrition reported an all time one day record for defacements shortly thereafter. Statistically, most defacements happen on Sunday. You might consider writing a script that grabs your home pages, compares it to what it should be, and emails or pages you if it has changed.
The Apache software also comes with example scripts. In older releases, these scripts were installed in cgi-bin, the default scripts directory. If you left these examples scripts here, they could be exploited. Newer releases of Apache have moved these scripts to a sample directory that is not accessible by default.
Whether you are using IIS or some other Web server software, you want to remove all sample scripts. You may want to keep these scripts for reference--that is fine, just do not leave them in the Scripts folder under NT, or under cgi-bin under UNIX, both directories found in the server root directory. Note that both IIS and Apache can have additional script directories, and you must treat these the same way. And, don't forget that subdirectories are included as well (for example, cgi-bin/ photoads, or Scripts\Tools).
If you do include scripts in your Web server, you must check them carefully for subtle flaws. The single, most commonly made error in writing scripts (or programs) for execution on Web servers is trusting client input. A classic UNIX exploit is to include a command terminator at the end of some expected input, for example, a name or email address. If the script trusts the input, it may pass the input unmodified as an argument to a UNIX command, and the portion after the command terminator (a semi-colon, newline, and many other characters) would be executed by the shell.
Microsoft's Visual Basic also includes a shell function that can use cmd.exe to run other programs on the NT server--this is not just a UNIX issue. And Perl, used on both UNIX and NT servers, is can also be manipulated with unexpected input.
Besides trusting user input, the Web script writer cannot trust anything passed from the remote client. While the script writer expects that his or her script is receiving input from a browser, an attacker can simulate a Web browser request using a tool (like RFP's exploit) or simply by hand entering it using telnet or netcat. Examples of this include trusting the value of HTTP-REFERRER, or hidden form variables. An attacker has complete control over what gets sent to your Web server, and it is your job to exclude the unexpected.
CERT (Computer Emergency Response Team) put out a sample Perl script years ago that is designed to filter out any unexpected characters received as input. The script writer creates a set of expected characters, and uses a substitute command that replaces anything not in this set with an underscore character.
An issue specific to NT has to do with passwords. NT's security model means that usernames and passwords must be included in scripts that will connect to Access or SQL databases. The scripts directories should not appear within the Web document hierarchy (webroot or htdocs), and the scripts themselves protected. IIS offers one level of protection (on top of NTFS ACLs), and for scripts, should be configured to permit execution only.
NT and IIS have had problems with preventing read access to scripts. Some six different tricks for reading instead of executing scripts have appeared within the last several years -- all soon patched by Microsoft. Five of these tricks involved simply appending some characters to the end of a script's pathname, and one used an example script to read arbitrary files on the Web server.
Although Web server software does attempt to control access, it still makes a lot of sense to take advantage of the operating system's ownership and permissions or access control. Whether you are using NT or UNIX, documents and scripts should never be owned by the user account that runs the Web server. On NT systems, this account is named IUSR_xxx, where xxx is the system name. Most UNIX and Linux systems use the account nobody, although some have a special account name (beginning with www) for running the Web server.
If there is a flaw in the Web server software, or in scripts executed by the Web server, if documents and scripts are not owned by the Web user account, and not writeable by the Web user account, they cannot be modified. Simply correcting ownership and permissions (ACLs under NT) to prevent writing would have prevented many of the defacements, especially those on NT systems.
Directories within the Web hierarchy must also be protected. Both NT and UNIX permit files within a directory to be deleted if the directory permits this action. On UNIX, this requires write and execute permision, and there is a specific delete permission in NTFS on directories. What is not generally known about NTFS is that delete permission on a directory implies delete-tree, permitting the removal of files and subdirectories.
Web servers are most secure when configured as bastion hosts. Bastion hosts, so named because they have been fortified, have software removed and network services disabled. Within NT, you can unbind NetBIOS from the network interface, disable all services except EventLog, NTLM Secrutiy Support Provider, Protected Storage (if you have this), and Remote Procedure Call (RPC) Service. These services are required for running IIS (and for logging in to maintain the system). Also use IP filtering under the advanced menu of the Network control panel to permit access just to port 80/TCP, as the RPC services will appear the common problem ports for NT systems: 135, 137 138, and 139.
If you are working with UNIX or Linux, disable all services started from within /etc/inetd.conf, and remove the links to startup scripts in the /etc/rc.d directories that start network services. With both NT and UNIX, reboot, and use netstat -a to list the services still listening (the flag LISTENING in the far right column). On UNIX, you should see only httpd (port 80) listening, along with local domain sockets if you are runing X (using a text console is more secure and recommended). On NT, all you should see are the RPC services and IIS. Note that running the RPC services and IIS results in some ports being open in the 1025 to 1035 range, and that this is to be expected.
Only sysadmins have accounts on the bastion host. Web content is most safely added from the developement Web server to the bastion by putting the files on a backup media, such as a zip or writeable CD, and installing them from the console. In the NT world, helpful tools, like FrontPage, have also been helpful to hackers.
And, of course, the bastion host is protected by a firewall. What may look like overkill is simply protection in depth, like wearing seatbelts in a car with airbags. You really do want both -- a bastion host configuration and a firewall. The firewall should also protect the internal network from the Web server, in case it still gets compromised. Most commercial firewall support three network interfaces, and the Web server(s) belong on the DMZ (Demilitarize Zone, or optional) interface.
Operating system vendors have done a lot to make their systems friendlier and easier to use. Placing a Web server on the Internet has nothing to do with ease-of-use for the owners of the Web server, and everything to do with the tightest security you can manage. Just because an operating system has proven security features, doesn't mean that it will be secure when you add insecure applications. NT's C2 certification only applies <i>when NT is not connected to a network</i>. Don't become a statistic. Secure your Web servers.
Survey of Web server types: http://www.netcraft.com/survey/ (top three, Apache 62%, Microsoft, 21%, iPlanet 7%) 14,322,950 Web servers
Attrition's Web defacement mirror: http://www.attrition.org/mirror/attrition/os.html
Steve Sutton's NT security Guide:
http://www.trustedsystems.com/tss_nsa_guide.htm
Microsoft IIS 4.0 Security Checklist:
http://www.micorosoft.com/security/products/iis/CheckList.asp
Stefan Norberg's excellent paper and tools for creating an NT bastion host (separate paper for HP/UX): http://people.hp.se/stnor/
AUSCert NT security suggestions:
http://www.auscert.org.au/Information/Auscert_info/Papers/
win_configuration_guidelines.html, (US mirror,
http://www.securityfocus.com/library/2335)
The World Wide Web Security FAQ by Lincoln D. Stein <lstein@cshl.org> http://www.w3.org/Security/Faq/
Rain Forest Puppy's Web site, with several IIS exploits: http://www.wiretrip.net/rfp/