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 (at) castlecops (dot) com [email concealed]]
Sent: Friday, December 30, 2005 3:41 PM
To: Bill Busby
Cc: Hayes, Bill; davidribyrne (at) yahoo (dot) com [email concealed]; bugtraq (at) securityfocus (dot) com [email concealed]
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,www.frsirt.com/exploits/20051228.ie_xp_pfv_metafile.pm.php;
sid:2005122802; classtype:attempted-user; rev:1;)
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 (at) castlecops (dot) com [email concealed]]
Sent: Friday, December 30, 2005 3:41 PM
To: Bill Busby
Cc: Hayes, Bill; davidribyrne (at) yahoo (dot) com [email concealed]; bugtraq (at) securityfocus (dot) com [email concealed]
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,www.frsirt.com/exploits/20051228.ie_xp_pfv_metafile.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
[ reply ]