Post Reply 
Kill WMF-Exploit Files
Jan. 03, 2006, 04:19 AM
Post: #31
 
Hi Kye-U

sheesh... I had to to edit my last post twice to finally get it right. Smile!

Kye-U Wrote:Seems like we need to set a new standard when writing filters, to insert (^$TYPE(oth)) instead of leaving the URL Match blank.

I agree. In a standard web filter, the URL Match should (almost) never be without some sort of type check, (^$TYPE(oth)) if no other type is matched.

Ironically, your filter for detecting this exploit is an exception to this. But then again, it's not a standard web filter.

As for the false positive, I'm not sure there's a lot you can do about that as the shell code begins after the code your matching against. Seems like the hackers could put anything there. I think wmf's are limited to 64k, so that might be an option, but I wouldn't bet my comptuer on that without verifying it first.

Mike
Add Thank You Quote this message in a reply
Jan. 03, 2006, 04:28 AM
Post: #32
 
The only thing I can do is be more specific on what to match Wink

Since the standard header is present in every WMF file and in the WMF-Exploit, the new filter matches it, but it only matches the constants. For example, there's 10 bytes in between the constants that are based on file size and other dynamic aspects. The new filter acknowledges this, and I've specified that those 10 bytes can be any value.

I doubt there are any false positives now Smile!

Working on a header filter in my set, to make it compatible with Sidki's set. When I'm finished, I will release v4.54 of my set.
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 03, 2006, 09:29 AM
Post: #33
 
I've updated the "Update Filters" config file.
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 04, 2006, 12:48 AM
Post: #34
 
Hi Kye-U

I've modified the URL of the header filter to insure it won't match local.ptron files:

Code:
URL = "(^local.ptron/)$FILTER(true)"

Mike
Add Thank You Quote this message in a reply
Jan. 04, 2006, 12:55 AM
Post: #35
 
Thanks Mike, I will release v4.55 very soon.

Just trying to find any other bugs that I can fix Wink
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 04, 2006, 01:32 AM
Post: #36
 
Hi Kye-U

I thought a bit about the false positive & the only thing I could think of was this:

Code:
Name = "Windows: Check for WMF-Exploit Files {P} [Kye-U] {JJoe}"
Active = TRUE
Limit = 18
Match = "$STOP()[%00-%02][%00][%09][%00][%00][%03]([%00-%FF]+{10})[%00][%00]$SET(SS=1)PrxNeverMatch"


Name = "Windows: Nullify Suspected WMF-Exploit Files {P} [Kye-U] {JJoe}"
Active = TRUE
Limit = 4
Match = "[%26][%00-%FF][%09][%00]$TST(SS=1)"
        ""
        "$SET(\9=Malformed Meta Files can execute a trojan dropper which downloads and installs many "crapware""
        "components without the user's permission."
        ""
        "Version(s) Vulnerable: Windows"
        "http://isc.sans.org/diary.php?storyid=972)"
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.)"

By splitting the filter, you can insure that the wmf file type bytes only match at the start. Thats the only way I could think of to do that.

Thought I'd throw it out there for you to think about. I haven't actually tried this filter.

Mike
Add Thank You Quote this message in a reply
Jan. 04, 2006, 01:53 AM
Post: #37
 
The problem is that some exploit files may still work if it starts with a placeable header in front of the standard header, which I'm matching. It could also start with a clipboard header, so you can see why I'm not matching from the start Wink
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 04, 2006, 06:43 PM
Post: #38
 
Code:
[Patterns]
Name = "Windows: Nullify Suspected WMF-Exploit Files [Kye-U] {JJoe}"
Active = TRUE
Limit = 18
Match = "[%00-%02][%00][%09][%00][%00][%01-%03]([%00-%FF]+{12})$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.)"

Updated due to the update in the Exploit Source Code.

Mike, I'm still unsure on what this is:

Quote:# WORD Function; /* Function number (defined in WINDOWS.H) */

int(rand(256) << 8) + 0x26,

Is it the same as 0x##26?
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 05, 2006, 01:42 AM
Post: #39
 
Hi Kye-U

Quote:int(rand(256) << 8) + 0x26,


Generate a Random number using a seed value of 256
Left Shift the result 8 bits (1 byte)
Make it an integer
Add it to 0x0026

Since the random number has been left shifted 8 bits, the two numbers can be added with their byte values preserved.

for instance:

Random number result = 0x007F I just picked this number at random Smile!

Quote: 7F 00 (Left shifted random number)

00 26 (function code)

= 7F 26 after addition.


This result of this function will be [%00-%255][%26]

When viewing the code in a hex editor, you see the low byte first then the high byte, so to match it in proxo it looks backwards like so:

[%26][%00-%255]


Mike
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: