How Code Red revealed the perils of port 80

AnchorDesk

How Code Red revealed the perils of port 80

Stephan Somogyi and Bruce Schneier
Contributing Columnists, AnchorD
Tuesday, October 2, 2001

Add your opinion

Forward in

Format for

In the few months that the Code Red worm and its relatives have traveled the Net, they've caused considerable consternation among users of Microsoft's Internet Information Server (IIS) and elicited abundant schadenfreude from unaffected onlookers.

Despite the limited havoc it wrought, the Code Red family highlights a much more pernicious problem: the vulnerability of embedded devices with IP addresses, particularly those with built-in Web servers.

THUS FAR, the Code Red worms work their way through self-generated lists of IP addresses and contact each address's port 80, the standard HTTP port. If a server answers, the worm sends an HTTP request that forces a buffer overflow on unpatched IIS servers, compromising the entire computer.

Any effect that these worms have on other devices that listen on port 80 appears to be unintended. Cisco has admitted that some of its DSL routers are susceptible to denial-of-service attacks; when affected routers' embedded Web servers are contacted by Code Red, the router goes down. HP print servers and 3Com LAN modems seem to be similarly affected; other network-infrastructure hardware has likely suffered, too.

HTTP has become the lingua franca of the Internet. Since Web browsers are ubiquitous, many hardware and software companies can't resist making their products' functions visible--and often controllable--from any Web browser.

INDEED, it almost seems as if all future devices on the Net will be listening on port 80. This increasing reliance on network-accessible gadgetry will return to haunt us; Code Red is only a harbinger.

Sony cryptically announced in April that it would endow all future products with IP addresses--a technically implausible claim, but nonetheless a clear statement of intent. Car vendors are experimenting with wirelessly accessible cars that can be interrogated and controlled from a Web browser.

The possibilities for nearly untraceable shenanigans perpetrated by the script kiddie next door after working out your car's password are endless. This problem won't be solved by encrypting the Web traffic between car and browser, either.

THE RISE OF HTTP as a communications common denominator comes from ease of use, for programmer and customer alike. All customers need is a Web browser and the device's IP address, and they're set. Creating a lightweight server is trivial for developers, especially since both in- and outbound HTTP data is text.

Even more attractive, HTTP traffic is usually allowed through firewalls and other network traffic barriers. Numerous non-HTTP protocols are tunneled via HTTP in order to ease their passage.

But HTTP isn't the miscreant. The problem is created by the companies that embed network servers into products without making them sufficiently robust. Bulletproof design and implementation of software--especially network software--in embedded devices is no longer an engineering luxury. Customer expectation of reliability for turnkey gadgets is higher than that for PC-based systems. The successful infiltration of the Code Red worms well after the alarm was sounded is eloquent proof that getting it right the first time has become imperative.

GIVEN THE EASE of implementation and small code size of a lightweight Web server, it's particularly disturbing that such software isn't engineered with greater care. Common errors that cause vulnerabilities--buffer overflows, poor handling of unexpected types and amounts of data--are well understood.

Unfortunately, features still seem to be valued more highly among manufacturers than reliability. Until that changes, Code Red and its ilk will continue unabated.

One example of doing it right is the OpenBSD project, whose developers have audited its kernel source code since the mid-1990s, and have discovered numerous vulnerabilities--such as buffer overflows--before they were exploited.

SUCH PROACTIVE manual scrutiny of code is labor intensive and requires great attention to detail, but its efficacy is irrefutable. OpenBSD's security track record--no remotely exploitable vulnerabilities found in the past four years--speaks for itself.

Like sheep, companies and customers have been led along the path of least resistance by the duplicitous guide called convenience. HTTP is easy: easy to implement, easy to use, and easy to co-opt. With a little diligence and forethought, it is also easy to secure, as are other means of remote network access. HTTP wasn't originally designed to be all things to all applications, but its simplicity has made it an understandable favorite.

But with this simplicity also comes the responsibility on the part of its implementers to make sure it's not abused.

Bruce Schneier is CTO of Counterpane Internet Security. Stephan Somogyi is a frequent contributor to AnchorDesk.

What do you think should be done about the perils of port 80? TalkBack to me.

Special sponsor stores

Dell Home

Disaster Recovery
Many companies still ill-prepared for disasters Read the study at TechRepublic
10 items for your disaster recovery wish list We all have to address disaster recovery (DR) at various levels, but we typically must apply the technology to fit rigid parameters. But what if you didn't have any limitations to hold you back? Read the post at TechRepublic
From our sponsors
Disaster Preparedness
How to Develop a Business Continuity Plan Review a five step process to develop a comprehensive business continuity plan Click here to find out more!