Kill WMF-Exploit Files

[Kye-U]

Delete the old filters if you want to install these newer filters.

It uses a sophisticated matching system created by JJoe. It uses flags. If the 4 bytes are not found, it will not create a flag, and therefore the filter will fail. If they are found, then a flag is set, it won't modify these 4 bytes and the filter will continue with the next match, which matches the exploit code itself. If it matches and it sees it has matched the static header section (by testing the flag), it will then kill the exploit code and the rest of the file, rendering it useless, since the payload section is located after the exploit code (26 [00-FF] 09 00).

The only drawback is that some junk bytes are left behind (the header to the bytes before the exploit code). I couldn't come up with any solution to this, so I have updated the Alert message, saying that the file that is being download has been "nullified", and that it poses no danger.

There are many pros to this method. The lower Bytes Limit makes it much faster and easier on CPU resources. It can potentially match any file size, according to my intense tests (I inserted like 1 MB of useless code between the first 4 bytes and the exploit code, and it still matched). I also tested for any possible false positive, like a file with the exploit code before the header section match.

Also, with the header filter, it will truly match ALL files, including GIF files. However, those users who are "freezing" GIF animations, this feature won't work. JJoe had created a filter that changed the content-type of GIF files to JPEG, so it would be matched by the Web Page filter. I've decided to merge the two functions together, filter all files while setting the content type for GIF files as JPEG files in one filter, to ease the installation process.

Web Page Filter:

Code:

[Patterns]
Name = "Windows: Nullify Suspected WMF-Exploit Files [Kye-U] {JJoe}"
Active = TRUE
Limit = 18
Match = "[%00-%02][%00][%09][%00][%00][%03]([%00-%FF]+{10})[%00][%00]$SET(SS=1)PrxNeverMatch"
        "|[%26][%00-%FF][%09][%00]$TST(SS=1)"
Replace = "\k$ALERT(Suspected WMF-Exploit File Nullified on:\n\n\u\n\nProbable exploit and payload has been removed from the file.\n\nThe file is now harmless.)"

Header Filter:

Quote:[HTTP headers]
In = TRUE
Out = FALSE
Key = "Content-Type: !!!Filter All File Types {P} [Kye-U] {JJoe} (In)"
URL = "(^local.ptron/)$FILTER(true)"
Match = "(*|)image/gif(*|)$SET(1=image/jpeg)|\1"
Replace = "\1"

Test the filters using harmless WMF-Exploit files here:

http://74.53.146.215/WMF/

[z12]

Hi Kye-U

Just noticed this forum, nice.

According to http://www.whisqu.se/per/docs/wmf.htm the function code for Escape is 0x626, or in proxo filter form [%26][%06].

I mention this because they mention:

whisqu Wrote:Several record formats deviate from the basic record format by containing a data structure, rather than a data array, in the Parameters field.

so in this case, the statement

Quote:# WORD Function; /* Function number (defined in WINDOWS.H) */
0x0426, # Can also be 0x0026, 0x0626, etc...
# WORD Parameters[]; /* Parameter values passed to function */

is wrong.

So I think you want to match [%26][%06] exactly.

Be aware that I looked at some MS office metafiles and they contain this function code.

Mike

[Kye-U]

http://www.bleedingsnort.com/forum/viewt...topic=1547

Read the fourth post:

Quote:...though reports have it that changing the function ID from 0x0626 to 0x0726 will still work the exploit even though 0x0726 is not a defined function. Any one has any ideas on that?

Also, their Snort rules also seem to allow for the range:

Code:

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|"; content:"|00 00|"; distance:10; within:12; pcre:"[b]/\x26[\x00-\xff]\x09\x00/[/b]"; classtype:attempted-user; reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2002741; rev:3;)

http://www.bleedingsnort.com/cgi-bin/vie...iew=markup

And their revision comment was:

Quote:SIDs 2002733 2002741: Removed depth/within limit for header search to allow for large encapsulating 'pre-headers'.p

So this shows that exploit writers are trying to bypass filters and rules that detect this exploit by making the headers larger.

Perhaps in this case I shall max out the Bytes Limit in order to prevent any malicious file from not being matched.

What do you think?

[z12]

Hi Kye-U

I think trying to call the Escape function without coding 0x626 will not call the Escape function. Since the Escape function is what is supposed to be vulnerable, it seems they would be shooting themselves in the foot.

It would also appear that whoever wrote the snort rule matching pcre:"/\x26[\x00-\xff]\x09\x00/"; is under the misguided impression that the Escape funtion is passed parameters rather than a data structure.

I suppose that the hackers could make the header any length they want to, so any byte limit could be exceeded.

