 |
|
||||
|
|||||
|
|||||
|
|
|||||
|
|
|
|
||||||||||||||
|
||||||||||||||||
|
|
| ||||
| 'Net threats, Part 1 | |   | |
| ||||
| ||||
| Making sense of the Code Red virus
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 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) 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 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 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 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... 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:
The Code Red effect 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.
| | |||||||||||||
 |
| About IBM | Privacy | Terms of use | Contact |
