Changing Threat Models
    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
A Security Sampler
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.
Metasploit Results
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.
Malicious USB
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.
Knoppix
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.
Passwords
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.
Forensic Fun
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.
Surprising Find
The surprising find was a lack of rootkits. I was surprised to find very little spyware as well.
Final Word
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
Merry Christmas to All!
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
 
              
Comments