WEB SERVER HACKING | Hacking Exposed 5th Edition

Before we begin our sojourn into the depths of web hacking, a note of clarification is in order. As the term "web hacking" gained popularity concomitant with the expansion of the Internet, it also matured along with the underlying technology. Early web hacking frequently meant exploiting vulnerabilities in web server software and associated software packages, not the application logic itself. Although the distinction can at times be blurry, we will not spend much time in this chapter reviewing vulnerabilities associated with popular web server platform software such as Microsoft IIS/ASP/ASP.NET, LAMP (Linux/Apache/MySQL/PHP), BEA WebLogic, IBM WebSphere, J2EE, and so on.

Note	The most popular platform-specific web server vulnerabilities are discussed in great detail in Chapter 4 (Windows) and Chapter 5 (Linux/UNIX). We also recommend checking out Hacking Exposed: Windows Server 2003 (McGraw-Hill/Osborne, 2003) for more in-depth Windows web server hacking details.

These types of vulnerabilities are typically widely publicized and are easy to detect and attack. An attacker with the right set of tools and ready-made exploits can bring down a vulnerable web server in minutes. Some of the most devastating Internet worms have historically exploited these kinds of vulnerabilities (for example, two of the most recognizable Internet worms in history, Code Red and Nimda, both exploited vulnerabilities in Microsoft's IIS web server software). Although such vulnerabilities provided great "Low Hanging Fruit" for hackers of all skill levels to pluck for many years , the risk from such problems is gradually shrinking for the following reasons:

Vendors and the open -source community are learning from past mistakestake the negligible number of vulnerabilities found to date in the most recent version of Microsoft's web server, IIS6, as an example.
Users and system administrators are also learning how to configure web server platforms to provide a minimal attack surface, disabling many of the common footholds exploited by attackers in years past (many of which will be discussed in this section). Vendors have also helped out here by publishing configuration best practices (again, we cite Microsoft, which has published "How to Lock Down IIS" checklists for some time now). This being said, misconfiguration is still a frequent occurrence on the Internet today, especially as web-based technologies proliferate on nonprofessionally maintained systems such as home desktops (for example, Microsoft's Personal Web Server and Desktop SQL Edition products).
Vendors and the open-source community are responding more rapidly with patches to those few vulnerabilities that do continue to surface in web platform code, knowing with vivid hindsight what havoc a worm like Code Red or Nimda could wreak on their platform.
Proactive countermeasures such as deep application security analysis products (for example, Sanctum/Watchfire's AppShield) and integrated input-validation features (for example, Microsoft's URLScan) have cropped up to greatly blunt the attack surface available on a typical web server.
Automated vulnerability-scanning products and tools have integrated crisp checks for common web platform vulnerabilities, providing quick and efficient identification of such problems.

Don't for a minute read this list as suggesting that web platforms no longer present significant security risksit's just that the maturity of the current major platform providers has blunted the specific risks associated with using any one platform versus another.

Tip	Be extremely suspicious of anyone trying to convince you to implement a web platform designed from scratch (yes, we've seen this happen). Odds are, they will make the same mistakes that all prior web platform developers have made, leaving you vulnerable to a litany of exploits.

Web server vulnerabilities tend to fall into one of the following categories:

Sample files
Source code disclosure
Canonicalization
Server extensions
Input validation (for example, buffer overflows)

This list is essentially a subset of the Open Web Application Security Project (OWASP) " Insecure Configuration Management" category of web application vulnerabilities (see http://www.owasp.org/documentation/topten/a10.html). We will spend a few words discussing each of these categories of vulnerabilities next , and wind up with a short examination of available web server vulnerability-scanning tools.

Sample Files

Web platform vendors, in their never-ending desire to drive greater adoption of their technologies, frequently distribute sample scripts and code snippets to illustrate creative use of their platform. Being hastily coded themselves after all, they are samples!many of these stowaways contain serious vulnerabilities. We'll discuss a few of these here.

Note	Our subsequent discussion of buffer overflows later in this chapter will illustrate some other common scripts that have caused trouble in the past.

One of the classic "sample file" vulnerabilities dates back to Microsoft's IIS 4.0. It allows attackers to download ASP source code. This vulnerability wasn't a bug per se, but more an example of poor packagingsample code was installed by default, one of the more common mistakes made by web platform providers in the past. The culprits in this case were a couple sample files installed with the default IIS4 package called showcode. asp and codebrews.asp. If present, these files could be accessed by a remote attacker and could reveal the contents of just about every other file on the server, as shown in the following two examples:

 http://192.168.51.101/msadc/Samples/SELECTOR/showcode.asp?source=/../.. /../../../boot.ini http://192.168.51.101/iissamples/exair/howitworks/codebrws.asp?source= /../../../../../winnt/repair/setup.log

L0pht discovered a number of significant sample file vulnerabilities in Allaire's ColdFusion Application Server, allowing remote command execution on a vulnerable web server. When installed, the product places sample code and online documentation. The problem lies in a number of these sample code files, because they do not limit their interaction to localhost only.

Note	Allaire was acquired by Macromedia in 2001, and the ColdFusion web application server is now a Macromedia product. All further references to Allaire in this chapter have thus been changed to Macromedia to ensure that readers approach the current vendor for questions or updates.

One of the more interesting problems has to do with the "Expression Evaluator" functionality that lies in the default installed openfile.cfm file. This file performs the uploading of the local file to the target web server, but displayopenedfile.cfm actually displays the file in your browser. Then, exprcalc.cfm evaluates the uploaded file and deletes it (or is supposed to). Using openfile.cfm alone, you can trick the system into not deleting an uploaded file and then subsequently run any command on the local system. Using a URL such as the following, an attacker can delete the exprcacl.cfm script, and then all subsequent uploads using openfile.cfm will persist on the target web server:

 http://192.168.51.101/cfdocs/expeval/ExprCalc.cfm?RequestTimeout= 2000&OpenFilePath=D:\INETPUB\WWWROOT\cfdocs\expeval\exprcalc.cfm

Now the attacker can upload malicious executables with impunity, essentially owning the server.

The best way to deal with rogue sample files like this is to remove them from production web servers. Those that have built their web apps to rely on sample file functionality can retrieve a patch in the short term; for example, the patch for the Macromedia Expression Evaluator issue described here can be found at http://www.macromedia.com/devnet/security/security_zone/asb99-01.html.

Source Code Disclosure

Source code disclosure attacks allow a malicious user to view the source code of application files on a vulnerable web server that are intended to remain confidential. Under certain conditions, the attacker can combine this with other techniques to view important protected files such as /etc//asswd, global.asa, and so on.

Some of the most classic source code disclosure vulnerabilities include the IIS +.htr vulnerability (discussed in Chapter 4) and similar issues with Apache Tomcat and BEA WebLogic related to appending special characters to requests for Java Server Pages (JSP). Here are examples of attacks on each of these vulnerabilities, respectively:

 http://www.iisvictim.example/global.asa+.htr http://www.weblogicserver.example/index.js%70 http://www.tomcatserver.example/examples/jsp/num/numguess.js%70

These vulnerabilities have long since been patched, or workarounds have been published (for example, manually removing the sample files showcode.asp and codebrews. asp; see http://www.microsoft.com/technet/security/bulletin/MS01-004.mspx for +.htr and http://jakarta.apache.org and http://dev2dev.bea.com/resourcelibrary/advisories.jsp?highlight=advisoriesnotifications for JSP disclosure issues). Nevertheless, it is good practice to assume that the logic of your web application pages will be exposed to prying eyes, and you should never store sensitive data there.

Canonicalization Attacks

Computer and network resources can often be addressed using more than one representation. For example, the file C:\text.txt may also be accessed by the syntax ..\text.txt or \\computer\C$\text.txt. The process of resolving a resource to a standard (canonical) name is called canonicalization . Applications that make security decisions based on the resource name can easily be fooled into performing unanticipated actions using so-called "canonicalization attacks."

The ASP::$DATA vulnerability in Microsoft's IIS was one of the first canonicalization issues publicized in a major web platform (although at the time, no one called it "canonicalization"). Originally posted to Bugtraq by Paul Ashton, this vulnerability allows the attacker to download the source code of Active Server Pages (ASP) rather than having them rendered dynamically by the IIS ASP engine. The exploit is easy and was quite popular with the script kiddies. You simply use the following URL format when discovering an ASP page:

 http://192.168.51.101/scripts/file.asp::$DATA

For more information regarding this vulnerability, you can check out http://www.securityfocus.com/bid/149 and get patch information from http://www.microsoft.com/technet/security/current.asp.

Probably the next most recognizable canonicalization vulnerabilities would be the Unicode/Double Decode vulnerabilities, also in IIS. These vulnerabilities were exploited by the Nimda worm. We already discussed these at length in Chapter 4 on Windows hacking, so we won't belabor the point here. Suffice it to say, again: Keep current on your web platform patches, and compartmentalize your application directory structure. We also recommend constraining input using platform-layer solutions such as Microsoft's URLScan, which can strip URLs that contain Unicodeor double-hex-encoded characters before they reach the server.

Server Extensions

Some would argue that the root of all evil ever visited upon a web server resides with server extensions, those pesky little code libraries tacked on to the core HTTP engine to provide such niftiness as dynamic script execution (for example, Microsoft ASP), site indexing (for example, Microsoft's Indexing extension, which fell victim to buffer overflows), Internet Printing Protocol (IPP, another Microsoft extension that fell victim to buffer overflow attacks, circa IIS5), Web Distributed Authoring and Versioning (WebDAV), Secure Sockets Layer (SSL; for example, Apache's mod_ssl buffer overflow vulnerabilities, and Netscape Network Security Services library suite), and so on. These add-on modules that rose to glory and faded into infamy in many casesshould serve as a visceral reminder of the tradeoffs between additional functionality and security.

The Microsoft WebDAV Translate: f problem, posted to Bugtraq by Daniel Docekal, is a particularly good example of what happens when an attacker sends unexpected input that causes the web server to fork execution over to a vulnerable add-on library.

The Translate: f vulnerability is exploited by sending a malformed HTTP GET request for a server-side executable script or related file type, such as Active Server Pages (.asp) or global.asa files. Frequently, these files are designed to execute on the server and are never to be rendered on the client to protect the confidentiality of programming logic, private variables , and so on (although assuming that this information will never be rendered on the client is a poor programming practice, in our opinion). The malformed request causes IIS to send the content of such a file to the remote client rather than execute it using the appropriate scripting engine.

The key aspects of the malformed HTTP GET request include a specialized header with Translate: f at the end of it and a trailing backslash (\) appended to the end of the URL specified in the request. An example of such a request is shown next. (The [CRLF] notation symbolizes carriage return/ linefeed characters, 0D 0A in hex, which would normally be invisible.) Note the trailing backslash after GET global.asa and the Translate: f header:

 GET /global.asa\ HTTP/1.0 Host: 192.168.20.10 Translate: f [CRLF] [CRLF]

By piping a text file containing this text through netcat, directed at a vulnerable server, as shown next, you can cause the /global.asa file to be displayed on the command line:

 D:\>  type trans.txt nc -nvv 192.168.234.41 80  (UNKNOWN) [192.168.234.41] 80 (?) open HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 23 Aug 2000 06:06:58 GMT Content-Type: application/octet-stream Content-Length: 2790 ETag: "0448299fcd6bf1:bea" Last-Modified: Thu, 15 Jun 2000 19:04:30 GMT Accept-Ranges: bytes Cache-Control: no-cache <!Copyright 1999-2000 bigCompany.com --> ("ConnectionText") = "DSN=Phone;UID=superman;Password=test;" ("ConnectionText") = "DSN=Backend;UID=superman;PWD=test;" ("LDAPServer") = "LDAP://ldap.bigco.com:389" ("LDAPUserID") = "cn=Admin" ("LDAPPwd") = "password"

We've edited the contents of the global.asa file retrieved in this example to show some of the more juicy contents an attacker might come across. It's an unfortunate reality that many sites still hard-code application passwords into .asp and .asa files, and this is where the risk of further penetration is highest. As you can see from this example, the attacker who pulled down this particular .asa file has gained passwords for multiple back-end servers, including an LDAP system.

Canned Perl exploit scripts that simplify the preceding netcat-based exploit are available on the Internet. (We've used trans.pl by Roelof Temmingh and srcgrab.pl by Smiler.)

Translate: farises from an issue with WebDAV, which is implemented in IIS as an ISAPI filter called httpext .dll that interprets web requests before the core IIS engine does. The Translate: f header signals the WebDAV filter to handle the request, and the trailing backslash confuses the filter, so it sends the request directly to the underlying OS. Windows 2000 happily returns the file to the attacker's system rather than executing it on the server. This is also a good example of a canonicalization issue (discussed earlier in this chapter). Specifying one of the various equivalent forms of a canonical file name in a request may cause the request to be handled by different aspects of IIS or the operating system. The previously discussed ::$DATA vulnerability in IIS is a good example of a canonicalization problemby requesting the same file by a different name, an attacker can cause the file to be returned to the browser in an inappropriate way. It appears that Translate: f works similarly. By confusing WebDAV and specifying "false" for translate, an attacker can cause the file's stream to be returned to the browser.

How do you prevent vulnerabilities that rely on add-ons or extensions such as Microsoft WebDAV? The most effective way is patching or disabling the vulnerable extension (preferably both). We'll quickly note the location of the Translate: f patch and how to disable the WebDAV extension to IIS to illustrate this two-pronged approach.

Microsoft released a patch for Translate: f at http://www.microsoft.com/technet/security/bulletin/MS00-058.mspx. (This patch is included in Windows 2000 Service Pack 1.) The patch allegedly makes IIS interpret server-side executable scripts and related file types using the appropriate server-side scripting engine, no matter what header is sent.

To disable WebDAV on IIS 5.0 (if you are not using it), follow the Microsoft Knowledge Base article at: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q241520&.

Buffer Overflows

As we've noted throughout this book, the dreaded buffer overflow attack symbolizes the coup de grace of hacking. Given the appropriate conditions, buffer overflows often result in the ability to execute arbitrary commands on the victim machine, typically with very high privilege levels.

Buffer overflows have been a chink in the armor of digital security for many years. Ever since Dr. Mudge's discussion of the subject in his 1995 paper "How to Write Buffer Overflows" (http://www.insecure.org/stf/mudge_buffer_overflow_tutorial.html), the world of computer security has never been the same. Aleph One's 1996 article "Smashing the Stack for Fun and Profit," originally published in Phrack Magazine, Volume 49 (http://www.phrack.com), is also a classic paper detailing how simple the process is for overflowing a buffer. A great site for these references is located at http://destroy.net/machines/security. The easiest overflows to exploit are termed stack-based buffer overruns, denoting the placement of arbitrary code in the CPU execution stack. More recently, so-called heap-based buffer overflows have also become popular, where code is injected into the heap and executed.

Note	See Chapter 11 for more in-depth coverage of buffer overflows, including more recent variants such as heap overflows and integer overruns.

Web server software is no different from any other, and it, too, is potentially vulnerable to the common programming mistakes that are the root cause of buffer overflows. Unfortunately, because of its position on the front lines of most networks, buffer overflows in web server software can be truly devastating, allowing attackers to leapfrog from a simple edge compromise into the heart of an organization with ease. Therefore, we recommend paying particular attention to the attacks in this section because they are the ones to avoid at any cost. We could go on describing buffer overflows in web server platforms for many pages, but to save eyestrain, we'll synopsize a few of the most serious here.

The IIS HTR Chunked Encoding Transfer Heap Overflow vulnerability affects Microsoft IIS 4.0, 5.0, and 5.1. It potentially leads to remote denial of service or remote code execution at the IWAM_ MACHINENAME privilege level. An exploit has been published for this vulnerability at http://packetstormsecurity.nl/0204-exploits/iischeck.pl.

IIS also suffered from buffer overflows in the add-on Indexing Service extension (idq.dll), which could be exploited by sending .ida or .idq requests to a vulnerable server. This vulnerability resulted in the infamous Code Red worm (see http://www.securityfocus.com/bid/2880). Other "oldie but goodie" IIS buffer overflows include the Internet Printing Protocol (IPP) vulnerability (see http://www.eeye.com/html/research/advisories/AD20010501.html) and one of the first serious buffer overflow vulnerabilities identified in a commercial web server, IISHack (see http://www.eeye.com/html/research/advisories/AD20001003.html).

Not to be outdone, open-source web platforms have also suffered from some severe buffer overflow vulnerabilities. The Apache mod_ssl vulnerability (also known as the Slapper worm) affects all versions up to and including Apache 2.0.40 and results in remote code execution at the super-user level. Several published exploits for both Windows and Linux platforms can be found at http://packetstormsecurity.nl, and the CERT advisory can be found at http://www.cert.org/advisories/CA-2002-27.html. Apache also suffered from a vulnerability in the way it handled HTTP requests encoded with chunked encoding that resulted in a worm dubbed "Scalper," which is thought to be the first Apache worm. The Apache Foundation's security bulletin can be found at http://httpd.apache.org/ info /security_bulletin_20020620.txt.

Common Gateway Interface (CGI) was the initial method used by web developers to provide dynamic execution within their web applications. Many early CGI scripts suffered from buffer overflows and were distributed with popular web platforms. The php.cgi 2.0beta10 and earlier distributions of the NCSA HTTPD server are a good example. The problem occurs when attackers pass a large string into the FixFilename () function (which is derived from script parameters) and overwrite the machine's stack, allowing arbitrary code to execute on the vulnerable system. For more information about the buffer overflow vulnerability, check out http://oliver.efri.hr/~crv/security/ bugs /mUNIXes/httpd14.html.

The wwwcount CGI program was a popular web hit counter. The vulnerability and exploit for the script were first made public by plaguez in 1997. The vulnerability allows a remote attacker to remotely execute any code on the local system (as always, as the HTTPD user). At least two sample exploits were made public, but they basically did the same thing: shell back an xterm to the attacker's system. For more information on the vulnerability and a suggested fix, take a look at both http://oliver.efri.hr/~crv/security/bugs/mUNIXes/wwwcount.html and http://oliver.efri.hr/~crv/security/bugs/mUNIXes/wwwcnt2.html.

Typically, the easiest way to counter buffer overflow vulnerabilities is to apply a software patch, preferably from a reliable source. Next, we'll discuss some ways to identify known web server vulnerabilities using available tools.

Web Server Vulnerability Scanners

Feeling a bit overwhelmed by all the web server exploits whizzing by? Wondering how you can identify so many problems without manually combing through hundreds of servers? Fortunately, several tools are available that automate the process of parsing web servers for the myriad vulnerabilities that continue to stream out of the hacking community. Commonly called web vulnerability scanners, these types of tools will scan for dozens of well-known vulnerabilities. Attackers can then use their time more efficiently in exploiting the vulnerabilities found by the tool. Errr, we mean you can use your time more efficiently to patch these problems when they turn up in scans !

Note	See our upcoming discussion of web application security scanners for more up-to-date commercial tools that also analyze web server software.

Nikto

Nikto is a web server scanner that performs comprehensive tests against web servers for multiple known web server vulnerabilities. It can be downloaded from http://www.cirt.net/code/nikto.shtml. The vulnerability signature database is updated frequently to reflect any newly discovered vulnerabilities.

Table 12-1 details the pros and cons of Nikto.

Table 12-1: Pros and Cons of Nikto
Pros	Cons
The scan database can be updated with a simple command.	Does not take IP range as input.
The scan database is in CVS format.You can easily add custom scans.	Does not support files of targets.
Provides SSL support.	Does not perform NTLM Authentication.
Supports HTTP basic host authentication.	Cannot perform checks with cookies.
Provides proxy support with authentication.
Captures cookies from the web server.
Supports nmap output as inputs.
Supports multiple IDS evasion techniques.

Whisker 2.0

Whisker is a web vulnerability scanner with some impressive features. It can be found at http://prdownloads. sourceforge .net/whisker/whisker-2.0.tar.gz?download. Table 12-2 lists the pros and cons of Whisker 2.0.

Table 12-2: Pros and Cons of Whisker 2.0
Pros	Cons
Provides SSL support.	Cannot take a file of target hosts as input. Whisker v1.1 does have this option.
Supports HTTP basic host authentication.	Does not perform NTLM Authentication.
Provides proxy support with authentication.
Has a built-in crawler.
The CGI directory can be redefined from the default (/cgi-bin) to one of your own choosing or to a set of well-known CGI paths.
Before checking for a vulnerability, Whisker will verify that the CGI directory exists and that the CGI itself exists, thus reducing the number of false positives.