The Register, Vmyths &
My Code Red Advisory

by Steve Gibson, Gibson Research Corporation  --  2001/07/30

Saturday, August 4th, 2001 — There's a New Worm in Town:

A new worm appeared on the Internet and began propagating using Microsoft's increasingly infamous "Can O'Worms" IIS web servers.

Calling itself CodeRedII, this is a completely new worm, written from scratch and with a very different agenda and replication technology.

Reports from many users indicate MUCH higher scanning rates (personal firewall logs going crazy and filling up) due to a much more clever (much less random) and aggressive second-generation IIS-searching system. The worm tends to search mostly within its own "IP neighborhood", only occasionally sending probes out to other networks. This tends to cause it to waste less time probing large dead areas of the Internet.

And this worm is more nasty than the first: This worm plants a "Trojan-style Backdoor" on every infected server. This subsequently grants anyone remote access to the server's resources. And since any "infection probe" captured by a personal firewall originates from an open infected server, these "backdoor Trojanned" systems actively advertise the availability of their backdoor across the Internet.

Click here for a complete technical analysis of CodeRedII

Never a dull moment.

For further information, please see these excellent sites:

NOTE — The following page documents my prediction of the return of the FIRST worm, which did, as we now know, come true in spades:

On Sunday, July 29th, 2001, with August 1st looming, I set aside some time to examine the programming code of the Code Red Internet worm. I then initiated a dialog with a number of agencies of the US government and private industry to share, confirm, and discuss my findings.

Finally, coming to the conclusion that we have not seen the last of the Code Red Internet worm (by a long shot), and feeling that the reasons for this have not been adequately reported by the computer press, I wrote and forwarded the following advisory to a number of my friends in the press with whom I have corresponded in the past:

The text of my press advisory:

Hi Friends,

This weekend I have been in dialog with eEye's Marc Maiffret, law 
enforcement agencies of the U.S. government, NAI,, and 
others. After finally making time to examine the Code Red worm code, 
I have been trying to assemble a picture of the next 23 days.

I think you'll find it interesting:

It has become *CLEAR* that at midnight of Tuesday, July 31st (UTC), 
when the dates set into the clocks of the world's nearly 5 million 
IIS servers change the "Day Of 
Month" from 31 to 1, a repetition of the exponential growth of the 
Code Red worm will IMMEDIATELY commence. If you have not seen CAIDA's 
excellent write up on the previous event, you must:

