Web Servers

Web Servers

Every time a browser connects to a Web site on the Internet (or intranet for that matter), it is connecting to a Web server. The server listens for requests on the network and responds to the requester with specific data.

Apache

As stated in the foundation's Web site, "Apache has been the most popular Web server on the Internet since April of 1996." Apache's (http://www.apache.org) popularity is largely attributed to three factors: platform support, features, and price. The Apache Web server runs on almost every popular platform available, including NetBSD, Digital UNIX, AIX, OS/2, Windows 3.x, SCO, HPUX, Novell NetWare, Macintosh, Be OS, Windows NT, Linux, VMS, AS/400, Windows 95, FreeBSD, IRIX, and Solaris. In addition, the Apache Web server always offers a wide variety of features, allowing developers to create and enhance a Web site's design quickly. Last, but certainly not least, the Apache Web server offers the best price: It's free!

With over 56% of all Web servers using Apache today (Netcraft 2001), it is not surprising that it is a common target of hackers. Every added platform and feature provide added opportunity for an attacker to take advantage of a programming weakness.

The version of Apache we discuss in this chapter is 2.0.32. It contains features rife with security implications:

         Virtual hosts

         Server Side Includes

         Dynamic Content with CGI

         Handlers

         Environment variables

         Mapping URLs to the file system (http://httpd.apache.org/docs-2.0/)

With so much going for it, Apache attracts the best (or worst) in people. Many are targeting it in attempt to find vulnerabilities and exploit them.

Virtual Hosts

The growth of the Internet, and the millions of Web pages it serves up daily, may never have been realized had it not been for the concept of virtual hosts. This simple feature allows one computer to host numerous Web servers at the same time. As a result, one physical computer running one Web server, can serve up pages to a myriad of Web sites. It does so via two mechanisms: name-based and IP-based.

Name-Based Mechanism

Name-based virtual hosting requires the user to supply a unique name for each HTTP request. The name is typically the DNS name provided by the URL in the client's Web browser. The hosting company's DNS creates CNAME records in its DNS server, which all point to the same IP address. For example, if you looked up a name on three Web sites that were virtual-hosted on the same system, they would all return the same IP address. For example, let's look up the Japanese site (site 1):

C:\> nslookup www.jp.example.com
Server:  UnKnown
Address:  192.168.0.1
Non-authoritative answer:
Name:  www.jp.example.com
Address:  172.16.30.222

Let's now look up the Brazilian site (site 2):

C:\> nslookup www.bz.example.com
Server:  UnKnown
Address:  192.168.0.1
 
Non-authoritative answer:
Name:  www.bz.example.com
Address:  172.16.30.222

And, finally, let's look up the U.S. site (site 3):

C:\> nslookup www.us.example.com
Server:  UnKnown
Address:  192.168.0.1
 
Non-authoritative answer:
Name:  www.us.example.com
Address:  172.16.30.222

Note that all three Web sites have the same IP address. Detection of name-based virtual host sites is trivial, but IP-based virtual hosts aren't.

So, if you went to a Web site that was hosted along with others on the same system, you would type:

http://www.us.example.com

The browser would submit an HTTP GET request, designating the true destination with the Host: header:

GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.0)
Host: www.us.example.com
Connection: Keep-Alive

Once the Web server received the HTTP GET request, it would strip off the

Host: www.us.example.com

and forward the page request to the virtual host of www.us.example.com. As a result, the Web server would display only the Web pages specific to www.example.com and not the dozens of other Web sites that call this system home.

IP-Based Mechanism

With IP-based virtual hosting, the server must have a different IP address for each virtual Web site. This condition is the same as creating secondary IP addresses on Windows systems and IP aliases on Unix systems.

UNIX IP Aliasing

Unix users must employ IP aliasing. It typically is performed with the ifconfig command. For example, if you had a base IP address of 172.16.30.222 for eth0, to add three IP addresses to the eth0 interface, you would use:

[root@jack /opt]# /sbin/ifconfig eth0:0 172.16.30.50
[root@jack /opt]# /sbin/ifconfig eth0:1 172.16.30.51
[root@jack /opt]# /sbin/ifconfig eth0:2 172.16.30.52
[root@jack /opt]# /sbin/ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:50:04:91:D5:A0
  inet addr:172.16.30.2  Bcast:172.16.30.255  Mask:255.255.0.0
  UP BROADCAST RUNNING  MTU:1500  Metric:1
  RX packets:33272 errors:20 dropped:0 overruns:20 frame:20
  TX packets:22851 errors:0 dropped:0 overruns:0 carrier:0
  collisions:309 txqueuelen:100
  Interrupt:3 Base address:0x300
 
eth0:0  Link encap:Ethernet  HWaddr 00:50:04:91:D5:A0
  inet addr:172.16.30.50  Bcast:172.16.30.255  Mask:255.255.0.0
  UP BROADCAST RUNNING  MTU:1500  Metric:1
  Interrupt:3 Base address:0x300
eth0:1  Link encap:Ethernet  HWaddr 00:50:04:91:D5:A0
  inet addr:172.16.30.51  Bcast:172.16.30.255  Mask:255.255.0.0
  UP BROADCAST RUNNING  MTU:1500  Metric:1
  Interrupt:3 Base address:0x300
 
eth0:2  Link encap:Ethernet  HWaddr 00:50:04:91:D5:A0
  inet addr:172.16.30.52  Bcast:172.16.30.255  Mask:255.255.0.0
  UP BROADCAST RUNNING  MTU:1500  Metric:1
  Interrupt:3 Base address:0x300

All three of the new IP addresses took on the eth0:x interface, indicating that the eth0 interface had three new aliases: 172.16.30.50, .51, and .52.

Unlike name-based virtual hosting, with IP-based virtual hosting, each IP address must have a separate and distinct DNS name associated with it. In other words, each IP address created must have a record in the DNS. Refer to your DNS documentation to perform this function.

Each IP address must now be mapped to the appropriate Web server, using Apache's httpd.conf file and the VirtualHost directive:

<VirtualHost 172.16.30.50>
ServerAdmin webmaster@mail.example.com
DocumentRoot /opt/apache/jp
ServerName www.jp.example.com
ErrorLog /opt/apache/jp/logs/error_log
TransferLog /opt/apache/jp/logs/access_log
</VirtualHost>

And so on, for each virtual host.

Unlike name-based virtual hosting, IP-based detection is much more difficult; after all, each Web server is associated with a separate and distinct IP address. One of the only mechanisms for discovering an IP-based virtual host is looking at the MAC address for each IP address. This technique requires the attacker to listen on the local LAN, so it can provide a mechanism for detection, because the MAC address for each virtual IP address is the same.

Virtual hosting isn't a security concern per se, but it does have security implications because, once a single virtual Web site has been compromised, every Web site on that system has been compromised.

Server Side Includes

As discussed in Chapter 1, Server Side Includes (SSI) are directives within HTML Web pages that provide server-side functionality. Typically used for generating dynamic content on a Web page, SSI are similar to CGI. By default, Apache no longer turns on SSI, which is a good thing. However, Web sites often turn on this feature and tell the Web server to take all files with a .shtml extension and handle them as SSI.

We discussed the security implications of using SSI in Chapter 1, so we won't repeat the warnings. However, if you do use SSI, be sure to disallow the exec cmd directive. To disable this directive, you can specify the IncludesNOEXEC argument with the Options directive in Apache's httpd.conf file.

CGI

Also discussed in Chapter 1, Common Gateway Interface (CGI) is one of the original mechanisms developed for delivering dynamic content to the Web. Apache supports a variety of CGI technologies and setup of CGI is trivial.

ScriptAlias

The ScriptAlias directive in the httpd.con file, tells Apache that the following directories contain scripts that must be executed. The ScriptAlias directive looks something like this:

ScriptAlias /cgi-bin/ /opt/apache/cgi-bin

It tells Apache that any request beginning with the /cgi-bin directory, must be mapped to the /opt/apache/cgi-bin directory. ScriptAliases are ways of securing your Web server, because they control where scripts can be executed.

Handlers

A handler (in Web server terms) is a mechanism that handles Web requests based on the file name, which is how much of the Internet is run today. Certain files (.jsp, .asp, and so on) require certain actions (Java engine, ASP engine, and so on). Since the advent of Apache 1.1, the Web server has the capability of explicitly defining the action taken on a file based on its file name, rather than depending on hard-coded defaults. As a result, a developer can map a handler to a nonstandard file name.

Built-in handlers include a default handler that takes care of static content, typically HTML. However, additional default built-in handlers are available, including mod_asis, mod_cgi, mod_imap, mod_info, mod_status, and mod_negotiation. Although these are built-in handlers, you can add them manually with the Action directive. This directive allows a Web server to handle certain requests with a specific CGI file. For example, to have all files ending in .stu handled by a customer Perl script you would add the following to the httpd.conf:

AddHandler my-file-type .stu
Action my-file-type /cgi-bin/stu.pl

For more information on Apache and how to make it secure, check out http://httpd.apache.org/docs-2.0/misc/security_tips.html.

Microsoft's Internet Information Server (IIS)

Microsoft has long viewed its IIS Web server as a crucial wedge in its Internet strategy. So great is Microsoft's belief in IIS that the company has bundled the Web server with its Windows operating system since NT 4.0. Although IIS's ubiquity is unrealized and its market share compared to Apache is anemic, it is a remarkable piece of software. Will it dominate the market and take over the digital online world, as Microsoft would like it to? Only time will tell. But its sievelike default configuration can be a cornucopia of security vulnerabilities.

In this section, we discuss the various security components of IIS and the fundamental vulnerabilities that allow an attacker to turn your firewall into Swiss cheese.

ISAPI Applications

When we're asked, "What is the single largest security risk to IIS Web servers?," the only truthful answer is, "Internet Server Application Programming Interface (ISAPI) applications." The ISAPI allows Web programmers to extend the functionality of the IIS Web server by allowing them to write their own programs to process and handle data and requests being sent to the Web server. In addition, ISAPI applications allow a developer to "catch" all the packets coming into a Web server and preprocess them. This allows for increased control over the requests and prevents attacks on Web servers (see URL scan later in this chapter). Ironically, the preprocessing of packets opens your Web server to attack.

How? By default, IIS installs a large number of ISAPI filters that can be used to break into Web servers. Why? Because of the law of averages. Given enough entry points into your Web server, an attacker will find his way in, and ISAPI filters provide those entry points.

Among the myriad ISAPI filters installed in a default Windows 2000 (IIS 5.0) installation are those displayed in Table 2-1.

Although the ISAPI filters add volumes of functionality to the Web server, they add volumes of potential migraines in the form of security holes. Take, for example, the .idq and .ida filters. They are, in no small part, responsible for the Code Red and Nimda worms, claiming more than $100,000 in damages per Fortune 1000 company. The Code Red worm took advantage of a buffer overflow condition in the .ida extension. The worm exploited the .ida Index Server vulnerability, which allowed the attacker to send a request to the Web server and cause an overflow of the DLL handling the request, thereby executing commands on the remote system. The beauty of the attack was that the payload was in the HTTP request itself. Thus the request was nearly legitimate and completely acceptable by just about all the firewalls or proxies in use. The results were broad and far-reaching: The attacker executed a command on the remote systems and effectively took control of them.

The solution to the filters problem is to stay abreast of all Microsoft security patches and apply the appropriate ones. However, a workaround (and general hardening step) that can be used is to remove all unnecessary ISAPI filters from the Web server, which can be done through the Internet Services Manager. To do so, select Properties on the Web server running. Then select the ISAPI filters tab and remove the offending filter (if not all of them). Next, select the Home Directory tab and select Configuration. As shown in Figure 2-1, the default application mappings is listed there. Finally, remove the mappings, one by one.

Figure 2-1. Application mappings in IIS

graphics/02fig01.gif

Note: You should do the same thing on your Web Master Properties. To do so, right-click on the system name in Internet Service Manager, hit Properties, and perform all the preceding steps. This removes the ISAPI mapping and filters for all Web servers involved.

In addition, homegrown or default ISAPI filters can be danger points. ISAPI filters are programs that act as shims, catching requests coming in before the back-end ISAPI application acts on them. Default ISAPI filters that can be removed or disabled are:

         Sspifilt

         Compression

Table 2-1. ISAPI Filters

ISAPI Extension

Executable Path

Description

.asa

C:\winnt\system32\inetsrv\asp.dll

Active Server Page server-side scripting extension allows dynamic content delivery.

.asp

C:\winnt\system32\inetsrv\asp.dll

Active Server Page server-side scripting extension allows dynamic content delivery.

.cdx

C:\winnt\system32\inetsrv\asp.dll

Active Server Page server-side scripting extension allows dynamic content delivery.

.cer

C:\winnt\system32\inetsrv\asp.dll

Active Server Page server-side scripting extension allows dynamic content delivery.

.htw

C:\winnt\system32\inetsrv\ism.dll

Index Server extension

.ida

C:\winnt\system32\inetsrv\idq.dll

Index Server extension

.idq

C:\winnt\system32\inetsrv\idq.dll

Internet Data Queries, Index Server extension

.idc

C:\winnt\system32\inetsrv\httpodbc.dll

Internet Database Connector

.htx

C:\winnt\system32\inetsrv\httpodbc.dll

Internet Database Connector (IDC) uses ODBC APIs to communicate with database sources such as SQL Server.

.printer

C:\winnt\system32\msw3prt.dll

Internet Printing

.shtm

C:\winnt\system32\inetsrv\ssinc.dll

Server-Side Includes provides dynamic content delivery to the Web.

.shtml

C:\winnt\system32\inetsrv\ssinc.dll

Server-Side Includes provides dynamic content delivery to the Web.

.stm

C:\winnt\system32\inetsrv\ssinc.dll

Server-Side Includes provides dynamic content delivery to the Web.

.htr

C:\winnt\system32\inetsrv\ism.dll

Web-based Administration provides a means of performing administrative functions via the Web, such as changing passwords.

         Md5filt

         Fpexedll.dll

To remove them, simply edit the Service Master properties and Web server properties.

Virtual Directories

IIS has an added feature, virtual directories, which is similar to the linking ability in UNIX systems. These directories allow an administrator to set up a link between a directory under the Web root and another directory on the hard drive or on a remote system. Unfortunately, the installed default virtual directories must be removed. To remove them simply use Internet Services Manager, click on the Web server desired, and then select the virtual directories that you don't need.

Among the virtual directories typically unnecessary in an IIS 5.0 installation are the following:

         Scripts if you need CGI or ASP or ISAPI functionality you'll need a directory with script execution permission, but we always recommend removing the scripts directory, because it is a common target. See Figure 2-2.

Figure 2-2. ISAPI filters that can be removed

graphics/02fig02.gif

         _vti_bin needed for FrontPage support.

         Printers typically used for printing from the Web.

These and other virtual directories can be removed without much impact on your system. However, every system is unique, so be sure to check with your system administrator before removing them.

Sample Files

As with any application, IIS contains a variety of default application files. Typically, these files are instrumental in writing code and understanding the functionality of a particular feature. However, because these files are provided by default and are oriented toward developers, they often contain security holes. For Windows 2000 systems running IIS 5.0, the following files are installed by default:

Description

Default Location

Virtual Directory

IIS sample files

c:\inetpub\iissamples

\IISSamples

IIS documentation

c:\winnt\help\iishelp

\IISHelp

Data access

c:\program files\common files\system\msadc

\MSADC

The general rule after every installation is to remove or, at a minimum, assign an Access Control List (ACL) to the file, using NTFS permissions. Removing the offending files and directories is both the best solution and the simplest to employ, but it isn't always realistic. For example, if your application contains certain sample components, removal of the files may break production functionality. As an alternative, you can restrict access to these systems to only those who need them, such as administrators (a.k.a. developers).

NTFS file permissions are simple to assign but can break things if not applied properly. To apply ACLs correctly you must answer the following questions:

         What files are available to the Web site? (In some cases you may want to assume that all the files are available and are ACLs.)

         What permissions are required to retain complete functionality?

Once you know the answers to these two questions, assigning ACLs to files is a trivial matter. Figure 2-3 shows the default permission assignment on the iissamples directory, "Everyone, with all rights" a bad approach.

Figure 2-3. Samples directory properties

graphics/02fig03.gif

However, this situation is reparable. Simply remove the Everyone group from the list by clicking on the Remove button. Then just insert the IUSR accounts by clicking on Add and giving them read only and maybe execute permissions (based on your needs). As shown in Figure 2-4, the final permissions on a sample directory should be minimal.

Figure 2-4. Restricted samples directory properties

graphics/02fig04.gif

ACLing dramatically reduces your exposure to attack. Even if an attacker gets in to execute the offending samples file, she can't use the program to write a file in the directory (which allows an attacker to gain further access).

Virtual Hosts

As discussed in regard to Apache's virtual hosting, Microsoft allows multiple Web sites to run off a single machine as well as through secondary IP addressing (equivalent to the IP-based technique discussed) and multiple Web sites (equivalent to the name-based technique discussed).

Even though it isn't an enormous security risk, virtual hosting poses an interesting challenge for an attacker. If the hacker determines that virtual hosting is set up, he may find the target more enticing than most and be willing to forgo hack attempts on other sites. The following steps describe how virtual hosting is set up on a Windows system to run multiple Web sites on a single system.

Secondary IP Addresses

The first step is to create secondary IP addresses. Doing so on a Windows system is trivial, and most system administrators will configure the network interface by doing the following:

1.       Click on the Start menu.

2.       Select the Settings menu.

3.       Select the Network and Dial-Up Connections menu.

4.       Select your network interface.

5.       Click on the Properties button, shown in Figure 2-5.

Figure 2-5. Status window

graphics/02fig05.gif

6.       Click on the Internet Protocol (TCP/IP) component and click on the Properties button.

7.       Click on the Advanced button, shown in Figure 2-6.

Figure 2-6. General Internet protocol properties tab

graphics/02fig06.gif

8.       On the IP Settings tab click on the Add button, shown in Figure 2-7.

Figure 2-7. Advanced settings tab

graphics/02fig07.gif

9.       Now, you can add additional IP addresses, as shown in Figure 2-8.

Figure 2-8. Address window

graphics/02fig08.gif

Multiple Web Sites

The next step in enabling your IIS Web server to handle multiple Web sites is to create servers and assign them to the IP address created. To do so, just do the following:

1.       Open Internet Services Manager, from the Administrative Tools menu.

2.       Once there, right mouse click on the system name.

3.       Select New->Web site.

4.       Walk through the Connection Wizard and chose the new IP address assigned to the Web server being created.

5.       Select the path to the separate Web server files.

6.       Walk through the remaining steps to define the default permissions of the Web server.

Service providers wanting to maximize resources will employ multiple Web site technologies, and most hackers know this. As a result, they often focus on ISPs for the big kill: gaining administrative access on one system can compromise dozens of Web sites.

 



Web Hacking(c) Attacks and Defense
Web Hacking: Attacks and Defense
ISBN: 0201761769
EAN: 2147483647
Year: 2005
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net