strange attractors or weaknesses in Nimda's prng

From: Russell Fulton (r.fultonat_private)
Date: Wed Dec 11 2002 - 01:46:34 PST

  • Next message: Mark: "Re: EBay Fraud Attempt"

    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
    



    This archive was generated by hypermail 2b30 : Wed Dec 11 2002 - 10:49:21 PST