7.1. Web Server Attacks

Sometimes your web server is the specific target of an attack because of who your organization is or what it represents. Sometimes people hack your web server for the same reason they climb a mountain: because it's there. Web server attackers often want:

• To embarrass or discredit an organization

• To earn respect among hackers by indiscriminately vandalizing a site

• To gain a foothold in the organization's network for deeper penetration at a later time

• To leverage the server in malicious activity against another network

• To try to obtain sensitive or confidential data

• To simply deny your server the ability to serve its pages

Web site defacement has obvious repercussions. It is easy to imagine the embarrassment of a high-profile company when their web site is defaced. Sometimes hackers hack a web site to express an opposing viewpoint right from the site they oppose. Such vandalism is only likely on your site if your organization is associated with one side of a controversial issue. Of course, there are innumerable electronic vandals who vandalize for the sake of vandalizing.

Some hackers will attack your web server with a goal of using it illicitly in some other activity. They may want to put their cracked, illegal copies of software there for people to download. They may want to set your web server up as a node in a distributed denial of service (DDoS) attack. They might even be so lucky (and you might be so unlucky) that they get interactive access (i.e., shell access) on your web server. Then they may merely pass through, using you as one more hop in a long chain of logins that help obscure their origins.

Web servers are often located in the network's DMZ, making them natural first steps for breaking into an organization's network. Broken routers or firewalls would be even better entry points, but they tend to be more tightly controlled than the web server. An attacker knows he will always have access to port 80 on the target system.

7.1.1. Why You Care

The direct effects of hacking a web server may seem benign. In actuality, they can have a surprisingly abrupt and negative impact. Hackers who put illegal software on your web site and then share the location among their friends may suddenly and completely consume available resources on both your system and your network. Your server may fail under the load, or your organization may receive a surprisingly large bill for excess bandwidth usage. If your Internet service provider (ISP) is notified that your server is a participant in a DDoS attack, they may choose to "shoot first, ask questions later" and remove your server's connectivity to the Internet. If your web server shares your organization's primary (or only) link to the Internet, you may find your whole company unceremoniously disconnected while you and the ISP sort out what is wrong. Lastly, some sites that are the targets of DDoS attacks respond with "counterattacks." Your web server or network could be targeted by some form of electronic retribution.

Many web servers perform one or more e-commerce functions. Perhaps they handle the storefront; maybe they're the shopping cart server; or they might allow customers to get shipping information on orders they've already placed. Even if all the web site's transaction processing is ultimately handled in a secure data center, the web server stores the data momentarily. A hacker who can break in and monitor communications or data flow has an opportunity to capture personal information, user IDs and passwords, or perhaps even credit card information. If you are running a commercial web server, these risks are probably foremost in your mind. The only thing more fearsome than a CIO asking about an enormous bandwidth bill is a CEO who must notify customers that their credit card information is now in the hands of Eastern European hackers.

