bugtraq - Re: msblast.d and a review of defensive worms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 18 Aug 2003 15:50:38 -0700
From: Nicholas Weaver <nweaver@...berkeley.edu>
To: "David J. Meltzer" <djm@...rusec.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: msblast.d and a review of defensive worms

On Mon, Aug 18, 2003 at 01:42:29PM -0400, David J. Meltzer composed:
> As many people have undoubtably already seen, the newest variant of
> msblast (dubbed msblast.d, see
> http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_MSB
> LAST.D) is one of a growing group of "good/defensive worms."  
> 
> As every previous "good" worm has, this will of course touch off another
> debate on just how bad worms of this variety are.  Coincidentally
> (really!) I have been polishing a presentation on defensive worms I will
> be giving at Toorcon.  Since the historical portion of my presentation
> has become so timely, I've put up that first portion of my presentation
> on the web for anyone interested to review.  
> 
> It is directly linked at http://www.intrusec.com/resources.html, no
> registration of any kind is required to read.  If you have any errata or
> additional references, feel free to e-mail me privately and I will
> incorporate them.
> 
> Here is also the list of references from this presentation for anyone
> who just wants to go directly to the source material and skip my fluff:

A couple of other comments, not really addressed in the sides.

Beyond being blatently illegal, white/good worms have a couple of
other BIG problems:

They can't work against a smart "black" worm: the white worm must be
released afterwards (otherwise, why not just use autoupdate, as there
is "no worm required" for autoupdate to work?  Which vulnerabilities
get white worms and which get ignored?).

Unless the black worm is grossly poorly engineered, the black worm
will have spread everywhere and had a chance to unleash its payload.
Remember, the release of a white worm involves human intervetion (use
the exploit, TEST, release), while viable defenses need to be
automatic.

Likewise, a black worm can easily close the hole behind it.  EG,
slammer blocks further infection (the service is frozen into the
sending loop).  So you can't make an anti-slammer worm, without using
a different exploit, as slammer-infected machines are immune.

Likewise, MS-blast (i think) uses the RPC crashing version of the
exploit, so while the computer stays up, further infection by any
means, using the RPC vector, would be impossible.

So even a "lame, slow" worm like Blaster can still be resistant to a
white-worm counterattack, simply by virtue of closing the hole it used
behind it.  Note that this closure doesn't necessarily require
patching, just killing/disabling the vulnerable part of the service
used by the worm, which has happened (inadvertantly) in the past.

-- 
Nicholas C. Weaver                                 nweaver@...berkeley.edu