Chapter 9: Introducing IIS 7

Windows Vista introduces Internet Information Service (IIS) 7, built on Microsoft's highly successful IIS 6 product. After over four years (IIS 6 was released in March 2003 along with Windows Server 2003), IIS 6 remains without a single significant security blemish. IIS 7 was created to be even more secure. This chapter covers web server threats, introduces the new features and changes of IIS 7, and concludes with the ways to harden an IIS 7 server.

Note 

IIS 7 is secure by default. This chapter's recommendations provide additional hardening steps applicable to any environment to make it even tougher to hack a web server. IIS 7 was specifically designed to be tough enough to serve as any type of web server, whether used internally as an intranet site or as an externally facing Internet-accessible web server. This chapter will cover hardening steps that can secure both types. However, IIS 7's original presence on Windows Vista, an end-user client OS, indicates that Microsoft intended IIS 7 to initially lean more toward intranet use.

Web Server Threats

Web servers contain many pieces and parts, including the host OS, web protocols, back-end databases, and the web server software itself. This collection of related components coupled with inviting inbound Internet connectivity makes web servers a frequent hacker target. Threats to web servers include the following:

• Application vulnerabilities

• OS vulnerabilities

• Back-end database issues

• Protocol vulnerabilities

• Buffer overflows

• Directory traversal attacks

• Sniffing attacks

• Denial of service

• Password-guessing attacks

Each of those threat types is covered in slightly more detail in the material that follows.

Application Vulnerabilities

Application vulnerabilities account for the vast majority of web server attacks. OS and web server vendors have worked hard to make their products less exploitable but, in general, application developers tend to be under trained in security. To be fair, most managers are more focused on delivering applications on time than with developing and testing the security defense of the application against some "theoretical" attack.

Note 

When hiring a PHP programmer, I asked every one of the two dozens candidates what they did to ensure that the PHP code that they wrote or borrowed did not contain security vulnerabilities. To a person, all claimed to be unaware that PHP had any security issues. Only one candidate even seemed interested in the subject. He got the job. This is a real-world example of why web applications continue to be the most frequent target of hackers.

Application vulnerabilities are often caused by incorrect permission setting, scripting errors, design faults, inadequate input parameter checking, and by coding errors in general.

No software programmer is perfect. All programmers make design or coding errors. It's a factor of being human. Coding errors are often measured in bugs per thousands of lines of code (or bugs per kloc). The average number of bugs per kloc for a programmer is thought to be between 50–150/kloc, according to several studies. One study (http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/watts-new-2004-3.htm) of 800 industrial programmers revealed in a 120 bugs/kloc average. The top 1 percent most accurate coders had 11 bugs/kloc.

Microsoft has worked hard to reduce the number of bugs through better programmer training, manual and automated code review, and financial incentives. According to David LeBlanc, Senior Software Development Engineer in the Office Division of Microsoft, the results are paying off. Microsoft believes their core programmers program to a 5 bugs/kloc standard, the best of any large company. Of course, Windows Vista contains over 50,000,000 lines of code. If you assume 5 bugs/kloc average, it means Vista could be estimated to have 250,000 programming bugs. Still, most of them are not security issues. They are more likely to be reliability and user-friendliness issues.

Proof of Microsoft's software quality engineering processes is that IIS 6 has had only three known bugs (as of April 2007) since its release in March 2003, and neither was used a lot in the wild. Microsoft SQL, often paired with IIS, hasn't had a major exploit since the SQL Slammer worm in April 2003, and even that bug had been patched for over six months before the worm got out.

OS Vulnerabilities

