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."
Conclusion:
The Witty worm incorporates a number of dangerous characteristics. It is the first widely spreading Internet worm to actively damage infected machines. It was started from a large set of machines simultaneously, indicating the use of a hit list or a large number of compromised machines. Witty demonstrated that any minimally deployed piece of software with a remotely exploitable bug can be a vector for wide-scale compromise of host machines without any action on the part of a victim. The practical implications of this are staggering; with minimal skill, a malevolent individual could break into thousands of machines and use them for almost any purpose with little evidence of the perpetrator left on most of the compromised hosts.
While many of these Witty features are novel in a high-profile worm, the same virulence combined with greater potential for host damage has been a feature of bot networks (botnets) for years. Any vulnerability or backdoor that can be exploited by a worm can also be exploited by a vastly stealthier botnet. While all of the worms seen thus far have carried a single payload, bot functionality can be easily changed over time. Thus while worms are a serious threat to Internet users, the capabilities and stealth of botnets make them a more sinister menace. The line separating worms from bot software is already blurry; over time we can expect to see increasing stealth and flexibility in Internet worms.
Witty was the first widespread Internet worm to attack a security product. While technically the use of a buffer overflow exploit is commonplace, the fact that all victims were compromised via their firewall software the day after a vulnerability in that software was publicized indicates that the security model in which end-users apply patches to plug security holes is not viable.
It is both impractical and unwise to expect every individual with a computer connected to the Internet to be a security expert. Yet the current mechanism for dealing with security holes expects an end user to constantly monitor security alert websites to learn about security flaws and then to immediately download and install patches. The installation of patches is often difficult, involving a series of complex steps that must be applied in precise order.
The patch model for Internet security has failed spectacularly. To remedy this, there have been a number of suggestions for ways to try to shoehorn end users into becoming security experts, including making them financially liable for the consequences of their computers being hijacked by malware or miscreants. Notwithstanding the fundamental inequities involved in encouraging people sign on to the Internet with a single click, and then requiring them to fix flaws in software marketed to them as secure with technical skills they do not possess, many users do choose to protect themselves at their own expense by purchasing antivirus and firewall software. Making this choice is the gold-standard for end user behavior -- they recognize both that security is important and that they do not possess the skills necessary to effect it themselves. When users participating in the best security practice that can be reasonably expected get infected with a virulent and damaging worm, we need to reconsider the notion that end user behavior can solve or even effectively mitigate the malicious software problem and turn our attention toward both preventing software vulnerabilities in the first place and developing large-scale, robust and reliable infrastructure that can mitigate current security problems without relying on end user intervention.
You can find more information here.
In contrast, the Witty worm infected a population of hosts that were proactive about security -- they were running firewall software.
This makes me feel a bit safer, since we used to run Windows-based boxen directly on the Internet but now they all hide behind a Linksys NAT Router and firewall.
From what I've learned, the general rule is NEVER to put a Windows machine directly on an unsecure network. Unfortunately, the machine I'm typing on here at the University of Virginia is directly connected and yes, it runs Windows. I turned on the Internet Connection Firewall...but this kind of worm vulnerability makes me nervous. Today, someone attacks the eEye security software; tomorrow, someone takes out Microsoft's ICF.
Similarly, end users may also be unaware that perceived slowness of their computer or Internet connection is caused by a worm, and they may reboot their computers in the hope that that will fix the problem.
I find this problem with spyware and adware too. I recently cleaned out the computer of a family friend that was very slow and would no longer connect to the Internet. Removed a huge gob of spyware with Ad-Aware and Bazooka, and BAM! we were back online.
Goes to show you. I'm thinking that Microsoft's security model in Windows may need to be revised, considering in XP Home at least, all users run as Administrator (root) and system services have way too many privileges.
Makes me glad I replaced my aging NT file server with Linux/Samba.
i believe it's the first host to be infected, the 'master server', but it might just be that the master server just had server 'baby' master servers.
Runnin' On Empty
A ground zero host/vector is a host that wasn't infected by another machine, but by an individual who wished the machine to infect other machines. A ground zero host does not necessarily need to have the same exact code as the code it sends out, for example, in this case, it would be unproductive for the ground zero host to have the original code since it erodes the filesystem of the host.
I guess the writer had written the payload in advance and waited for an appropriated vulnerability to show up to use as a vectir. Generating exploits isn't rocket-science... in fact there are automated tools out there that will generate exploits for common holes like buffer/stack overflows.
There is also the chance that the author discovered the bug either himself or through "black hat" groups before the advisory was put out.
That was not their conclusion. If you continued the quote, you'd see that they said much the same thing as you.
When users participating in the best security practice that can be reasonably expected get infected with a virulent and damaging worm, we need to reconsider the notion that end user behavior can solve or even effectively mitigate the malicious software problem and turn our attention toward both preventing software vulnerabilities in the first place and developing large-scale, robust and reliable infrastructure that can mitigate current security problems without relying on end user intervention.
ZDNet UK had a preview of Windows XP SP2 recently (see link) that included discussion of the pack's implementation of software-based overflow protection. It also mentions that 64-bit processors include this protection in hardware (NX or "no eXecute"). So, there is a little progress being made.
The Ezine Directory
The proper term in epidemiology would probably be "index cases."
Read Gibson's report of the DDOS on his website, and you'll have a completely different view of the possible reach of a 17-year-old in our current times of insecure computing.
http://www.grc.com/dos/grcdos.htm
In short, anyone with basic scripting knowledge and some time can create a reasonably-sized network (of a few hundred system, at least) of remote-controlled "bots" or zombies, generally home users on cable modems. Quickly-propagating worms are more easily come by. It doesn't take much to add a "delete IMPORTANTFILE.SYS" to one of those.
It takes even less effort to then combine the two.
While this action may appear to require large-scale planning and intent, it can accomplished fairly easily by one kid with issues and a bit of time to work on it. Not to say that it *isn't* an easy way for cyber-terrorists to strike (if a kid can do it well, a trained terrorist could probably add something more interesting), but it is definitely within the reach of an oddball kid.
That will depend on how ipv6 addresses are allocate. IPv6 pushes address space from 32 bits(~4 billion) to 128 bits (~4billion^4) if everyone spread out over the whole range it could slow down the spread of viruses since each random address would have a much lower chance of hitting a live machine. If however we all cluster in the same part of that range it won't help at all.
You can massively limit the damage done by a worm in Linux simply by running all processes that leave a port open in a chroot jail, or by doing so as a lesser privledeged user. This is one of the many simple solutions avaliable, while in Windows, its not so easy.
From the article text:
"The worm payload of 637 bytes is padded with data from system memory to fill this random size..."
So you are seeing some random grabage that was in memory on the victim's machine while the worm was being sent out. That helps to avoid detection as it is harder to profile the worm.
I believe the US government gave M$ a "pass" on security and allowed it to sell software to, for example, the Navy. (I am too lazy to look up the details.)
Cringeley... (the real one, not the fake ghost-written InfoWorld column version) discussed this very subject in his two latest columns...
1
2
No. There are exactly 126 Class A addresses. They probably DO have a Class A, if their claim is correct, but there are not 256 of them, just 126...
More destructive worms = less apathetic/ignorant users out there
I'm not going to bother replying to your "it's the victim's fault" tripe, but I'll just point out that the problem with this particular worm is that it's destroying computers from users that are NOT apathetic, it's targeted at people who have bothered to get a firewall up and running, using a exploit that was detected just a day before the spread.
Of course, you'd know that if you had bothered to RTFA. Wishful thinking, I know...
---- Take the Space Quiz!
But native compiled Java, with Java's bounds checks, would be far safer than C++.
Or how about native compiled C++, with bounds checks?
There's nothing about C++ that means you can't have bounds checking! The specification allows for undefined behavior when an array is accessed incorrectly. The compiler author can decide for himself what that undefined response could be. It might be an invalid access (like most current compilers do), but there's no reason it couldn't hit a boundary-check and abort the program.
Assorted add-in libraries to C++ compilers do this. They're not very popular, of course. But if programmers cared about safe insurance against memory overruns, they could achieve it without switching languages.
Windows Update is nice for keeping up to date with all the patches for windows as they are released. But using it to patch a series of machines doing fresh installs is silly.
At the height of the Blaster worm, I had to reinstall Windows for a friend of mine. I connected to the net in order to update Window XP, and her machine was reinfected within five minutes of connecting: before the machine could be patched.
I learned my lesson. Here is a guide on how to slipstream an installation of Windows XP and SP1.
Although I wouldn't recommend it, you can also slipstream a copy of Windows SP2 Beta 1. When SP2 is finalized, I fully intend to create a slipstream version of that for the next time I have to reinstall windows somewhere.
See, this is why service packs are a Good Thing (TM).
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
XP has a built in firewall you could have enabled BEFORE you connected the ethernet cable
more than enough protection during your race to download patches.
frankly, enough protection for concientious users ALL the time
http://www.microsoft.com/billgates/speeches/2004/
The parent comment caught my eye in particular because security was brought up as an issue when discussing the future roadmap for Visual Studio. Gates said the following: So, in a nutshell, Microsoft's next release of Visual Studio, 2005, will have new features that try to detect common flaws in development patterns and warn the programmer ahead of time.
Applications can also make a distinction between administration/user modes, and if this is what I think it is + Microsoft implements this correctly, then Windows security could move up a step closer to that of Unix-based permissions systems with a rough emulation of the relation between root/user modes.
And most importantly, with compiler options to automatically write in extra security checks, developers may not have to ever even know that a particular bug exists and still be a-ok.
Will this warn the developer of every bug? Probably, and almost 100% certainly not. For that matter, it's an extremely bad thing if you designed your code poorly and don't know that it is so- programmers should not be initially taught using tools like this.
But, as the parent mentions, this will lead to somewhat-more-secure code, and help in the long run.
In fact, I don't see anything bad about writing developer tools such that the environment can sensibly pop up a dialog asking "Are you sure you don't want to check input xyz?". At the very least, something like this is needed in both Microsoft and OSS development platforms.
He isn't saying this specific vulnerability was the one that could have done it. He's saying that if a vulnerabilty did come along that could enable someone to do it, that he would not have patched until it was too late.
I wouldn't have either possibly, the point being you have to be sure that people can't get to your boxes like that. Either by patching or having layers of abstractions to stop it from happening. Most likely both.
It's more of a hypothetical at this point, but saying "it will never happen to me/us!" is bad policy.
That's scary.
No, that's not the worst case. The attacker would own the firewall. In a second step he could then attack the now unprotected system. If the firewall is hacked, the defender has lost - it's that sipmple.
But it might be a could idea, to put the IDS outside of the firewall.