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. 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 |
|||
Jan. 03, 2006, 04:28 AM
Post: #32
|
|||
|
|||
The only thing I can do is be more specific on what to match
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 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. |
|||
Jan. 03, 2006, 09:29 AM
Post: #33
|
|||
|
|||
I've updated the "Update Filters" config file.
|
|||
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 |
|||
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 |
|||
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}" 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 |
|||
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
|
|||
Jan. 04, 2006, 06:43 PM
Post: #38
|
|||
|
|||
Code: [Patterns] 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) */ Is it the same as 0x##26? |
|||
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 Quote: 7F 00 (Left shifted random number) 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 |
|||
« Next Oldest | Next Newest »
|