All web server software runs on top of a host operating system. Accordingly, any successful attack against the underlying host OS is a successful attack against the web server. With the notable exception of OpenBSD (http://www.openbsd.org) every host OS has multiple vulnerabilities, including Windows. A web developer must take great care in hardening the underlying OS to minimize overall vulnerabilities.

Back-End Database Issues

Back-end databases, such as MS-SQL, MySQL, PostGres, and Oracle, are frequently the targets of intruder attacks because they often directly interface with front-end web servers. Although MS-SQL hasn't had a major system vulnerability in over three years, many other database suites, including Oracle and MySQL, have.

More often, application-level vulnerabilities (SQL injection attacks, scripting subsystem holes, and so on) allow the attacker to compromise the back-end database server and then use the data connection to compromise the web server.

Protocol Vulnerabilities

Web servers use a number of network, transport, and session protocols. The two most popular protocols used are Hypertext Transfer Protocol (HTTP) and HTTP over SSL (HTTPS). However, it would not be an exaggeration to say that a web server can utilize dozens of other protocols (and file formats) to serve up a standard application. Each protocol and the subsystem that interacts with the client is a potential attack vector.

Even when the protocol doesn't have known public vulnerabilities, web developers can implement them insecurely. It is not uncommon for Web sites claiming to have HTTPS encryption and authentication to send all resulting data streams in clear-text and unauthenticated.

Note 

I have often seen this mistake on some of the Web's most popular banking and financial Web sites.

Buffer Overflows

Like any input-accepting application, web server software can be buffer overflowed. The most famous IIS buffer overflow was the Code Red worm of July 2001 (http://www.cert.org/advisories/CA-2001-19.html). Affecting IIS versions 4 and 5, its worldwide spread led to a major loss of consumer confidence in IIS. Microsoft responded by making the next release of IIS one of its most secure products in history. In over four years, only three holes have been found, none of which were used widespread.

The last one of those vulnerabilities (as of the book's publication date) was a buffer overflow exploit in July 2006 (http://www.microsoft.com/technet/security/Bulletin/MS06-034.mspx). IIS purists don't consider this an IIS buffer overflow because the exploit is located in the potentially separate ASP.NET subsystem. However, both products are made by Microsoft and are meant to be run together, although ASP.NET is not installed by default in IIS 6 unless intentionally enabled. Either way, it was not popularly exploited. Apache 2.0 web server, a popular open source web server, has had 4 buffer overflow vulnerabilities (out of 33 total known vulnerabilities) in roughly the same time period. Buffer overflows are a potential problem for all web servers.

Note 

IIS's main executable, Inetinfo.exe, is protected by Data Execution Prevention (DEP), which will defeat many common buffer overflow attacks.

Directory Traversal Attacks

Directory traversal is an attack method in which the intruder uses malformed (or unexpected) input to "jump" out of the drive folder containing the web server program or application into more privileged areas. For instance, the default location for IIS application files is %Systemroot%\inetpub\wwwroot. A directory traversal attack would attempt to break out of the wwwroot folder into the root directory, \Windows, or \Windows\System32, where unauthorized access can be more successful and fruitful. Directory traversal attacks normally contain strings of characters (for example, http://../../../../../../../../) that attempt to confuse the web server into offering up an unauthorized default directory outside the normal web server boundary (see Figure 9-1). The attack allows the intruder to traverse various directories, go up to the root, and then back down into the drive's directory structure to execute contained commands.

Figure 9-1: Representative example of a directory traversal attack

Although IIS has not experienced a successful directory traversal attack in many years, such attacks used to be a frequent method of exploitation in the days of Windows NT and IIS 4.

Sniffing Attacks

Unless the Web site uses HTTPS, the traffic to and from the web server is often sent in plain text. If the attacker can intercept the network streams, information can be sniffed and analyzed. Figure 9-2 shows a login name and password sniff from an HTTP session. Many users do not realize how frequently their confidential information is transmitted in clear text across the Internet.

Figure 9-2: Example of clear text password caught in HTTP traffic

Denial of Service

Denial of service (DoS) attacks have been a big threat to web servers. Attackers, using armies of compromised machines, can send millions of rogue packets per second to a web server, denying legitimate access and business. DoS attacks are among the most popular attacks against popular, commercial web servers, and are rather difficult to prevent. Indeed, in some sense, they are impossible to prevent, as every communication begins with a request that causes a response. If an attacker can cause more malicious requests to come in than the host machine can adequately respond to, a DoS attack occurs. With the rise of botnets, networks of computers exploited and controlled by hackers, Distributed denial of service (DDoS) attacks make it possible for attackers to bring down even sites with large bandwidth pipes.

Many Web sites, especially gambling and pornography sites, which make tens of thousands to millions of dollars a day from online customers, have been extorted by cyber criminals to pay up to $100,000 to avoid getting a targeted DoS attack. These Web sites find it cheaper to pay the ransom than to lose the business that would result from the DoS. While many security companies are developing better anti-DoS capabilities to protect popular Web sites, the default anonymous nature of the Internet makes stopping DoS attacks difficult. Microsoft has responded by intentionally hardening the Windows TCP/IP network stack against specific types of DoS attacks, improving IIS's performance under heavy loads, and in setting performance thresholds.

Password Guessing Attacks

Many web servers are compromised because the administrators configure them with weak passwords. Most web servers contain either HTML-enabled logon screens or remote admin consoles. Attackers can often guess against these logon prompts using automated password guessing tools (such as Hydra) or by using manual methods. Even moderately complex passwords (for example, eight characters with multiple character sets) can be guessed by an attacker given enough time. Unfortunately, many web administrators don't even attempt to use long or complex passwords, so guessing the correct admin password doesn't take a significant amount of effort.

A great discussion of web server vulnerabilities is maintained at Open Web Application Security Project (OWASP) at http://www.owasp.org. Their top ten web server security errors list (http://www.owasp.org/index.php/OWASP_Top_Ten_Project) is a great list to review. While the list is terrific, it's depressing to see that the list hasn't changed much over the years, and it appears we are no closer to better securing web servers than we were in January 2003 (when the OWASP top ten list was first released). The next two sections will introduce IIS in general and then discuss the new features of IIS 7.