Last Updated: 2006-12-26 13:23:28 UTC
by Kevin Liston (Version: 1)
A number of days ago, a reader pondered about the possibility of an SNMP "Slammer Worm" based on the vulnerability described in MS06-074. What would it take exactly for there to be another "Slammer"-like event? A worm outbreak requires two major components: an internet worm, and a vulnerable population. The model for the internet worm is made up of further sub-components: the scanner, the propagation code, and the exploit. Scanning routines influence the success and impact of a worm. Poorly written scanning routines have limited many promising young worms in the past. A lot of time has been spent studying the scanning methods of worms, I've wasted an hour or two on it myself, take a glance through www.wormblog.com to see the number of white-papers and academic works on the topic. The propagation code must be written to accommodate any limitations placed upon it by the vulnerability exploited (such as size limitations, and NOP codes, or other constraints on the injected data.) Some overcame these limitations by using a staged approach. This workaround has its drawbacks, as the secondary stage can add its own limitations to the worm since the transfer may fail because of firewall rules or, the source of secondary payload my make a lucrative target for incident handlers. Finally, the vulnerability must allow for unauthenticated remote execution of arbitrary code. Since proven scanning routines are publicly available, and there are multiple examples of propagation code in circulation, the announcement of any network-visible vulnerability that allows unauthenticated remote execution of arbitrary code creates a potential situation.
A quick review of MS06-074:
SNMP Memory Corruption Vulnerability (CVE-2006-5583)
CVSS (Base) : 10.0 http://nvd.nist.gov/cvss.cfm?name=CVE-2006-5583&vector=(AV:R/AC:L/Au:NR/C:C/I:C/A:C/B:N)
Exploit code: Privately Available
Now, some special things about SNMP are since it's UDP, the source IP address can be spoofed without affecting delivery of the exploit, also, knowledge of the SNMP community string may or may not be required to successfully deliver the exploit.
This brings us to our second requirement for an "outbreak event," a vulnerable population. Although a lot of systems are running SNMP, not that many are running with UDP/161 open to the internet. On the other hand, there are a class of networks that may have UDP/161 allowed in from "trusted" 3rd party networks. Which, based on the spoofability of UDP, isn't such a sound security practice. These particulars alone would have limited impact on worm development, though the general inaccessibility to the SNMP port is a major limiting factor on the success of the potential worm.
The limited size of a vulnerable population severely limits the possibility of a generalize Internet worm with "slammer"-like impact.
If there was a large population ripe for an MS06-074 worm, I still reason that there would not be a "slammer"-like worm exploiting this vulnerability. I left out one important criterion for a worm in the model above. In addition to Scanning routines, propagation methods, a vulnerability exploit, and a vulnerable population, a worm also needs a motivated creator in order to come into existence. (I'm chagrined to admit that malware follows a model of intelligence design, and not Darwinian evolution.)
The model of the malcode author has changed these past years. Monetary gain has now outpaced the egotistical quest for fame/notoriety, etc. as the driving motivation behind malcode creation. A malcode author wants to be able to leverage their creation, so now you see botnets, not internet worms.
So, we will not likely see an SNMP "slammer" worm. The question should be: "will we see an SNMP 'SDbot'?" Because of how SNMP is often implemented, I don't see a large chance of that either.
With exploit toolkits like metasploit and webattacker, every new vulnerability that is discovered runs the possibility of becoming an "event." Neither of these toolkits will create an internet worm like slammer. Instead they make smaller, harder-to-detect events that can be leveraged by the criminal to cause more damage in the long run.
kliston -at- isc.sans.org
Last Updated: 2006-12-25 18:44:10 UTC
by Kevin Liston (Version: 1)
The systems ranged from Windows 98 through Windows XP systems. They underwent a simple physical inspection/inventory and then subjected to "evil" acts. They were used in a demonstration of Metasploit as live-fire targets. Malicious USB drives were inserted into them. Finally they were subjected to forensic examination.
Without fail, blind plinking from metasploit, (or a simple nessus scan followed by less-blind plinking with metasploit) resulted in a compromised system. To be fair, the machines hadn't seen Windows Update in a month or two, they had been sitting idly on shelves or packed in boxes. The Windows 98 systems enjoyed a bit of security through obsolescence and were tougher targets for metasploit.
Anti-Virus and Anti-Spyware Protection
Every system had some sort of Anti-virus protection. This is a good thing.
All systems, except for the win98 systems, had Anti-Spyware as well, Spybot S&D was very popular, followed by adaware.
With all of the AV and Anti-spyware running on the systems, none detected the malicious USB drives. Most systems happily complied with the autorun requests. There were many SAM files captured this way.
The systems that resisted the malicious USB drives did not stand up to booting up with knoppix and pulling the files that way. None of the systems used any drive encryption or BIOS protection.
VNC and other BackDoors
Many of the systems booted up with VNC running in listen mode. Probably handy for the sysadmin to maintain their flock, but a strong password, or maybe system-specific passwords may have been a better choice.
One admin created a backdoor account with Administrator privileges (but they do get points for not granting Administrator privileges to all of their users) unfortunately with such a weak password, the strong password protecting the real Administrator account didn't keep my class out of your machine.
Cain and Abel and John the Ripper made quick work of the password hashes. There was not a single instance of a special character in any of the passwords. Great classics like: password and 1234567 were disappointingly common. Administrator passwords were also weakly protected, with only simple tricks attempted like reversing the company's name.
Imaging drives, recovering files, documentation-- good times, but important if you're going to build a case, and important to practice. It doesn't come without its rewards. In the course of the simulated investigation we uncovered two failing marriages, one interoffice romance (nestled ironically amongst power-point presentations on Sexual Harassment in the Workplace,) and all the pr0n one could hope for from Google Images. Sigh.
The surprising find was a lack of rootkits. I was surprised to find very little spyware as well.
There is a surprising amount of company information that leaves the door on the average laptop. Although the word has gotten out about AV and Anti-spyware protection, USB lockdown and drive encryption should also be universally applied to mobile assets. You never know where your old equipment may end up, and who might be writing about what they find?
kliston -at- isc.sans.org
Last Updated: 2006-12-25 04:48:31 UTC
by Marcus Sachs (Version: 1)
From all of us here at the Internet Storm Center, thanks to you - our faithful readers - for another year of support and friendship! Without you we would just be a bunch of incident handlers with nothing to handle.
We hope you have a wonderful holiday season and keep those DShield logs coming. We want packets for Christmas!
Marcus H. Sachs
Director, SANS Internet Storm Center