full-disclosure - The worm author finally revealed!

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: mark at tweakt.net (Mark Renouf)
Subject: The worm author finally revealed!

futureshoks@...hmail.com said the following on 1/31/2003 7:53 AM:

 > So saying that there is no excuse to patch blah blah blah doesn't
 > hold true. We have to work within logistical boundaries and do
 > what we can. What do you do if patching isn't viable, the systems
 > have to stay up and development/test resources can't be commited
 > to fixes? In this instance you block port 1434 if you can and
 > hope to God that nothing bad happens.

(Note: this is not directed personally at you, just an observation
in general.)

What I don't get, why the sudden urgency to block 1434 all of a
sudden... what are your SQL boxes doing listening publicly on
ANY FREAKIN PORT AT ALL? IMO not only should SQL boxes be not
listenin to the internet, they should be firewalled even behind
the DMZ, so you'd have to comprimise both the web servers and
them to do anything nasty...

This goes FAR beyond forgetting to install a simple patch, I think
it shows just how many poeple out there have no port filtering
in place and probably check off "full install" on their windows
servers without a second thought.

It also shows how many companies could give two shits about
patching and firewalling important boxes internally. It only
takes one. In our case we were infected by Corporate Central
via the VPN tunnel. *sigh*