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.
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.
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.
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.