strange attractors or weaknesses in Nimda's prng

[Russell Fulton <r.fulton () auckland ac nz>]

HI All,
        Apologies to those of you who are on both the unisog list (where I
first posted this issue this morning) and on the incidents list since
you will see this twice.

Brief recap: I recently noticed that one web server on campus was
getting more than its fair share of nimda traffic.  Over half the nimda
exploits being logged by snort for our 100+ webservers were directed to
this one system and this has been happening since the server was first
deployed about 3 weeks ago.  It averages around 7 attacks per hour, 2600
since the machine started.
 
This afternoon I examined the logs of the server in question and
established that the flood of nimda started immediately the server went
on line. I then used the argus logs to look at the traffic to this
address before it was in use and found a consistent pattern of about 7
probes to port 80 every hour.

I then knocked up a perl script to examine all sessions to port 80 that
did not get established. For each destination address on our network I
counted the number of different sources that attempted to start sessions
and ran it over 12 hours of argus logs.  The script sorted the resulting
list by number of unique sources and then printed the list with a
cumulative percentage.

The top 100 address accounted for 15% of the probes and none of the
sources were in the same /8 as us so they should have been uniformly
distributed but clearly are not.  The same pattern holds for other
periods too.

I.e. 100 addresses in our class B accounted for 15% of all port 80
sessions that consisted of a single SYN packet.

So what is going on?

My guess is that this neatly illustrates one feature of pseudo random
number generators: that if they are run long enough they will eventually
all start cycling no matter what starting seed was used.  One of the key
aims in designing prngs is to maximize the size of such cycles thus
maximizing the useful life of the generator before it degenerates. (By
cycling I mean that the prng will produce a reproducible cycle of output
which repeats indefinitely).

Many Nimda systems have been infected for a long time (up to nearly 18
months) and are probably rebooted infrequently.  Thus the prng in Nimda
is likely to have plenty of time to get into one of a small number of
degenerate cycles which are the same for all copies of Nimda.  It would
not surprise me if the prng is poorly designed and has relatively short
cycles.  Thus these long running Nimda will be scanning a small 'random'
subset of the 32bit address space and if you happen to have one of these
addresses then you will get pounded.

We have decide to move the server off the hot address and save logfile
space ;-)  The server is seeing more nimda traffic and real requests.

-- 
Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand

"It aint necessarily so"  - Gershwin


----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com