Attacking the Web Server
As with any kind of application, a web application is dependent on the other layers of the technology stack that support it, including the web server, operating system, and networking infrastructure. Any of these components may be targeted by an attacker, and compromising the technology on which an application depends will very often enable an attacker to fully compromise the application itself.
Most attacks in this category are outside the scope of a book about attacking web applications. One exception to this is attacks that target the web server layer. The web server is intimately tied up with the application that runs on it, and defects within a web server can often be used to attack the application directly, rather than indirectly, by first compromising the underlying host.
Vulnerable Web Server Configuration
Even the simplest of web servers comes with a wealth of configuration options that control its behavior. Historically, many servers have shipped with insecure default options, which present opportunities for attack unless they are explicitly hardened.
Default Credentials
Many web servers contain administrative interfaces that may be publicly accessible. These may be located at a specific location within the web root or may run on a different port such as 8080 or 8443. Frequently, administrative interfaces have default credentials that are well known and are not required to be changed on installation.
Examples of default credentials on some of the most commonly encountered administrative interfaces are shown in Table.
Table : Default Credentials on Some Common Administrative Interfaces
In addition to administrative interfaces on web servers, numerous devices, such as switches, printers, and wireless access points, use web interfaces that have default credentials that may not have been changed. The following resources list default credentials for a large number of different technologies:
■ www.cirt.net/cgi-bin/passwd.pl
■ www.phenoelit.de/dpl/dpl.html
Default Content
Most web servers ship with a range of default content and functionality that you may be able to leverage to attack either the server itself or the main target application. Here are some examples of default content that may be of interest:
■ Debug and test functionality designed for use by administrators.
■ Sample functionality designed to demonstrate certain common tasks.
■ Powerful functions not intended for public use but unwittingly left accessible.
■ Web server manuals that may contain useful information that is difficult to obtain elsewhere or is specific to the installation itself.
Debug Functionality
Functionality designed for diagnostic use by administrators is often of great value to an attacker because it may contain useful information about the configuration and runtime state of the server and applications running on it.
Figure 1 shows the default page phpinfo.php , which exists on many Apache installations. This page simply executes the PHP function phpinfo() and returns the output. It contains a wealth of information about the PHP environment, configuration settings, web server modules, and file paths.
Figure : The default page phpinfo.php
Sample Functionality
Many servers include by default various sample scripts and pages designed to demonstrate how certain web server functions and APIs can be used. Typically, these are intended to be innocuous and to provide no opportunities for an attacker. However, in practice this has not been the case, for two reasons:
■ Many sample scripts contain security vulnerabilities that could be exploited to perform actions not intended by the scripts’ authors.
■ Many sample scripts actually implement functionality that is of direct use to an attacker.
Powerful Functions
Some web server software contains powerful functionality that is not intended to be used by the public, but which can be accessed by end users through some means.
One example of powerful default functionality arises in the PL/SQL gateway implemented by Oracle Application Server. This provides an interface whereby web requests are proxied to a back-end Oracle database. Arbitrary parameters can be passed to database procedures using URLs like the following:
https://wahh-app.com/pls/dad/package.procedure?param1=foo¶m2=bar
This functionality is intended to provide a ready means of converting business logic implemented within a database into a user-friendly web application. However, because an attacker can specify an arbitrary procedure, he can exploit the PL/SQL gateway to access powerful functions within the database. For example, the SYS.OWA_UTIL.CELLSPRINT procedure can be used to execute arbitrary database queries, and thereby retrieve sensitive data:
https://wahh-app.com/pls/dad/SYS.OWA_UTIL.CELLSPRINT?P_THEQUERY=SELECT+*+FROM+users
To prevent attacks of this kind, Oracle introduced a filter known as the PL/SQL Exclusion List. This checks the name of the package being accessed and blocks attempts to access any packages whose names start with the following expressions:
SYS.
DBMS_
UTL_
OWA_
OWA.
HTP.
HTF.
Directory Listings
When a web server receives a request for a directory, rather than an actual file, it may respond in one of three ways:
■ It may return a default resource within the directory, such as index.html .
■ It may return an error, such as the HTTP status code 403, indicating that the request is not permitted.
■ It may return a listing showing the contents of the directory, as shown in Figure.
Figure : A directory listing
Dangerous HTTP Methods
HTTP requests can use a range of different methods other than the standard GET and POST methods. Many of these methods are
designed for unusual and specialized tasks. If they are accessible by low-privileged users, they may provide an effective avenue for attacking an application. Here are some methods to look for:
■ PUT — Uploads the attached file to the specified location.
■ DELETE — Deletes the specified resource.
■ COPY — Copies the specified resource to the location given in the Destination header.
■ MOVE — Moves the specified resource to the location given in the Destination header.
■ SEARCH — Searches a directory path for resources.
■ PROPFIND — Retrieves information about the specified resource, such as author, size, and content type.
■ TRACE — Returns in the response body the exact request received by the server. This may be used to circumvent some protections against cross-site scripting.
The Web Server as a Proxy
Web servers are sometimes configured to act as forward or reverse HTTP proxy servers. If a server is configured as a forward proxy, then depending on its configuration, it may be possible to leverage the server to perform various attacks as follows:
■ An attacker may be able to use the server to attack third-party systems on the Internet, with the malicious traffic appearing to the target to originate from the vulnerable proxy server.
■ An attacker may be able to use the proxy to connect to arbitrary hosts on the organization’s internal network, thereby reaching targets that cannot be accessed directly from the Internet.
■ An attacker may be able to use the proxy to connect back to other services running on the proxy host itself, circumventing firewall restrictions and potentially exploiting trust relationships to bypass authentication.
Securing Web Server Configuration
Securing the configuration of a web server is not inherently a difficult task, and problems typically arise through oversight or lack of awareness. The most important task is to fully understand the documentation for the software you are using and any hardening guides available in relation to it. In terms of generic configuration issues to address, be sure to include all of the following areas:
■ Change any default credentials, including both usernames and passwords if possible. Remove any default accounts that are not required.
■ Block public access to administrative interfaces, either by placing ACLs on the relevant paths within the web root or by firewalling access to nonstandard ports.
■ Remove all default content and functionality that is not strictly required for business purposes. Browse the contents of your web directories to identify any remaining items, and use tools such as Nikto as a secondary check.
■ If any default functionality is retained, harden this as far as possible to disable unnecessary options and behavior.
■ Check all web directories for directory listings. Where possible, disable directory listings in a server-wide configuration. You can also ensure that each directory contains a file such as index.html , which the server is configured to serve by default.
■ Disable all methods other than those used by the application (typically GET and POST ).
■ Ensure that the web server is not configured to run as a proxy. If this functionality is actually required, harden the configuration as far as possible to allow connections only to the specific hosts and ports that may be legitimately accessed. You may also implement network-layer filtering as a secondary measure to control outbound requests originating from the web server.
