IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
      
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks > Security >
developerWorks
'Net threats, Part 1
61KBe-mail it!
Contents:
What went down and when
Into the code we jump (with an offset)
And just to complicate things...
The Code Red effect
Resources
About the author
Rate this article
Related content:
'Net threats, Part 2
On the lookout for dsniff, Part 1
On the lookout for dsniff, Part 2
Tutorial: VPNs, Part 1
Tutorial: VPNs, Part 2
Subscriptions:
dW newsletters
dW Subscription
(CDs and downloads)
Making sense of the Code Red virus

Larry Loeb (larryloeb@prodigy.net)
Author, Secure Electronic Transactions
01 Oct 2001

With recent viruses like Code Red and SirCam causing headaches far and wide, the developer community is taking a long, careful look at how it prepares for such threats. Here in part 1, security ace Larry Loeb analyzes (code and all) how Code Red manages to make so much trouble, while part 2 will examine the havoc wreaked by SirCam.

This past summer was an aggravating one for most computer users. The ever-present security threat from Internet-borne viruses ratcheted up a notch with the Code Red and SirCam infestations. These exploits rubbed a new realization into the noses of the connected community that on the 'Net, one's neighbor's fate could affect one's own situation even if the moat around one's own part of the network was fully stocked with piranha.

What went down and when
Some time lines will be useful in comprehending the gestalt of just what went down during a very confusing time. The context is rather important, for it is in the context you must first look for the significance of the actions that occurred. As my daughter Jaemi reminds me, the logic fault Aristotle identified as post hoc ergo propter hoc (or whatever they called it in Greek) remains as valid today as ever. In English, you translate the Latin phrase as "after this therefore because of this" -- the evident flaw here being that cause may not, in fact, be related to why and when things occur. So in all that follows, please do not assume that just because A happens before B, that A caused B. Things are more complex than that, as we shall see.

On June 18, 2001, a firm named eEye Digital Security published an advisory about a problem that it had found with a widely used commercial off the shelf (COTS) operating system (see Resources). The advisory described a buffer overflow weakness in some detail. Since eEye sells security software designed to prevent and correct the security problems of COTS software, there was some post-mortem grumbling that these guys should have shut up about the flaw, rather than describe it.

Note: I don't buy this viewpoint. The flaw was as they described (as we found out) and eEye didn't write it into the OS. eEye has steadfastly maintained their interest was promoting security awareness through full disclosure. Even if they thought that they might end up selling some of their software to those that suddenly became more security-aware, the validity of exposing problems in a free manner must be upheld. It is an implicit correction mechanism of such importance, magnitude, and necessity that it must always be encouraged. End of tangent.

