Hi Friends,

This weekend I have been in dialog with eEye's Marc Maiffret, law 
enforcement agencies of the U.S. government, NAI, cert.org, 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 http://www.netcraft.com/survey/ 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: 
http://www.caida.org/analysis/security/code-red/.

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

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 Cert.org 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 whitehouse.gov.
>
>-------------------------------------------------------------------

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.