[Dshield] WMF - SETABORTPROC alarms
ssmith at kwqc.com
Mon Jan 2 20:57:23 GMT 2006
I'm not sure it is entirely fair to compare this exploit to recent ones.
While it lacks replication, disarming it as a large network-disabling
giant as we are getting used to, it targets and exploits novice
users.... Those who run as at administrator level without knowing the
damage and/or incontinence they could case themselves, smaller
businesses who run only one or two computers and depend on them for
their entire operation, and ALL users (home and office) who just are
plain ignorant to the dangers of such things no matter how many times
you explain it to them.
ISC has already reported the hijacking of a "trusted" webpage frame
redirecting users to infection. McAffee has reported that 6% of it's
"users" are infected. 6% is a very large number. While unlikely in my
environment, if 6% of my users were infected, I'd have my hands full for
the rest of the week to say the least.
I feel that the patch (and subsequent testing) was completely justified.
Vendors no longer (have they ever?) move at the speed of the net. Their
jobs are reactionary. The community must pull together to help itself.
Disabling, removing, and/or unregistering the suspect dll was examined
as a possible fix. Blocking WMF images was examined as a possible fix.
Current anti-virus &anti-spyware definitions were examined as possible
fixes and all were found to be partial. Partial isn't good enough.
Trusting my users is FAR from good enough.
With the community having pulled together, I could have spent less time
launching the temporary patch as opposed to rescuing 6% of my users from
themselves. As they say, time is money....
From: list-bounces at lists.dshield.org
[mailto:list-bounces at lists.dshield.org] On Behalf Of bschnzl at cotse.net
Sent: Monday, January 02, 2006 1:10 AM
To: list at lists.dshield.org
Subject: [Dshield] WMF - SETABORTPROC alarms
I would like to examine the relative risk involved with the WMF -
SETABORTPROC (heretofore "WMF") issue. Setting aside responsible
disclosure issues, I believe the vulnerability is not as pressing as
others in the past. Resources used in testing the "unofficial" patch
are better used elsewhere. Insight from replies will guide my response
to this disclosure.
Here is my analysis of the disclosure. The potential for automatic
exploit is low. If one limits user shell activity on critical machines
properly, exposure is reduced, and native recovery platforms remain
available. The exploit renders privilege in the current security
context, requiring additional functionality to perform administrative
level functions. As well, limiting NetBIOS connections across network
boundaries removes the largest exposure.
Best Practices already indicate more controlled environments for Road
Warriors, increasing this risk only marginally.
The vulnerability requires the opening of a graphic file. This is
decidedly a user function. Windows Explorer will do this to every file
in opened directories, but the user has to open the directory.
Thus, the speed with which any malware will travel through a network is
reduced below that of the Nimda and Zotob worms, for instance.
Those with access to critical machines are more likely to know that
reading your personal mail on a server is not recommended.
While browsing the web is certainly doable on a windows server,
hopefully administrators know that is not a good idea. Generally, these
users have better ideas of how they will do things when they start
pushing the mouse around. With more deliberate action paths comes less
risk, in this case especially.
This exploit compromises the user's account only. Hopefully users
are limited in what they can do to their physical workstations.
Certainly they should be limited to how they can make changes on the
server. While any compromise is dangerous, real system damage requires
another attack in this case. That gives those who practice
defense-in-depth another opportunity to detect the intrusion. Again, it
could be worse.
In this day and age, most of us know that allowing NetBIOS to the
open internet is asking for trouble. In the case of a file finding its
way on to shared drive spaces still only infects the workstations that
open it. The server that hosts that file can be cleaned from a command
line. As well, in the case of older variants, the server provides a
second chance at detection.
Road warriors remain a problem, but this particular issue does not
increase the risk as much as simply connecting to uncontrolled networks.
The connection risk indicates increased education effort, and quarantine
procedures. These steps provide momentum toward handling any compromise
along this vector. I feel justified in listing this as a marginal
increase in risk.
While my own experience is that few networks practice the above steps
in a comprehensive way, much progress has been made. Today's networks
are much more resistant to this sort of vulnerability than just a year
ago. Some networks have been compromised by using this exploit. Fewer
still will notice. That responsibility rests squarely on the management
and administrators of each network. With that level of resources
applied, I find it hard to recommend an "unofficial" patch.
Your thoughts are appreciated. Please include my address on the to
line for replies.
Bill Scherr, IV GSEC, GCIA
Key fingerprint = 4687 DEB0 E772 B94F 383E 8CB2 F2FC A46D A4A2 DC71
uid Bill Scherr IV <bschnzl at cotse.net>
Learn about Intrusion Detection in Depth from the comfort of your own
send all posts to list at lists.dshield.org
To change your subscription options (or unsubscribe), see:
More information about the list