Sure enough, less than 30 days after eEye went public, a worm appeared using the very buffer overflow exploit eEye described (see Resources for the manufacturer's patch).

Into the code we jump (with an offset)
So, how does this sucker actually work? While the following discussion from the first version of the worm is drawn from the initial postings by eEye and assumes a good knowledge of COTS OS functions, the method of attack is more important than the specifics.

The initial infection starts to take place when a Web server that is vulnerable to the attack is hit with an HTTP GET request that contains the necessary code to exploit the attack and also contains the worm as a payload. EIP is then overwritten with 0x7801CBD3, which is an address within msvcrt.dll. The code at this address disassembles to call ebx. When EIP is overwritten, it then causes program flow to divert back to the stack. The code on the stack jumps into the worm code that's held in the body of the initial HTTP request.

The first code that executes is the worm setting up a new stack for its own use. The new stack is 218h bytes filled with CCh. The worm code then moves on to initialize its function jump table. Note that the entire worm uses an EBP stack-based memory offset system, which means that all variables are referenced as "EBP-X" values.

The worm then references the data portion of the exploit code at EBP-198h. This then sets up its internal function jump table (a stack-based table used to store function addresses). This allows the worm to generate the function addresses at run time, thus giving it a better chance of executing cleanly on more systems.

The technique used by this worm is what is called a Relative Virtual Addresses (RVA) lookup. This means that all functions -- and specifically GetProcAddress -- are found within the affected server program itself. Going through the steps, RVA techniques are used to get the address of GetProcAddress. GetProcAddress is then used to get the address of LoadLibraryA. Between these two functions, all other functions that the worm may need can be easily found.

The worm then checks how many threads of itself (all sharing the same code base) are active, and if the number is greater than 100 the worm goes into a different mode. In this process, the worm also performs a WriteClient (part of the ISAPI Extension API), sending "GET" back to the attacking worm. Ninety-nine of the threads are devoted to attacking other sites, while the 100th does a check of the OS. If it finds a file c:\notworm in its check, it then goes dormant and does not continue on to the site-specific attack.

If the worm finds itself on a Windows 2000 English-language machine, it attempts to do a Web defacement by hooking. Hooking is a technique that spoofs by pointing to a memory resident location instead of the normal TCP connection. The worm modifies w3svc.dll (the IIS core engine) to change the normal operation of TcpSockSend. TcpSockSend is what w3svc.dll uses to send information back to the client. This hook patches what the user sees when a certain Web page is requested. Fortunately, it self-destructs after 10 hours, and the 100th thread then returns w3svc.dll to its original state, including re-protecting memory.

The site-specific attack is simple. First, create a socket and try to connect to http://www.targetedsite.tld on port 80 and send 100KB of data. If this connection is made, the worm then creates a loop that performs 18000h single byte "send ()"s. The worm will now resend itself to any IP addresses to which it can connect via port 80. (And only port 80 right now, but that could change in future incarnations.) It uses multiple "send ()"s so packet traffic may be broken up. On a successful completion of send, it closes the socket and goes back to the beginning of the attack, repeating this loop infinitely.

And just to complicate things...
A similar worm has also appeared that uses the same injection mechanism but substitutes as its payload a Trojan horse that, when installed, gives a remote user full access to the infected system rather than implementing the site-directed Distributed Denial of Service (DDoS) attack. It is usually called Code Red version 2 (CRv2). An analysis of that worm by Marc Maiffret and Ryan Permeh of eEye Digital Security describes the Trojan mechanism in some detail (see Resources).

CRv2 eventually writes the file explorer.exe into the fake directory where it had first put a copy (root.exe) of its cmd.exe. (Just so you know, the fake directories used are Drive:\progra~1\common~1\system\MSADC\root.exe as well as Drive:\inetpub\scripts\root.exe and Drive:\progra~1\common~1\system\MSADC\root.exe.) There is an embedded binary within Crv2 that will also be written out to explorer.exe which has the property that if an embedded byte is 0xFC, it is replaced by 20h 0x00 bytes instead of the regular byte.

Why this file? Well, Windows 2000 has an interesting characteristic that forms the basis for the exploit. When a user logs into the system, the OS has to load explorer.exe (which contains the desktop, task bar, etc.). The OS first looks for it in the main drive path [C:\] which means the trojan explorer.exe is going to be loaded the next time a user logs in. This keeps the system trojaned every time it boots. Pretty nasty, huh?

Wait, it gets better. One of the effects of the trojan is to create a virtual Web path (/c and /d) that maps /c to c:\ and /d to d:\. Note that the writer of this worm designed this routine to allow for a backdoor to be placed on the victim system. Thus, even if you remove the root.exe (the cmd.exe prompt) from the local/scripts folder, an attacker can still use the /c and /d virtual roots to compromise your system. As long as the trojan explorer.exe is running, an attacker can remotely access the server.

The attacks would most likely look something like these:

  • http://IpAddress/c/inetpub/scripts/root.exe?/c+dir (if root.exe was still there) or
  • http://IpAddress/c/winnt/system32/cmd.exe?/c+dir (where dir could be any command an attacker would want to execute).

The Code Red effect
The initial rate of propagation of CRv1 scared the bewillikers out of the 'Net guardians. Unchecked, it could (and did) take down networks as it infected and directed the DDoS attack. Even if you patched your server software (or ran on something that wasn't directly affected by the worm) you felt its nasty effects. You got scanned like crazy from infected servers, which took up system bandwidth unnecessarily. Resources on the 'Net unexpectedly became unavailable for use. If you used the 'Net for important but not mission-critical data exchange in your business, you got hosed for a few days. In addition, the doggone networked HP laser printers started acting funny because of Red's "sort of random" network accesses.

Red also nailed Cisco routers and software big time. As Cisco put it:

