[Dshield] WMF - SETABORTPROC alarms

Fielder, Wayne (CPE) Wayne.Fielder at ky.gov
Tue Jan 3 18:49:40 GMT 2006

A couple things really jumped out at me in Mr. Scherr's note, the idea that
"safe computing" might mitigate this and the idea that propogation isn't a
serious issue with this thing.

First, on Safe Computing Mr. Truitt hits the packet on the header, not
everyone has or does practice perfect standards all the time.  I would wager
that everyone one of us has a machine or two that we would LOVE to tighten
up but because of policy, business case, or personalities we simply can't
and that machine is watched like a hawk.  It may be that machine or one of
our Road Warriors that brings this "visitor" into our networks.  

The idea of following "Best Practices" is the ideal and one worth pursuing.
Unfortunately most of us can't reach that golden ring all the time.

Second, the propogation of this thing could explode at any minute.  As with
coding anything, it's an exercise in lego building.  We take a piece of this
and a piece of that to make what we want.  Vx coders are no different and I
can almost hear the keystrokes as I type this.  What we have seen up till
now is the same PoC with different shell code.  Metasploit is a wonderful
tool and soon someone will come up with the shell to transport this thing.

This vulnerability is just screaming for a reliable transport agent.  I'm
betting on one of the IM applications as the primary target with email
attachments(the bane of everyone's existence) a close second.

Wayne Fielder GSECG, GCIHG

Join the Plain Text Email Campaign!

-----Original Message-----
From: list-bounces at lists.dshield.org [mailto:list-bounces at lists.dshield.org]
On Behalf Of Ed Truitt
Sent: Monday, January 02, 2006 2:26 PM
To: General DShield Discussion List; bschnzl at cotse.net
Subject: Re: [Dshield] WMF - SETABORTPROC alarms

My analysis/response/commentary is included, in line with your email.

bschnzl at cotse.net wrote:

>   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.
Over 50 variants (separate exploits) within about a 48-hour period pretty
much sets a record.  This one appears to affect EVERY VERSION OF WINDOWS,
starting with Windows 3.0.  It was a design feature, for crying out loud!  I
think this one will be far worse than any previous exploit/attack, once all
is said and done.  We will probably be dealing with this for years to come,
and in fact may never know exactly how many machines were compromised.
IMHO, this is a very serious issue, indeed, and one that we ignore at our

>   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.
There are, however, some reports of automatic propogation ("worm" 
activity).  And, this thing is getting spammed through email and IM, and 
unfortunately people insist on clicking on those links, despite what we 
tell them not to do.

>   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.
However, some applications (such as Google Desktop) will open the file 
enough to trigger the vulnerability.  Consider it "semi-automatic" 
propogation, at least.

>   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.
True.  However, servers still get compromised, which means someone isn't 
paying attention to all that training that have been getting.  Plus, too 
many administrators are given it as an "additional duty", with minimal 
training involved.

>   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.
True.  HOWEVER, if the payload is yet another exploit which allows code 
execution in the SYSTEM context, the machine is 0wn3d.

>   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.
Most of us know this, but too many NetBIOS (Windows Networking) 
connections to the Internet still exist.

>   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.
More than marginal, IMHO.  Road Warriors bringing bad stuff in from the 
outside is probably how most of the recent attacks have gotten into my 
employer's network, right alongside the uncontrolled (and strictly 
against policy) Internet access points.

>   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.  
If we all practiced safe computing 100% of the time, I might agree with 
you.  However, seeing what Blaster, Zotob, Slammer, and their kind have 
done to networks that have been (or should have been) secure, I don't 
take any comfort at all in these facts.  In general, I agree that 
"unofficial" patches should be avoided if at all possible.  In fact, I 
am not going to recommend to my employer that we deploy this 
"unofficial" patch.  However, I do think (and will recommend) that we at 
least review it, so that we have something available in case things blow 
up in our faces.  Spend a lot of effort on it?  Probably not, but if 
Microsoft doesn't release an 'official' patch this coming January, and 
if the number of exploits continues to grow, I don't see that I can 
recommend simply sitting on our hands.  As far as unregistering the DLL 
that is vulnerable, I am going to recommend we have that available as an 
option, as Microsoft includes it as a workaround in their security 
advisory.  Again, YMMV.

>Bill Scherr, IV  GSEC, GCIA
>Jericho, VT
>Key fingerprint = 4687 DEB0 E772 B94F 383E  8CB2 F2FC A46D A4A2 DC71
>uid Bill Scherr IV <bschnzl at cotse.net>
>KID 0xA4A2DC71

Ed Truitt
PGP fingerprint:  5368 D25E 468C A250 9833  CCD6 DBAE 9C25 02F9 0AB9

"Note to spammers:  my 'delete' key is connected to YOUR ISP.
 Also, if you send me UCE, I reserve the right to post your spew
on my Web site, with the appropriate color commentary, so that
others may have a good laugh at your expense."

Learn about Intrusion Detection in Depth from the comfort of your own couch:

send all posts to list at lists.dshield.org
To change your subscription options (or unsubscribe), see:

More information about the list mailing list