Slashdot Mirror
Worms Going Further, Faster
Major Byte writes "Rob Kolstad's MOTD (pdf) column in Usenix login; passes along a few distilled factiods from a CAIDA analysis of the 'Sappire/Slammer' Worm. When it was at full blast it was scanning over 3 billion systems per hour--a speed that 'a "better" vulnerability would have enabled infection of the entire internet in 15 minutes, a "flash worm" or a "Warhol Worm."' I think 'better' to mean 'able to infect across a lot of platforms.'"
http://www.cgisecurity.com/articles/worms.shtml
Don't confuse rate of scan with number of systems. As mentioned it was spewing it's exploit in a single UDP packet. The worm didn't care whether other worms had already spewed the packet at a given IP, it was just tossing it out there. Whether the number itself is valid, it's being calculated (probably, at least) by multipying the average bandwidth available to an infected host, times the number of infected hosts. X infected hosts spewing Y packets an hour is Z total packets per hour.
Perhaps not especially useful, but it does give an idea of the sheer scope of that beast.
Never attribute to malice what can as easily be the result of incompetence...
The statistics does hold, the efficiency of the worm decreases because there simply aren't enough hosts on the internet (or in IPv4 for that sake) to keep the worm busy for several hours...
If the worm spews out X packets over Y minutes, why would it change in the Y+n next minutes ?
Think about it yourself, the worm doesn't suddenly stop and think "hey I've infected 3 bn. systems now, I better slow down", it keeps on going, but as only a fraction of the 4 bn available addresses in IPv4 are available and globally reachable it doesn't make sense to do an exhaustive test...
If you're running Apache, and it looks like you are, you can avoid logging that crap (and minimize bandwidth and CPU waste) with this minor httpd.conf change. You can also block/ban email spiders (at least ones that report their agent name truthfully, which apparently is most of them) using the info at the same link.
everything in moderation
Actually, Microsoft had released a patch for the vulnerability that was exploited. Unfortunately, no one (including Microsoft) bothered to implement it.
!#@%*)anks for hanging up the phone, dear.
How to 0wn the Internet in Your Spare Time
Interesting topics: "Better" worms techniques
"A combination of hit-list and permutation scanning can create what we term a Warhol worm, capable of attacking most vulnerable targets in well under an hour, possibly less than 15 minutes. "
Brain is my second favorite organ.
It's not a description of an actual worm, it's not even a description of how to build a worm, it's a vague description of how a worm might be constructed:
1. Scan internet servers looking for vulnerable software
2. Infect said software.
Duh. The author writes, "I didn't write this paper to give people malicious ideas." -- It's okay! There's nothing in the paper that would assist people in doing anything useful!
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
Actually, the new Bugbear does selectively infect shared files. On my network, two 98 boxes had their entire C drives shared, while someone else (a laptop) became infected with the new Bugbear. Those two computers had only a few infected files, including:
c:\program files\internet explorer\iexplore.exe
c:\program files\outlook express\msimn.exe
c:\program files\adobe\acrobat x.0\reader\acrord32.exe
So it looks like the new Bugbear already selectively infects shared files.
We need to stop stressing prevention quite so much and start dealing with what happens when a virus does get through.
We don't need to stop stressing prevention, but some shops certainly do need to react faster when something hits.
Whatever you gain by compressing something that small, you lose in the space that the decompression code takes up, unless the OS provides a decompression service for you.
The way Slammer worked, it had to fit in a single packet, which meant it had about 1500 bytes to work with. That means it could have been more than four times bigger than it was, but no more.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
A key point of this article is patch-based security won't work, and signature-based virus scanning won't work, against a competent attacker. If someone discovers a new exploit and crafts a fast-spreading attack based on it, the attack can take over a vast number of hosts long before there's any response.
DOC, XLS, MDB, BAT, ZIP, TAR.*...
Ok, so those aren't obvious carriers in the same way that you classified the filetypes that you listed. However, they are all potentially capable of carrying and delivering malicious code and, at the same time, all potentially valid attachment types.
The problem with blocking attachments is that certain filetypes are often used for virus distribution but also for valid email. Something like PIF can be blocked because no one sends PIF files as attachments. Blocking an EXE or a DOC file may have unforseen consequences, however. The solution isn't to block every suspicious filetype that comes through. Running those files through a virus scanner on the server side would probably be a good idea, though. Of course, that'd use more CPU time than just delivering the message, so messages might end up being delayed a few seconds, but it's a small price to pay.