RE: What, Me Worry About Warhol Worms?

[InfoSec News <isn () c4i org>]

Forwarded from: Rogan Dawes <rdawes () deloitte co za>

Comments inline.

Forwarded from: "Jay D. Dyson" <jdyson () treachery net>

Hi folks,

        I've seen this fly across a number of lists lately:

        Warhol Worms: The Potential for Very Fast Internet Plagues
        http://www.cs.berkeley.edu/~nweaver/warhol.html

        While Mr. Weaver does raise some compelling points about the
        possibility of a Warhol Worm (catchy term!), there are some problems
        with the model he presents.

        1.      Connection timeout:
                Not every IP on the 'net is alive.  And some that are
                alive don't respond to pings or vanilla TCP scans.

Nick was not suggesting pinging, I think. Simply send the SYN, and wait for
an ACK. The worm could use nmap style scanning techniques to keep a record
of who it had scanned, without clogging up the connection table. It would be
able to timeout a lot quicker (and scan a lot faster) this way than if it
used the native OS connect implementation, I think.

        2.      Firewalls:
                Not every system behind a firewall is NAT'd.  Some systems
                have routable IPs behind those firewalls (don't ask me
                why).

How does this slow the propagation of the worm? Sure, in some cases, the
worm won't get out past the firewall again, but perhaps at that point, it
falls back to local network scanning, for the machines it can get to. Do an
initial test for connectivity against a selection of highly available
servers, e.g. Microsoft.com to see if can get out.

        4.      Honeypots:
                HIDS configured to bind to ports typically used by known
                vulnerable services.  The worm "crawls in," but it won't
                crawl out.

Given the numbers of honeypots out there (guess: a couple of thousand, max),
I don't see that that would have a significant effect on the spread of the
worm. Unless the first box infected is a honeypot, and it has the entire
initial hitlist, of course, or a substantial portion thereof.

        5.      Human error:
                As every worm released thus far shows, we're only human.
                Every worm from the Morris worm of the '80s to the Code
                Red have suffered from programmatic mistakes.  It's just
                the nature of the beast.

I wouldn't like to count on that :-)

        6.      Hurry Up and Wait:
                If such a worm were to start propagating at such prodigous
                speeds, it would ultimate start tripping over itself.  The
                first network that would be a victim of it would likely
                suffer network saturation.  This would in turn slow the
                propagation to other networks significantly.

Not if it starts with a hitlist, it wouldn't. That way, the initial
population is fairly well spread out, and does not impact other instances.
ULTIMATELY, it will start tripping over itself, but at that point, it is
because it has already infected the majority of the machines out there.

        All these factors taken together will greatly increase -- by at
        least an order of magnitude -- the purported Warholian window.  

        Sure, the notion of a fast-moving worm seems scary on the face. 
        There is admittedly no effective human response to it...but when you
        get right down to it, the same is true for the
        slow-as-molasses-in-January worms. 

        With all of that in mind, the timeframe of spread isn't the
        alarming part.  The alarming part is that most vendors and admins
        are still sitting on their thumb when it comes to sound
        security practices. 
        *That* is truly the cause for alarm here. 

This I can't disagree with. Given the size of the second Code Red infection
population, a month later, it could spread at a far slower rate, and STILL
get most of the vulnerable machines out there . . . 

        - -Jay

Rogan



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.