full-disclosure - Worm side effects

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]

From: geoincidents at getinfo.org (Geo.)
Subject: Worm side effects

The nachia/welchia worm that is doing all the icmp traffic uses 92 byte ping
packets, a rather unusual size which makes it easy to filter them without
blocking all icmp traffic. It took me a while but I think I figured out why
92 byte echo requests.

Because of this worm everyone is now blocking 92 byte imcp packets because
they cause an arp storm and crash network devices like Max TNT dialup boxes
that many ISP's use when the worm starts scanning a class C block. It's a
real problem.

I think I know why the worm used 92 byte icmp echos. Windows tracert command
(traceroute) also uses 92 byte icmp echo packets. Filtering the worm breaks
windows command line tracert plus samspade traceroute and any others that
use the built in windows function. Doing a traceroute from a dialup box or
router still seems to work fine and it probably works fine for unix as well
although I haven't tested that.

Guess it's possible the author figured nobody would be willing to break
windows in order
to stop what he thought would be a harmless worm, turns out he miscalculated
both.

So what the world needs now is a replacement for tracert.exe so that windows
users can once again do traceroutes. Microsoft, are you listening?

Geo.