eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Microsoft on May 24 concluded an investigation into a potential IIS 6.0 flaw that researchers said may lead to a denial of service attack and which researchers said “definitely” allows attackers to access special DOS devices (COM1 in this case).
The verdict: The claims are wrong, the public proof of concept code doesnt take advantage of an IIS 6.0 vulnerability, and the code in question, although it claims to use IIS 6.0, actually uses ASP.NET.
Posters on the BugTraq mailing list maintained that the flaw could be used to read data from a device attached to COM1—a PCs first serial port. The flaw can also prevent another application from accessing the port, since access to ports is exclusive, according to a poster with the handle “3APA3A.”
IIS 6.0 is the current shipping version of the Internet Information Services Server for Windows Server 2003. Microsoft is up to IIS 7.0 for Windows Vista and IIS 5.1 for Windows XP Professional.
The potential flaw was first brought up on BugTraq by a member with the handle “Kingcope.” Kingcope said that he or she recently found a small bug in IIS 6.0 when requesting a special path.
“When I request /AUX/.aspx the server takes a bit longer to respond as normally. So I did write an automated script to see what happens if I request this file several times at once. The result is that some servers on the Internet get quite instable, some do not. On some servers after I stop the attack I get an exception that the Server is too busy/Unhandled Exception on the wwwroot (/) path,” Kingcope wrote.
3APA3A also reported that the suspected vulnerability can be exploited “as a local unauthorized access or privilege escalation, to execute user-supplied .aspx script from COM port (via serial cable) without having console access with permissions of Web application.”
According to a Microsoft spokesperson, the code in question actually uses ASP.NET, and even there it only affects older systems in a minor way. “Our investigation has shown that the code has no impact against systems running ASP.NET 2.0. Systems running ASP.NET 1.1 may experience a temporary disruption when receiving a large volume of concurrent requests containing this code. However, as soon as the requests are no longer submitted, the system returns to normal operation,” the spokesperson said in an e-mail exchange.
Early versions of IIS were responsible for some whoppers when it comes to vulnerabilities. In 2001, the Code Red worm took advantage of the so-called .ida flaw in IIS, which hit more than 300,000 servers in July alone (even though Microsoft shipped a patch the month before).
IIS 6.0 has fared much better: Between 2003 and 2007, only three flaws have been found, none of which were deemed critical and all of which have since been addressed. Microsoft had, in fact, addressed the causes of many of the vulnerabilities in IIS 4.0 and 5.0 when it got to 6.0.
With 6.0, the server installs in lock-down mode, limiting the attack surface.
“When you install IIS 6.0, it is locked down—only request handling for static Web pages is enabled, and only the World Wide Web Publishing Service [WWW service] is installed. None of the features that sit on top of IIS are turned on by default, including ASP, ASP.NET, CGI scripting, FrontPage® 2002 Server Extensions from Microsoft, and Web Distributed Authoring and Versioning (WebDAV).
“This locked-down state minimizes the attack surface that is available to intruders, who sometimes target computers by attacking services that are running but that are unused. These attacks can happen if, for example, an administrator forgets to turn off an unused service, and then to maintain it with current hotfixes, service packs, and security updates. Over time, the service might become increasingly vulnerable to attackers,” Microsoft wrote on its TechNet site at the time.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.