Slashdot Mirror


Analysis of the Witty Worm

DavidMoore writes "The Cooperative Association for Internet Data Analysis (CAIDA) and the University of California, San Diego Computer Science Department have an analysis of the recent Witty worm. Among other things, Witty was started in an organized manner with an order of magnitude more ground-zero hosts than any previous Internet worm."

16 of 415 comments (clear)

  1. buggy code by neoThoth · · Score: 4, Interesting

    The end of the worm seems to have bytes suggesting a flaw in the original worm code.
    I'm still getting data points for the infected by analyzing the worms victims who contact my IP.

    1. Re:buggy code by rritterson · · Score: 3, Interesting

      "The end of the worm seems to have bytes suggesting a flaw in the original worm code."

      Would you mind elaborating on that assertion? I'm curious.

      --
      -Ryan
      AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
  2. Their unsaid conclusion by ObviousGuy · · Score: 5, Interesting

    They state that the most important thing is to force users into a security mindset and this is near impossible. Also, they point out that even security-aware users may be at risk because of the risk of infection before the ability to patch the firewall/AV software is possible.

    This leads to the conclusion that firewall/AV software should be included as part of the baseline system, whether with the operating system or as an additional package at system build time. Also it leads to the conclusion that user-assisted updates are useless and only automatic updates can effectively patch fast enough to block worms of this sort.

    This is one of the most depressing stories about the state of the Internet that I've read in a while.

    --
    I have been pwned because my /. password was too easy to guess.
  3. vulnerability to worm time by neoThoth · · Score: 5, Interesting

    the rate of worm creation on this one was almost a little TOO quick. This time to creation would almost suggest that the author of the worm perhaps had inside knowledge. It's not entirely outside the realm of reason that the vulnerability leaked from ISS before the announcement was made.

  4. Anyone else see this? by citking · · Score: 4, Interesting
    On Friday March 19, 2004 at approximately 8:45pm PST, an Internet worm began to spread, targeting a buffer overflow vulnerability in several Internet Security Systems (ISS) products, including ISS RealSecure Network, RealSecure Server Sensor, Proventia, RealSecure Desktop, and BlackICE. Emphasis mine.

    Man, I am so used to seeing IIS in a security vulnerability I had to give it a second glace. I guess people shouldn't use those letters in software abbreviations anymore. It's becoming bad luck!

    Seriously, worms like this that damage computers are very un-cool. As a freelancer I got to see this on only a few machines and by gratuitous use of recovery console, fixmbr, and (alas) one format and reinstall later I was able to fix them all.

    While doing this onsite at a realty company I asked what they used as a firewall. Seeing blank stares from them all wasn't the highlight of the day. Not having a hardware firewall handy it was quite fun to race against the vermin as I downloaded patches off of the net on a virgin XP install! I actually thought I heard giggling echoing from the DSL modem as the DL percentage ticked higher slowly but surely....

    --
    "This food is problematic."
  5. What's It going To Take by flopsy+mopsalon · · Score: 3, Interesting

    Another day, another virulent internet worm utilizing an unaccounted-for "buffer overflow" to propagate itself throughout the internet. Users suffer and system administrators grind their teeth to clean out their networks.

    By now I am sure it has been noticed that the "buffer overflow" is a very common "exploit" used by these internet worms to infect machine after machine. One simple way to address this problem would be to replace these vulnerable "buffers" with something that will not overflow, perhaps something spongy and highly absorbent. Isn't anyone working on a solution along these lines? You never seem to hear about any progress being made. Honestly, sometimes it seems like no one in the technology industry has any common sense.

  6. Time to learn SELinux I think by SmallFurryCreature · · Score: 4, Interesting
    Cause Linux and BSD sure ain't safe against this. Bufferoverflows ain't nothing new and this analasys shows there is no security in being a small target.

    Might be time to make a security model that stops a firewall application from writing to the Harddisk or deleting files. Why should it after all? Or a limiting just how many emails a user can send, how many times do you send thousands in a minute?

    Perhaps even a delete mechanism that doesn't allow destruction of data without a password.

    Paranoid? 12.000 machines just went Poof in half an hour with this virus if the story tells it right. Doesn't exactly cheer me.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

  7. KneeJerking by minusthink · · Score: 5, Interesting

    Since I deal more with our internal software/services (opposed to dealing with the customers) I don't do really have to fix anything other than wipe a machine or two. However, for me, the worse part of this is the kneejerking that occurs right afterward.

    Now that this worm hit, management is crying for more security without really thinking it through. Now all staff machines need to be behind hardware firewalls. ALL machines. Linux, Solaris (95% of our boxes), Windows. Not such a big deal except they bought us cheapo netgear cable/dsl firewalls that I'm convinced will do nothing more than ipf/iptables to stop a determined cracker. These netgear firewalls stop me from mounting NFS of anything, they have no trusted hosts options. In fact, I can only port forward from everywhere, so in a sense it is lowering my security.

    Does anyone else experience reactionary steps like this from the PHBs?

    (THanks for reading my rant :)

    --
    "when life gets complicated, I like to take a nap in a tree and wait for dinner" - Hobbes.
  8. Destructive by Anonymous Coward · · Score: 4, Interesting

    Interesting: one could have had the feeling that it was 'stupid' for these worms to destroy their hosts so rapidly. Why not wait for a few hours or days and then do it in a synchronized manner?

    In fact, the overall number of host that could be infested was low (~12,000): there was no need for waiting.

    It seems that those who launched it had a very good knowledge of what they where doing.

    Definitely interesting.

    1. Re:Destructive by buttahead · · Score: 4, Interesting

      there was no need for waiting.

      I'd go a step further and say that immediate damage to the system was mandatory. Waiting in this case would have detracted from the destructiveness of this worm. Since it was attacking firewalled, and, probably anti-virus enabled machines, waiting would mean that the destruction would be nullified.

      It seems that those who launched it had a very good knowledge of what they where doing.

      Sounds like someone from marketing has decided to write worms. They thought about the market of hosts they were trying to infect. A good reason for infecting this set of hosts would have been to stifle the security software vendors. In order to avoid this situation in the future, a person should invest in a new model of protection. Seems to be a perfect opening for a new market.

  9. A niche Warhol worm by theCat · · Score: 3, Interesting

    We tend to think of the M$ monopoly, and the subsequent homogenous pool of hosts, as being the reason for the rapid spread of worms. Actually, the monopoly means that most virus will be targeted for that platform because it is obvious, but a virus well targeted even for a niche platform like ISS can take off because there internet itself is now almost completely transparent.

    What this suggests is that the combination of 1) bandwidth commonly available and 2) CPU speed are now more than sufficient for a virus to find almost all of the hosts it needs to anywhere these are on the internet. When a few early, fast hosts can spew 11,000,000 pps to random IP addresses then it doesn't take long to find what one is looking for.

    No doubt this is part of the reason for the observation that when 2% of Windows sysadmins fail to patch for a known vuln, then the next worm to come along and exploit that vuln has a field day. 2% of a really big number is in turn a lot of hosts, millions of Windows hosts for example.

    And a million of anything, be it Mac OSX or NetScreen or Checkpoint or BeOS or OS/2 or Amiga or anything, is fair game when a smartly written virus can get them all.

    I guess I'll have to go back and review my Mac for system updates.

    --
    =^..^= all your rodent are belong to us
  10. Is there a 0wned-net we need to know about? by LostCluster · · Score: 3, Interesting

    What's most disturbing to me is that this worm appeared on about 200+ distinct hosts at such a rate of speed that it could not have done so that fast using it's main random-checking method. There clearly was some plan to pre-seed the worm into at least that many places before the worm started to spread on its own.

    I doubt whomever programmed this worm had legit access to that many well-destributed computers... so it appears that some carrier hack occured before this worm was released, which effectively took about 12 hours off of the reaction time clock before the white hats even realized what was hitting them. Are we about to see a rash of compound attacks where one worm has a second worm baked in?

  11. Security defined by mcrbids · · Score: 4, Interesting

    I think we all have to come to terms with the fact that our current state of Computer Science is not up to the task of dealing with the Internet as it is becoming.

    Linux/BSD has a somewhat better security record than MSFT, but even after all the auditing effort put out by the guys over at BSD/OpenSSH, there have *still* been a number of security vulnerabilities of recent!

    The problem is not being viewed in the proper light. Something like a buffer overflow should not result in a compromisable host! Something like a misquoted SQL statement should not result in an SQL injection vulnerability!

    Applications and programming environments need to be structured and developed with the understanding that people make mistakes and there needs to be allowance for that.

    You can't expect a group of programmers to maintain 50,000, 500,000, or 5,000,000 lines of code without there being mistakes in there.

    It just cannot be done.

    So languages, programming techniques, and infrastructure needs to be developed that truly prevents the "bug==severe security risk" situation.

    Really, as much as we all laud their security record, Microsoft is in a good position to trounce the OSS crowd if they can come up with a software language and security system that allows for programming mistakes.

    The answer is NOT to make sure you input validate *everything* - although input validation is always a good thing.

    The answer is to develop a system where common programming mistakes do not result in a security issue.

    Get used to it. People are people. They make mistakes. We either cease being human, or develop a system that makes allowances for our humanity.

    Can we do it?

    --
    I have no problem with your religion until you decide it's reason to deprive others of the truth.
  12. Re:Save yourself some reading by bobthemonkey13 · · Score: 4, Interesting
    And that relies on the assumption that your VM securely isolates the virtual machine from the real one. This turns out to be false in practice -- there have been several exploits for Sun's Java VM, and there's no reason to think that Microsoft's .NET runtime will be any better. High-level scripting languages help against low-level stack-smashing attacks, but it's far too easy to write a script that doesn't properly prevent exploitation of the dynamic features of the language (improper filtering of commands to Perl's system(), PHP's remote-fetching include(), etc). Features like Perl's taint-checking can help a lot, but don't take the place of careful coding.

    As for the issue of the underlying OS providing security features, it's not entirely a moot point. Linux provides some stack/heap protection and other binary runtime security through the grsecurity patches; OpenBSD has W^X and other security features built into the kernel. Still, expecting the OS to protect binaries at runtime is a completely ass-backwards way of approaching security. Ultimately, application developers have to bear most of the burden for writing secure code.

  13. Re:New tactical doctrine for attacks by Animats · · Score: 3, Interesting
    It's not a new observation about war. It's more of a justification for putting far more resources into preparation for the first few minutes of a battle than has historically been the case. There's a truism that no battle plan survives contact with the enemy. But for the first few minutes, with sufficient preparation and intelligence, that's often not true.

    The classic example is Eben-Emael. Seventy men took out one of the strongest forts in the world, manned by a thousand troops, in ten minutes. This allowed Hitler's armies to advance into Belgium and conquer France. Six months of preparation, ten minutes of vulnerability.

    The lesson for virus/worm writers is that an attacker needs the capability to rehearse and optimize attacks. This requires two things - general intel about target machines (what percent of targets are vulnerable to each available attack, for example), and a farm of machines on which to test and tune attacks. Many worms/viruses have failed because propagation was too slow, or all the attacks targeted the same machines, or some similar tactical failure in the early part of propagation. The original Morris worm failed for just such a reason. The serious attacker will have a farm of machines on which to repeatedly test the attack plan, without arousing attention until the actual attack.

  14. An Idea which I had for a long time. by LuckyStarr · · Score: 3, Interesting

    Given, many hosts run the same OS (Linux, Windows, whatever) and the same binaries. Even if you compile the source from scratch the resulting binary is likely to be identical to other binaries on other machines.

    This leads to a situation where malicious code can rely on things like stack position and such, enabling it to insert its code into it.

    Idea:

    Is it possible to modify the compiler or binary-format to gather some unique information from the host it is running on and modify the binary in a way that it behaves in a unique way on this machine?
    For example in a way so that malicious code can not predict the position where it can insert itself, resulting in a crash rather than a compromise of the machine.

    Pros:

    - All malicious code would be obsolete if it doesnt know the "secret" of the machine and the method it uses to "scramble" its binaries and/or its memory.
    - All remote/local exploits in any form would be converted to a DoS, which I think is not as dangerous as a compromise.

    Cons:

    - Would presumably make debugging of programs even worse than it is now.
    - Insert "You stupid *%@&, you dont understand" here.

    Please reply, as I feel that I may have missed something important.

    --
    LuckyStarr

    --
    Meme of the day: I browse "Disable Sigs: Checked". So should you.