As to what the exploit code that is passed via the Escape function, I have no clue. Perhaps poster #5 at BleedingSnort is on to it but I don't know.

Also, I don't see that function defined in windows.h

Mike

[Kye-U]

I'm curious to see if 0x0426, or 0x0026, or 0x0626 work...

[Kye-U]

I think it'll be safer just to leave the range in there:

Code:

[Patterns]
Name = "Windows: Kill Suspected WMF-Exploit Files [Kye-U]"
Active = TRUE
Limit = 32767
Match = "$STOP()*[%01-%02][%00][%09][%00]*[%26][%00-%FF][%09][%00]"
Replace = "\k$ALERT(Suspected WMF-Exploit File Killed on:\n\n\u)"

[Guest]

Perhaps you can modify a safe wmf and see if it breaks or works.

Mike

[z12]

Kye-U Wrote:I think it'll be safer just to leave the range in there:

I think that may not be a good idea, unless you test it first.

Mike

[Kye-U]

I'm assuming Frank Knobbe, Blake Harstein and Brandon Franklin all know their stuff

[Kye-U]

From v1.3-1.5 of their Snort rules, they've added the ranges:

http://www.bleedingsnort.com/cgi-bin/vie...h_tag=MAIN

[z12]

I'm sure they are snort wizzards.

Mike

[Kye-U]

Prototype filters. Delete the old filters if you want to install these newer filters.

It uses a sophisticated matching system created by JJoe. It uses flags. If the 4 bytes are not found, it will not create a flag, and therefore the filter will fail. If they are found, then a flag is set, it won't modify these 4 bytes and the filter will continue with the next match, which matches the exploit code itself. If it matches and it sees it has matched the static header section (by testing the flag), it will then kill the exploit code and the rest of the file, rendering it useless, since the payload section is located after the exploit code (26 [00-FF] 09 00).

The only drawback is that some junk bytes are left behind (the header to the bytes before the exploit code). I couldn't come up with any solution to this, so I have updated the Alert message, saying that the file that is being download has been "nullified", and that it poses no danger.

There are many pros to this method. The lower Bytes Limit makes it much faster and easier on CPU resources. It can potentially match any file size, according to my intense tests (I inserted like 1 MB of useless code between the first 4 bytes and the exploit code, and it still matched). I also tested for any possible false positive, like a file with the exploit code before the header section match.

Also, with the header filter, it will truly match ALL files, including GIF files. However, those users who are "freezing" GIF animations, this feature won't work. JJoe had created a filter that changed the content-type of GIF files to JPEG, so it would be matched by the Web Page filter. I've decided to merge the two functions together, filter all files while setting the content type for GIF files as JPEG files in one filter, to ease the installation process.

Web Page Filter:

Code:

[Patterns]
Name = "Windows: Nullify Suspected WMF-Exploit Files [Kye-U] {JJoe}"
Active = TRUE
Limit = 4
Match = "[%00-%02][%00][%09][%00]$SET(SS=1)PrxNeverMatch"
        "|[%26][%00-%FF][%09][%00]$TST(SS=1)"
Replace = "\k$ALERT(Suspected WMF-Exploit File Nullified on:\n\n\u\n\nProbable exploit and payload has been removed from the file.\n\nThe file is now harmless.)"

Header Filter:

Quote:[HTTP headers]
In = TRUE
Out = FALSE
Key = "Content-Type: !!!Filter All File Types {P} [Kye-U] {JJoe} (In)"
URL = "$FILTER(true)"
Match = "(*|)image/gif(*|)$SET(1=image/jpeg)|\1"
Replace = "\1"

Test the filters using harmless WMF-Exploit files here:

http://74.53.146.215/WMF/

[Ralph]

Happy New Year and many thanks for the work you've done on this exploit . Your latest version , merged into Sidke's configuration , breaks my Gmail , Poppeeper , and Opera browser . When loading this site in Opera , I get a bunch of script . If I use IE , I have no problems surfing with the filters . When I disable your latest filters , I have no problems with Opera , Gmail or PP .

[Kye-U]

I've went on GMail with the filters and I don't notice anything not working.

Perhaps it's a conflict with another filter.

I have an idea: You could insert (^$TYPE(oth)) into the URL Match of all Web Page filters that don't contain a URL Match.

Anyways, can you post a log file, if you can, of when the page breaks? This is so I can see what filters are in use, and if they don't have a URL Match, then I think it'd be pretty easy to set a new "rule", and that's if you're not planning to match Hex in files in a filter, and have nothing in the URL Match, then you should put (^$TYPE(oth)) into the URL Match.

[Ralph]

I'll work on this and get back to you later . Thanks