Did the FBI ignore 'Code Red' warning?
By Kim Zetter
(IDG) -- The "Code Red" threat seems to have finally halted its malicious crawl, but the security company that discovered the vulnerability that Code Red exploits says the swift-moving Internet worm might have been immobilized much sooner if not for federal agencies' caution about publicizing security threats.
The worm hit more than 700,000 computers in July and August 2001, depositing a Trojan horse program on infected machines, which then simultaneously attacked a specific Internet Protocol address (initially, the White House Web site). The volume of messages slowed Internet traffic in general.
Now, details about an earlier Code Red-like worm that hit systems back in February 2001 are raising questions about the Federal Bureau of Investigation's handling of computer virus outbreaks.
PCWorld.com has confirmed that a worm similar to Code Red appeared in February, March, and May 2001 on systems belonging to Sandia National Laboratories, a U.S. Department of Energy security research lab based in Livermore, California and Albuquerque, New Mexico. The worm affected a buffer overflow vulnerability in the .htr files of Microsoft IIS 4 servers; Code Red exploited a similar vulnerability in the .ida files of Microsoft IIS 5. The earlier worm propagated in a manner similar to Code Red, and it also targeted the White House Web site.
"When we saw Code Red come around five months later, we realized it was different in the sense that it was going after IIS 5 servers and using a different overflow, but Code Red was obviously written by the same person as it was attacking the exact same addresses as the .htr worm attacked," says Jim Toole, a network security administrator at Sandia.
Toole and Sandia colleague Jim Hutchins say the .htr worm they spotted in February failed to propagate successfully. It disappeared, but returned in March. They say they notified the Department of Energy's Computer Incident Advisory Capability and the FBI, and gave them complete logs of the worm's activity as well as a copy of the malicious code.
"Each time it happened we gave a heads-up to CIAC and the FBI," Toole says. "We never heard anything back. We just make the reports; what they do with the info after that is up to them."
Toole says the worm hit the same IP addresses at Sandia in all three of its attacks. Sandia's computer system, however, is set up to trick malicious code into thinking it is propagating on the network, but it is safely contained and cannot propagate or infect other machines.
"But at the same time, the 'network' allows the worm to expose itself by letting it do what it's supposed to do," Toole adds. In other words, the intruder still releases its "exploit," or malicious code.
Watching the worm
Toole and Hutchins captured the exploit that the worm carried and released it on a test machine to see what would happen.
"As soon as we ran the exploit it started doing all of these Web requests to a very specific address--ww1.whitehouse.gov. Then it stopped after a while. Then it started doing more Web requests to random IP addresses that it was trying to reinfect," Toole says. Two servers handle requests to the White House Web site: ww1.whitehouse.gov and ww2.whitehouse.gov, he adds. "The .htr worm exploit was directed to a specific server."
Toole says the March attack came from the same five computers running Microsoft IIS 4 servers that attacked them in February; the machines also run Windows 2000. The .htr vulnerability the worm was trying to exploit was an old IIS 4 security hole announced by Microsoft back in June 1999. The vendor released a patch in July 1999.
The worm's methods later proved similar to Code Red. Once the earlier worm had infected a random list of IP addresses, the worm re-set itself to attack the same machines again.
Code Red goes public
When Code Red struck in July 2001, the Sandia system was among the first to be attacked.
"We saw it hitting our systems again on Thursday morning [July 12], before anyone else was noticing it," Toole says. He and his colleagues were monitoring the activity remotely from the DefCon security conference they were attending in Las Vegas. By Friday morning, the e-mail security lists Toole subscribes to were full of discussions about the strange activity that network administrators were seeing on their systems.
That same day security company eEye Digital posted an announcement identifying the activity as a successful attempt to exploit an .ida vulnerability in IIS 5 that the company had discovered in June 2001.
"By then, we had already seen the worm about four times and we knew which five IP addresses it was going to go after first," Toole adds. "By Sunday morning we were seeing 3200 attacks an hour from machines trying to run the exploit on our box. That's a lot of attacks."
His staff first assumed that it was the same author and the same code adapted for a different vulnerability. Why would the worm's writer switch target systems? "Simple. A new vulnerability came out," Toole says. "The number of IIS 4 servers out there is a lot less than the number of IIS 5 servers. So when the IIS 5 vulnerability was announced, it made sense for the author to adapt his worm for that. People assumed it was a new exploit and it was not."
His suspicion of the earlier .htr worm: "It looked like someone was testing out a framework for spreading the worm."
Did the FBI and CIAC drag their feet, ignoring a warning that could have stopped the Code Red worm sooner?
Marc Maiffret, "chief hacking officer" at eEye Digital, says the National Infrastructure Protection Center's slow response allowed the worm to affect more systems.
The NIPC, an arm of the FBI, received reports of the .htr worm in April 2001. But its staff decided not to release an advisory about it because the Computer Emergency Response Team at Carnegie Mellon University had posted an advisory for the .htr vulnerability when it was first discovered back in June 1999, says Bob Gerber, chief of analysis and warning at NIPC.
"If it's important enough and credible enough to consider an investigation, then we take the appropriate investigative avenues," Gerber says. "We look at whether some sort of advisory is necessary. Given that the .htr vulnerability had already been 'advised' by CERT on three separate occasions before April, [we] decided that the NIPC would not do another warning."
Additional CERT advisories described the exploit for the .htr vulnerability in July 2000, October 2000, and January 2001, says Gerber. "We wondered what additional value to the public there was in adding our voice to [that]," he says.
Gerber notes that the NIPC receives hundreds of reports each week and can't respond to each one or predict which reports will escalate into larger problems. Some six to twelve new viruses and worms appear daily, many of them variants of earlier viruses, and many of them unsuccessful at propagating.
"Hindsight is always an easier prospect than warning. I would not do anything different than was done in April," Gerber says. The NIPC issued its first Code Red warning on July 19, after version 2 came out. A second NIPC advisory appeared on July 29.
"The .htr worm never reached the level of infection that we saw with the .ida Code Red," says Gerber. He says that the NIPC had no way of knowing that so many IIS 5 systems were vulnerable. It assumed that most systems would be secure against the attack because Microsoft had issued a patch for the vulnerability on June 18. When the NIPC saw the worm's infection rate rise, it released a warning on July 19 urging network administrators to fix their systems.
"It's a daily judgment on our part as to when we increase the shrillness of our warnings to serve the public interest," sys Gerber.
Code Red and the .htr worm that Sandia found clearly have some similarities, he says.
"They are certainly related in terms of the vulnerability that they exploit and the way they exploit them," Gerber says. But, pending an FBI investigation, he's reluctant to speculate that they were written by the same person.
EEye Digital Security's Maiffret has no such doubts. Had the FBI been more vigilant, Code Red warnings would have spread sooner and faster, Maiffret says.
"If we'd known about the first instance of Code Red back in April, then people would have recognized that Code Red was a worm and would have had a better understanding of it sooner," he says.
Watch for the next worm
"The technique in [the .htr worm that Sandia identified] was actually the technique that was used for Code Red," he says. "There was a span of about five or six days from when people first noticed the [activity of] Code Red and were trying to figure out what it was doing."
Had the NIPC identified the .htr worm as a test worm, or an epidemic waiting to spread, the organization could have responded sooner with its Code Red warnings, Maiffret says.
"I'm sure it's the case that if there had been some national announcement that came out as soon as we observed [the worm] again, the number of machines getting hit might have been reduced," says Sandia's Toole. But prior to Code Red, he notes, the .htr worm "wasn't hitting a whole lot of machines. Looking back, it's an easy call to say that if that information was out, [NIPC] might have moved faster."
Now, Toole is more worried about the next worm.
Code Red was probably designed to attack the White House site because its originator wanted to get attention. But that wasn't its greatest significance, Toole says. He believes it's more important that Code Red could give a cracker total access to an infected network.
He also notes that a month passed between discovery of the .ida vulnerability and the appearance of the Code Red worm that exploits it. Code Red got significant media attention, and writers of malicious code often crave such anonymous notoriety. When the next vulnerability is discovered, it may take only days for a virus exploiting it to appear, Toole says. System administrators will have to patch their systems more quickly, he adds. And the NIPC may need to sound a warning sooner.
"Code Red means there's a framework for a worm out there right now that has proven its effectiveness to spread," Toole says. "All [virus writers] need is a new vulnerability."
|Back to the top|