The recently passed Notice of Security Breach sections of the California Civil Code (California Civil Code Sections 1798.29 and 1798.82-1798.84, http://www.privacy.ca.gov/code/cc1798.291798.82.htm) have broad effects for organizations handling personal information in the United States. If "unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person," then the person must be notified. This law is very new and has not yet been vigorously tested in the courts. It probably applies to organizations incorporated in California. It may apply to organizations that merely do business in California. While there remains a lot of uncertainty about how broadly it applies, it certainly creates legal fear and uncertainty for web sites that deal with personal information. Even though your web site only deals in name and addresses, you could find yourself being compelled by law to notify users that their names and addresses were possibly compromised. No organization wants to be compelled to broadcast the fact that they have successfully been hacked.

7.1.2. Specific Threats to Web Servers

The kinds of general risks we've described typically materialize through specific technical mechanisms. These include file or data disclosure, file uploads or storage, program execution, operating system vulnerability exploitation (e.g., privilege escalation), and web server vulnerability exploitation (e.g., buffer overflow).

7.1.2.1 File and data disclosure

File and data disclosure were among the earliest kinds of attacks on web servers. Both Apache and Microsoft's Internet Information Server (IIS) were subject to a variety of directory traversal attacks. Two standard encodings, HTML entity encoding and HTTP URL encoding, are often combined in unexpected ways to cause the web server to do unusual things. You've probably seen ampersands (&) encoded in HTML as &. That's HTML entity encoding, and it represents characters with an ampersand, their decimal (or hexadecimal) ASCII value, and then a semicolon. It can represent the whole character set, though, including 2-byte UNICODE characters. For example, the letter "A" can be represented A. Similarly, you've probably seen spaces encoded in URLs as %20. That's an example of a totally different encoding: HTTP URL encoding. It allows web pages to encode non-alphanumeric characters in URLs using a percent sign and the character's 2-digit ASCII hexadecimal value. Again, you can represent more than just punctuation. The letter "A" can be encoded as %41. These encodings were intended to handle non-alphanumeric characters such as those with accents or whitespace such as spaces and tabs. Hackers exploit these encodings in a variety of ways to construct obscured paths that bypass security checks. For instance, they can encode /etc/passwd as %2F%65%74%63%2F%70%61%73%73%77%64. The earliest versions of many web servers would fail to notice, after decoding the string, that the file requested lived outside the web server's document root. Even today complex variations on this theme crop up from time to time as part of attacks on modern web applications.

File downloads are not the only problem you will face. Uploads can be a problem when they allow hackers to store data on your server that they, or someone else, will come retrieve later. Hackers probably won't fill your hard disk with junk. They might, however, upload a few gigabytes of MP3s, a few hundred megabytes of software whose licensing protections have been disabled, or perhaps some illegal pornography. You might find your web server suddenly attracting a lot of unwanted attention, both from hackers and from law enforcement.

File uploads can also destroy useful data. If a hacker can upload and overwrite important files, such as web orders that have not been transmitted to the fulfillment system yet, it may also cause your organization to lose money or information.

Lastly, uploads can be a critical step in compromising the server's security. If a hacker can upload a program to your web server and somehow trick the web server into executing it, she can go a long way toward defeating security measures.

7.1.2.2 Arbitrary program execution

Arbitrary program execution is the ultimate vulnerability in any server software. If a hacker can find a way to execute a program of his choosing on your web server and control some of the arguments to that program, then he can usually escalate into a variety of other attacks. He might use a CGI script or some PHP code, for example, to upload a program onto your server that is subsequently executed. He might merely abuse a program that already lives on your server but has vulnerabilities. Suddenly, a locally exploitable vulnerability in the line printer spooler daemon (lpd(8)) that seemed inconsequential is suddenly a very important threat. It can allow an intruder to escalate privileges and gain access to your web server without having direct local access.

7.1.2.3 Application abuse

There are a variety of other attacks against web servers that cannot be mitigated at the operating system level. Attacks such as SQL code injection, HTML injection, and cross-site scripting (XSS) are critical attacks to prevent. This is an important point that we cannot stress enough: the network and the operating system cannot fully compensate for bad applications. They can help, but they cannot obviate the need for careful, security-conscious programming. Despite being important, these attacks are outside the scope of this book because they exploit neither the web server software nor the host operating system. An example will help illustrate this point, and then we will move on.

Web sites often offer a form where a person can type a message, enter his email address, and click a button to send a message to someone associated with the web site. These "contact us" pages are usually for submitting feedback on the web site, contacting the sales department, or reporting a problem with a product. There are a variety of freeware and shareware CGI programs available for downloading that will do the necessary web-to-email processing. One notorious example, formmail.pl, has been repeatedly abused to send email from arbitrary senders to arbitrary recipients with arbitrary message content. If you aren't using this script but still see errors in your web server's log where someone has requested /cgi-bin/formmail.pl, you're probably looking at an exploit attempt. Spammers love to find vulnerable applications like this one.

For a more detailed example of these formmail.pl vulnerabilities and exploits, see the Section 6.1.2 in Chapter 6.

As an administrator there are only so many things you can harden and configure to prevent abuse of your server. The firewalls, routers, web server software, and operating system are all very important. All is for naught, however, if badly written applications are blindly allowed to run on the web server.