"Side-effects caused by the worm can expose unrelated problems on other products. When the traffic from the worm reaches a significant level, a Cisco CSS 11000 series Content Service Switch may suffer a memory allocation error that leads to memory corruption and will require a reboot. Traffic from the worm can trigger a defect in the IP/VC 3510 Videoconference Multipoint Control Unit and Cisco Aironet Wireless devices. As a separate side effect, the worm [...] causes Cisco 600 series DSL routers to stop forwarding traffic." (see Resources)

That little choking alluded to by Cisco was responsible for taking down the Qwest DSL service (which used Cisco 600 routers), affecting many of its customers as well as others who relied on Qwest to forward 'Net traffic bound for their systems. One of the many things that made Red so toxic was that not only would it mess up PCs and networks, but it would go after infrastructure as well -- a second level of slime, so to speak.

But not to worry. Cisco put up a Web page to help you figure out your problems (see Resources). Of course, if you couldn't get to the 'Net because your router was hosed, this effort appeared to be less than satisfactory. It's taken a bit of time, but Qwest is now distributing a Cisco CBOS upgrade (also -- sigh -- distributed via the Internet) to its users that Qwest says will fix the problem.

Infecting users is one thing. Hosing routers and laser printers is another. Red was more than a delivery mechanism -- It was just short of a biblical plague. According to the Netcraft Web server survey (see Resources), as of October 1, 2001, more than 80,000 IIS servers and 150,000 Web sites have been pulled from the 'Net because of this worm and its antecedents. It was just too much for some ISPs to deal with.

Since Red is date-based in attack (infect, then sleep until a date when it's likely that lots of machines have been affected, at which point they will be acting in concert), the 'Net cops issued a large warning to the community just before the second wave of attacks was expected. The reaction was not pretty. Hype abounded, as this worm drove Congressman Condit off CNN for a moment.

But after the clock ticked past the zero hour ... nothing happened. The data sinkhole didn't appear. The Internet did not melt down (not yet, anyway). FBI's National Infrastructure Protection Center (NIPC) finally issued a bulletin stating somewhat sheepishly that "the Internet threat posed by Code Red when it changes from a scanning mode to an active distributed denial of service (DDoS) mode at 8pm (EDT) on August 19, 2001 is significantly reduced."

Sure, the major ISPs cracked down and eliminated access to port 80 for everyone. That caused major inconvenience if you were hosted by one of them, no doubt. But closing 80 (Red's only vector of propagating) seemed to mitigate the infection cycle. It hasn't eliminated Red, though. Everyone has to do that themselves on their own machine with one of the free tools that have appeared lately. Whether or not Red is killed or becomes another chronic noise-level over the 'Net will be decided by how many hosts patch themselves, but (surprise finish!) Red didn't cause the loss of 'Net resources so scaring the admins during the first wave of attacks.

Around the same time as Crv1, there was a railroad tunnel fire in Baltimore, that lasted for five days and physically melted one of the major pipes of the Internet. That was the root cause of the 'Net problems -- the breakdown of a physical link. Red just made it somewhat worse at the same time. Thank you, Mr. Aristotle.

Little did we know that as bad as Red was and is, it was just the warm-up. More on this in the upcoming part 2 of this series.

Resources

  • eEye Digital Security published an advisory about a problem that it had found with a widely used Commercial Off The Shelf (COTS) operating system.

  • Get the manufacturer's patch for the buffer overflow weakness.

  • An analysis of Code Red version 2 (CRv2) by Marc Maiffret and Ryan Permeh of eEye Digital Security describes the Trojan mechanism in some detail.

  • Cisco posted a Web page that gives details on how the Code Red virus works, as well as a security advisory that describes how Code Red affects specific Cisco products.

  • According to the Netcraft Web server survey, as of October 1, 2001, more than 80,000 IIS servers and 150,000 Web sites have been pulled from the Internet because of Code Red and its antecedents.

  • Find out the latest security-related news and product information at IBM's security site.

  • IBM security services can help you determine what your risks are, and then design a security program to address them.

About the author
Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been -- among other things -- a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX, and the VARBusiness Exchange. He's also written a book on the Secure Electronic Transaction Internet protocol. His first Mac had 128K of memory. His first 1130 had 4K, as did his first 1401. You can e-mail him at larryloeb@prodigy.net.


61KBe-mail it!
Rate this article

This content was helpful to me:

Strongly disagree (1)Disagree (2)Neutral (3)Agree (4)Strongly agree (5)

Comments?



developerWorks > Security >
developerWorks
  About IBM  |  Privacy  |  Terms of use  |  Contact