Onderwerp: WMF Exploit

Another quick observation, again, I apologize if this information has already been posted; I haven’t been able to read all the posts today. The thumbnail view in Windows Explorer will parse the graphics files in a folder, even if the file is never explici
tly opened. This is enough to trigger the exploit. Even more frightening is that you don’t have to use the thumbnail view for a thumbnail to be generated. Under some circumstances, just single-clicking on the file will cause it to be parsed.

David Byrne

CERT now has posted Vulnerability Note VU#181038, "Microsoft Windows may
be vulnerable to buffer overflow via specially crafted WMF file"
(http://www.kb.cert.org/vuls/id/181038). The note provides additional
details about the exploit and its effects. Very few workarounds have
been proposed other than blocking at the perimeter and possibly
remapping the .wmf extension to some application other than the
vulnerable Windows Picture and Fax Viewer (SHIMGVU.DLL).

Bill...

-----Original Message-----
From: davidribyrne@yahoo.com [mailto:davidribyrne@yahoo.com]
Sent: Wednesday, December 28, 2005 4:18 PM
To: bugtraq@securityfocus.com
Subject: WMF Exploit


Another quick observation, again, I apologize if this information has
already been posted; I haven't been able to read all the posts today.
The thumbnail view in Windows Explorer will parse the graphics files in
a folder, even if the file is never explicitly opened. This is enough to
trigger the exploit. Even more frightening is that you don't have to use
the thumbnail view for a thumbnail to be generated. Under some
circumstances, just single-clicking on the file will cause it to be
parsed.

David Byrne

The problem with the temp fix so far (regserv32 /u etc.dll) is that
after the fix you can no longer see thumbnail views of pictures.
Personally, its a great annoyance when trying to sort ones pictures /
pornography. Hopefully there is a better fix out.

On Thu, 29 Dec 2005, Bill Busby wrote:

> It is not only *.wmf extensions it is all files that
> have windows metafile headers that will open with the
> Windows Picture and Fax Viewer. Any file that has the
> header of a windows metafile can trigger this exploit.

Sunbelt Kerio and Bleeding Snort have put together two rules for this:

alert ip any any -> any any (msg: "COMPANY-LOCAL WMF Exploit"; content:"01
00 09 00 00 03 52 1f 00 00 06 00 3d 00 00 00"; content:"00 26 06 0f 00 08
00 ff ff ff ff 01 00 00 00 03 00 00 00 00 00"; reference:
url,http://www.frsirt.com/exploits/20051...tafile.pm.php;
sid:2005122802; classtype:attempted-user; rev:1

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BLEEDING-EDGE EXPLOIT
WMF Escape Record Exploit"; flow:established,from_server; content:"01 00
09 00 00 03"; depth:500; content:"00 00"; distance:10; within:12;
content:"26 06 09 00"; within:5000; classtype:attempted-user;
reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002733;
rev:1

Simply add it to Sunbelt Kerio's bad-traffic.rlk file, or download it:

http://castlecops.com/p687296-.html#687296

--
Paul Laudanski, Microsoft MVP Windows-Security
[cal] http://events.castlecops.com
[de] http://de.castlecops.com
[en] http://castlecops.com
[wiki] http://wiki.castlecops.com
[family] http://cuddlesnkisses.com

Apologies if you've already read this, but this is interesting news:

Apparently shimgvw.dll isn't the problem; according to the Kaspersky
Lab blog, gdi32.dll is.

From http://www.viruslist.com/en/weblog?d...530&return=3D1
(which talks about an IM worm that uses this):

"Going back to the wmf vulnerability itself, we see number of sites
mention that shimgvw.dll is the vulnerable file.
This doesn't seem correct as it's possible to exploit a system on
which shimgvw.dll has been unregistered and deleted. The vulnerability
seems to be in gdi32.dll."

I've tested the exploit on XP home and I've found that it does not even need a single click on my machine. Once the folder containing the file is open (this was in list view) the exploit will run.

Scary sh*t!

--=-BG6hkRzLxtFxR2Scphpe
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2005-12-30 at 15:40 -0500, Paul Laudanski wrote:
> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BLEEDING-EDGE EXPLOIT=20
> WMF Escape Record Exploit"; flow:established,from_server; content:"01 00=20
> 09 00 00 03"; depth:500; content:"00 00"; distance:10; within:12;=20
> content:"26 06 09 00"; within:5000; classtype:attempted-user;=20
> reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002733;=20
> rev:1=20

This signature is outdated and can be evaded easily. Get the latest
version from
http://www.bleedingsnort.com/cgi-bin...EVENTS/CURREN=
T_WMF_Exploit?only_with_tag=3DHEAD&view=3Dmarkup

Also, make sure you read the important note on this sig (before you
wonder why it doesn't alert) as outlined in the bleeding-sigs mail list.
In case you missed that post, here again.

---8<---

Greetings,

below is a revised version of the Snort signatures for the WMF issue:

Web Only:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EXPLOIT WMF
Escape Record Exploit - Web Only"; flow:established,from_server;
content:"HTTP"; depth:4; nocase; content:"|00 09 00 00 03|"; within:500;
content:"|00 00|"; distance:10; within:12; pcre:"/\x26[\x00-\xff]\x09
\x00/"; classtype:attempted-user;
reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002741;
rev:2

All Ports:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"EXPLOIT WMF Escape
Record Exploit"; flow:established,from_server; content:"|00 09 00 00
03|"; depth:800; content:"|00 00|"; distance:10; within:12;
pcre:"/\x26[\x00-\xff]\x09\x00/"; classtype:attempted-user;
reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002733;
rev:3


Credits to Blake Harstein and Brandon Franklin for their cooperation
with us on further refinement and on-going improvement of the
BleedingSnort rules.

There is one important note in regards to ALL published signatures=20
including this one. All these signatures will fail to detect the
exploits when the http_inspect preprocessor is enabled with default
settings. My default, the flow_depth of the preprocessor is 300 which is
too short to cover the whole exploit. Should the exploit be transmitted
on port 80 and http_inspect is enabled, no alert will occur. Note that
it will still alert on any ports (using the all port sig below) that are
not configured in http_inspect (ie FTP).

One solution is to add the statement "flow_depth 0" to the http_inspect
preprocessor. This will tell the preprocessor not to truncate the
reassembled pseudo-packet, but it will have an adverse impact on
performance. On busy networks, this will lead to 100% CPU utilization of
the Snort process and major packet drops.

So we're between a rock, a solid surface, and a hard place. The exploits
are web based, yet the signature will fail with http_inspect enabled.
With it disabled, Snort will miss all rules containing uricontent and
pcre/U statements. With it enabled, and flow_depth set to 0, Snort will
alert on the exploit, but also process all uricontent rules in such a
fashion that its CPU utilization is skyrocketing.

The only viable solution at this point is to run two instances of Snort.
One with your normal set of rules and http_inspect enabled with either
the default or "sane" values for flow_depth. The second instance should
run with http_inspect disabled or flow_depth set to 0, and process only
rules that have to cover a larger than 300 byte area for content matches
on ports configured in http_inspect. This two-pronged approach assures
that Snorts performance is kept at normal levels, preventing packet
loss.


Have a good weekend and a great New Year!
Frank


--=20
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.


--=-BG6hkRzLxtFxR2Scphpe
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQBDtbiNwBQKb2zelzoRAjX9AJwK7h8KcoOhTISu++Eya5 E/1BClHwCfRuyZ
UjgnVfWUxwoMrbek9xRM0JY=
=ocYn
-----END PGP SIGNATURE-----

--=-BG6hkRzLxtFxR2Scphpe--

Taking a look at the first rule, it looks like it would be ineffective to
prevent a slightly modified exploit image. The first "content:" attribute
looks for a hardcoded wmf header, including the dword 00 00 1f 52 (remember
dwords are backwards in memory) filesize property. This is obviously going
to change if the attacker changes the shellcode (I think it might even be
ignored and automatically calculated).

Also, the second image includes the windows version property (0x0300). I'm
not sure if the image renderer even pays attention to this. It may, but it's
just something you should pay attention to.

I just wanted to bring this to everyone's attention. I don't know the layout
of the rules, but I just recognized that first hex string as a wmf image
header.

Regards,
Paul
Greyhats Security


-----Original Message-----
From: Paul Laudanski [mailto:zx@castlecops.com]
Sent: Friday, December 30, 2005 3:41 PM
To: Bill Busby
Cc: Hayes, Bill; davidribyrne@yahoo.com; bugtraq@securityfocus.com
Subject: Re: WMF Exploit

On Thu, 29 Dec 2005, Bill Busby wrote:

> It is not only *.wmf extensions it is all files that
> have windows metafile headers that will open with the
> Windows Picture and Fax Viewer. Any file that has the
> header of a windows metafile can trigger this exploit.

Sunbelt Kerio and Bleeding Snort have put together two rules for this:

alert ip any any -> any any (msg: "COMPANY-LOCAL WMF Exploit"; content:"01
00 09 00 00 03 52 1f 00 00 06 00 3d 00 00 00"; content:"00 26 06 0f 00 08
00 ff ff ff ff 01 00 00 00 03 00 00 00 00 00"; reference:
url,http://www.frsirt.com/exploits/20051...tafile.pm.php;
sid:2005122802; classtype:attempted-user; rev:1

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BLEEDING-EDGE EXPLOIT
WMF Escape Record Exploit"; flow:established,from_server; content:"01 00
09 00 00 03"; depth:500; content:"00 00"; distance:10; within:12;
content:"26 06 09 00"; within:5000; classtype:attempted-user;
reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002733;
rev:1

Simply add it to Sunbelt Kerio's bad-traffic.rlk file, or download it:

http://castlecops.com/p687296-.html#687296

--
Paul Laudanski, Microsoft MVP Windows-Security
[cal] http://events.castlecops.com
[de] http://de.castlecops.com
[en] http://castlecops.com
[wiki] http://wiki.castlecops.com
[family] http://cuddlesnkisses.com

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 12/30/2005


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 12/30/2005