(Be sure to notice that the vertical axis of figure 3 is LOGARITHMIC, 
so that nice straight and linear "growth line" is actually 

As you may know, the second variety of the Code Red worm, with the 
much more random IP generator, is designed to replicate while the 
day-of-month is less than 20. When the day-of-month is greater or 
equal to 20 and less than 28, it attacks an IP which used to be the 
Whitehouse. And it terminates its activities from the 28th through 
the end of the month.

However, both Marc Maiffret and have confirmed that many IIS 
Servers (Marc has logs showing thousands) with incorrectly set 
clocks, are actively scanning for IIS servers right now.

To a private industry/government list, at the end of a lengthy 
analysis, I wrote the following:

>>> Note that at the start of NEXT MONTH it will only take ONE SINGLE
>>> MACHINE -- with an out-of-sync date whose infection threads have
>>> remained active in a mistaken belief that the date is < 20  -- to
>>> re-initiate an exponential growth starting at midnight of July
>>> 31st, UTC.

To which Martin Lindner of CERT.ORG replied:

> Steve,
> Everything you said is correct. We have identified several systems
> with their clock off and capable of "restarting" the scanning on
> Aug. 1st UTC.
> Marty

And Marc wrote:

> We have also seen logs of about 2 thousand machines that are still
> attempting to infect new systems however since most of the systems
> they are hitting, do have the correct date set, the infections are
> not really spreading noticeably. When the 1st comes around though
> ... unless a few hundred thousand NT administrators have installed
> patches... well then were going to be going through the same thing
> all over and as we saw... the actual spreading of the infection was
> much worse then the failed DoS attack against

At today's date, any non-patched IIS server set with the correct date 
will accept a new copy of the infection, but the "worker threads" are 
immediately sent into an infinite sleep loop, rendering the infection 
ineffective. (Sufficient re-infections can crash the IIS Service 
process, but Microsoft's Windows 2000 "high availability" technology 
simply restarts the dead service, thus readying it to accept a new
batch of infections.

However, on this coming Wednesday, August 1st, all non-patched IIS 
servers with the correct dates *will* again become willing recipients 
of the worm, each launching their 99 replication threads and 
collectively pummeling the Internet as they search out and locate new, 
still-defective, IIS hosts.

Since we now have high confidence that there will still be IIS 
machines actively "re-initiating" the infection at that time, we can 
presume that "all hell is going to break loose" starting Wednesday 
August 1st, and we can expect a repetition of the exponential growth 
which CAIDA's analysis demonstrated so clearly -- just as the worm 
VOLUNTARILY switched from its replication to attack mode.

Note that shutting down the worm on the 20th was nothing *we* 
(humanity) did.  MOST copies of the worm turned themselves off.  
Also, since a very subtle one byte change in the original "bad 
replicator worm" turned it into a "good replicator worm", it seems 
highly likely that the worm's original author deliberately re-
introduced the fully-potent worm JUST HOURS BEFORE it was due to shut 
itself down.

Since the code *does* call for all worms to shut down PERMANENTLY on 
and after the 28th (though there's another "one byte switch" waiting 
in the code to disable that too!), the worm's author may not have 
intended this worm to continue living ... as it has due to incorrect 
computer clocks.

Unlike many similar previous threats such as the W32Leaves.Worm and 
the Zombie/Bot Trojans I have written about before, the Code Red worm 
has NO POINT OF CONTACT to allow its collective control.

The Leaves Worm downloads the rest of its code from third-party 
servers which can be shut down, and IRC-controlled Bots can be easily 
excommunicated. But this worm is a truly autonomous replicator 
without ANY MEANS for external control.  I believe, therefore, that 
it is going to be with us for a LONG time.  And, so long as SOME 
(even one) IIS server has an incorrect date, the worm will be "kept 
alive" through this overlapping of replication efforts.  I don't know 
how we're ever going to get rid of it entirely.


As an aside, I'll note that this does bear on my ongoing argument 
with Microsoft over their intransigent position regarding Windows XP 
and full raw sockets:  One of Microsoft's arguments against my 
position has been that once a machine has been taken over by a 
malicious hacker that hacker could download advanced packet-
generation software, thus rendering moot my concern over the NATIVE 
presence of full raw sockets.

However ... a fully autonomous and ram resident worm like Code Red 
has NO OPPORTUNITY to download code (which would render it non-
autonomous and thus vulnerable to control and shutdown). However, it 
DOES have access to *ALL* of the native Application-level API in the 
machine.  Thus, if this worm were using the full raw sockets 
capabilities which has already been built into Windows 2000 -- which 
it easily could be -- for launching spoofed IP SYN floods -- we would 
already be in MUCH WORSE SHAPE.

And, finally, note that this IIS .ida bug was ALREADY INCLUDED in the 
pre-release copies of Windows XP. Thank goodness the eEye guys 
brought this to light NOW, in time for Microsoft to fix it before 
Windows XP went gold.

But what OTHER unknown and possibly similar vulnerabilities does 
Windows XP have that have not yet been discovered? Imagine if this 
powerful autonomous replication capability -- enhanced with Windows 
XP full raw sockets -- had gone out to the Windows XP audience -- as 
it almost did.  Oh well, everyone knows I tried hard to prevent it.  
We'll see what the future holds.


All the best, and thanks for your attention to this.
I think it will CLEARLY BE next week's big news.

To eliminate confusion, "next week" at the close of my note above refers to the week beginning July 30th and containing Wednesday, August 1st, 2001.

It was not my intention to share this note directly with the public. I hoped that the computer industry press would digest it, do their research, and write whatever they felt was best (as they have, see links below). However, a strongly-worded article appeared the following day in The Register, written by Thomas C Greene (you may click the link to send Thomas your thoughts). Thomas' article referred to my note to the press without reproducing it and without making it available. So I wanted to allow anyone who was interested to have an accurate statement from me.

Since then I have been gratified to find my analysis supported by Microsoft and several leading Internet security organizations. The SANS institute sent this announcement, which was also echoed by Microsoft, calling it an "Urgent Security Announcement". Microsoft sent the announcement to their security list subscribers with the following heading:

The Microsoft Security Response Center, along with other
organizations listed below, is jointly publishing this

A Very Real and Present Threat to the Internet:
July 31 Deadline For Action

Additionally, CERT.ORG updated their earlier page. In their report, updated July 30th, CERT states:

" Different organizations who have analyzed "Code Red" have reached different conclusions about the behavior of infected machines when their system clocks roll over to the next month. Reports indicate that there are a number of systems with their clocks incorrectly set, so we believe the worm will begin propagating again on August 1, 2001 0:00 GMT. There is evidence that tens of thousands of systems are already infected or vulnerable to re-infection at that time. Because the worm propagates very quickly, it is likely that nearly all vulnerable systems will be compromised by August 2, 2001. "

As you'll know from reading the analysis and advisory which I sent to the press, my analysis favors the expectation that a few "straggler worms" that have continued operating — due to the dates of their clocks being incorrect — will have the effect of "re-starting" the infection two days from the date of this writing.

Either way, we'll soon know.

Please note that neither in the above communique, nor elsewhere, have I ever made any dire predictions for the worm's effect on the Internet. Others have, but I am skeptical. I believe that the Internet can easily handle the "replication probing traffic" generated even by millions of simultaneously searching and reproducing IIS worms.

The Code Red Worm in the News  (since July 29th, 2001) Officials Fight 'Code Red' Attack

 USA Today: Officials sound alarm over 'Code Red' worm

 CNET.COM: Government: Fight Code Red worm

 MSNBC: Government, security officials sound alarm . . .

 BBC News: Internet put on Code Red alert . . .

The Second Worm:

 Code Red foreshadows evolution of cyber threats . . .

 New Variant of Code Red Computer Virus Sighted . . .

 Britain Issues Alert Over New Computer Worm . . .

If you have some time for an editorial:

 LinuxPlanet: .comment: The Weakest Link

To return to the previous page, press your browser's BACK button.

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2014 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Oct 06, 2003 at 14:29 (3,852.89 days ago)Viewed 4 times per day