Understanding the Internet Information Server Situation
- A Catalog of Woes, Bad Defaults, and Vulnerabilities
- What About Server .NET and IIS 6.0?
- Living with IIS (Never Mind Which Version)
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You can say what you like about Microsoft's greedy, grasping, and perhaps even monopolistic ways in today's software and operating systems marketplace. But nobody can deny that Microsoft has also been a pioneer in that marketplace and has done more than simply occupy a dominant position in the software world.
For example, when Microsoft shipped Windows NT 4.0 in August 1996, it was the first major systems company to include ("bundle" if you like the marketing term) a Web server along with the core operating system it offered for sale. Prior to that time, the only options were to adopt Open Source implementations like Apache (which had already become the most popular Web server on the Internet by April 1996, and retains that coveted spot to this day) or the EMWAC (European Microsoft Windows NT Academic Center) shareware HTTP server, or to purchase commercial Web servers from companies like Frontier Technologies, O'Reilly & Associates, Questar Microsystems, or Netscape.
While it's true that IIS has had its share of problems and faults - many of them security related - it's also true that Microsoft's inclusion of IIS with Windows NT and later operating systems has helped to make the Web as ubiquitous and pervasive as it is today. Netcraft's October 2001 survey also shows that IIS usage has grown significantly since its introduction in 1996. Today, IIS is the second most popular Web server on the Internet, with a 28.99 percentage share (as compared to the leading Web server, Apache at 56.89 percent; iPlanet is next in the rankings with a miniscule 3.86 percent share).
Alas, IIS has been implicated in a rash of security-related issues over the years, and has earned a reputation as a useful but shaky Windows component. Then, in September 2001, highly regarded industry analysts and Windows watchers inside the Gartner Group recommended that organizations using IIS consider switching to less vulnerable Web servers such as those from Apache, iPlanet, and others. The upshot has been a huge debate in the industry about IIS that might be summed up in the following statements:
- Is IIS any good at all?
- What factors might prevent such a switch?
- How much will switching cost?
Interestingly enough, this debate has calmed down considerably since September. Further investigation of available alternatives has shown that while IIS may be more vulnerable to security threats or compromise than other Web servers, none of them is perfect in this regard. More important, many companies and organizations who have built complex sites around IIS also rely on Microsoft tools, programming interfaces, and facilities that can't simply be picked up and moved over into some other Web server environment. In other words, those who have invested heavily in building highly interactive, powerful websites around IIS, ISAPI, ASP, and other Microsoft technologies might have to rebuild their sites from scratch were they to move to another platform.
The preceding paragraph answers the previous second and third questions directly (loss of Microsoft tools, interfaces, and related development investments is why a switch might be prevented, and in at least some case switching simply costs "too much"). Paying serious attention to maintaining the best possible security around IIS helps mitigate most exposures, and careful coding and testing practices can eliminate most obvious threats. Read on to see what IIS has brought to the Internet over the years, in addition to access to Web pages, graphics, multimedia files, services, and so forth.
A Catalog of Woes, Bad Defaults, and Vulnerabilities
Since its release in August 1996, IIS has certainly been the subject of a fair number of Microsoft and third-party security alerts. In the 38 months since the release of the first security bulletin for IIS 4.0 in June 1998, that version of ISS has been the focus of 37 security bulletins, of which at least 4 represent cumulative patch and hotfix rollups (to make it easier to "get safe" with the product in one go). In the 23 months since the release of the first security bulletin for IIS 5.0 in January 2000, that version has been the focus of 22 security bulletins, including 2 cumulative roll-ups. And although the time frame may not be long enough to make my claim statistically significant, this looks like a steady once-monthly average for security bloopers, vulnerabilities, gotchas, or other problems for either version of the product.
As somebody who routinely monitors Microsoft and third party security bulletins anyway, this one per month rate for security fixes is among the highest in the Microsoft family of systems and applications. Nevertheless, this regular pace of updates and fixes for IIS hasn't made keeping our public or private servers up with critical updates impossible, nor too terribly labor-intensive. While it's possible to make the argument that things shouldn't be this "bad," from the perspective of living with the realities it imposes - as long as you make a policy of keeping up with the news about possible exposures and apply related updates - working with IIS is not an impossible job.
That said, here's an abbreviated catalog of the kinds of problems that IIS has been prey to in both versions 4.0 and 5.0:
Unchecked buffer problems of various kinds, including Index Server searches, Index Server ISAPI extensions, URL formulations, and file download requests (with commands appended after legitimate filenames).
When ISAPI handles non-.HTR files as if they were of that type, contents can sometimes be accessed; likewise certain specialized HTTP headers can provoke display of (otherwise invisible) ISAPI source code.
Numerous instances of cross-site scripting (CSS) issues, where a website fails to filter script input (and can therefore be attacked with scripts from an intermediate site between the end-user and the target site).
Without proper controls on the default IIS anonymous user account (which takes the form IUSR_machinename), it's possible for that account to access volumes and directories outside the IIS container (because all accounts are part of the Everyone group, and because Windows gives the all-embracing Everyone group Full Control access rights over new volumes and folders by default).
Almost none of these vulnerabilities enable the kind of access necessary to establish a beachhead on a compromised machine. None of them provides a set of instant keys to administrator level access. But all of them, in the hands of a patient knowledgeable cracker, can lead to serious damage (especially from file deletion) or system compromise.
Thus, it's clear that keeping up with exploits and vulnerabilities, and applying patches and fixes as soon as they're available, has to be part and parcel of an IIS administrator's regular routine. To mitigate this situation, and improve on current conditions, Microsoft has promised to make some significant changes with the next release of IIS, version 6.0, scheduled for inclusion with Server .NET, itself scheduled for release in the June-August 2002, time frame. Read on to learn more about what Microsoft plans to do to clean up its Web server security act.