Post Reply 
Kill WMF-Exploit Files + Log Config File
Dec. 31, 2005, 02:36 AM
Post: #1
Kill WMF-Exploit Files + Log Config File
What is this?

This is basically the same filter that kills WMF-Exploit files, but it also keeps a tab on where those files are located (in a log file).

Handy for those who want to know what sites to block... *cough* hpguru *cough* Pervert

Many thanks to Shea for bringing this idea up!

How do I install it?

Once you've downloaded the file (attachment), follow these easy steps:

1. Open the ZIP file with an archive program of your choice.

2. In Windows Explorer, locate the folder where "Proxomitron.exe" is located.

3. Extract everything in the ZIP file to the same folder where "Proxomitron.exe" is located.

4. Click Yes, when the message "This folder already contains a folder name 'Lists'" pops up. Don't worry, this won't delete any existing lists.

5. Open Proxomitron, and go to File, then Load Config File.

6. Select "WMF.cfg", and open it.

7. Start surfing around like an unmarried illegal blind non-safe-hex practising male duck Smile!

How do I view the log file?

Go to the folder where "Proxomitron.exe" is located.

Open the "Lists" folder.

Open the "WMF" folder.

Open the "WMF.txt" text file.

Presto!

ProxoPatch Users

There is an even easier way to view what you've got in your collection!

Right-click on Proxomitron's system tray icon.

Move your mouse over "Edit Block Files".

In the sub-menu, click on "WMF: WMF.txt"

EDIT: This is my 1000th post! Big Teeth


Attached File(s)
.zip  Proxo.WMF.Logger.zip (Size: 1.12 KB / Downloads: 409)
Visit this user's website
Add Thank You Quote this message in a reply
Dec. 31, 2005, 03:21 AM
Post: #2
 
Hi Kye-U

You replied earlier at BBR to "isvoid" (me) that trying to match the magic byte of an infected wmf file type when using the <start> tag in the match expression didn't work. Since I don't have access to an infected wmf file, I decided to try testing for the magic byte for a zip file.

As you mentioned, this filter never matches:

Quote:[Patterns]
Name = "alert on zip file magic bytes"
Active = TRUE
URL = "$TYPE(oth)"
Limit = 4
Match = "<start>[%50][%4B][%03][%04]$ALERT(zip file detected: \u)"

However, this filter does match on a zip file:

Quote:[Patterns]
Name = "alert on zip file magic bytes"
Active = TRUE
URL = "$TYPE(oth)"
Limit = 4
Match = "$STOP()[%50][%4B][%03][%04]$ALERT(zip file detected: \u)"


Since the magic byte (usually) are at the start of the file, I believe that a "one time" test for the byte sequence at the start of the file is still the safest way to go.

The hex code that I saw for an infected wmf file had the magic byte sequence at the start of the file (with the same hex vaules you are testing for). However, I ran across a snort rule for matching these files that had the following byte sequence:

Quote:[%01%02][%00][%09][%00][%00]

This would indicate to me that there may be other magic bytes that are in use for this expoit.

At any rate, I would still be cautious.


The other point that I was concerned about was the header filter enabling web filtering for all file types. While I understand that it is needed in order for the magic byte web filter to work, I still believe that this has a potential for causing other web filters to match unintentionally when all file types are filtered.

By default, proxo web filters will only match html,css,js,or vbs files. However with web filtering enabled for all file types, web filters can now match any file type. This is true unless the web filter has some sort of file type check that limits the type of file that the web filter will match on.

When I reviewed my filter set, I found probably 10 web filters that did not have any type checking since I wanted to match on any of the file types that proxo would normally filter.

What will happen when these web filters try to match on an exe? I'm not sure.

Could they find a match? Possibly.

What will proxo do when a web filter encounters a binary value/sequence that isn't found in ordinary html type files? Hmmm...

For these reasons, I have modifed my web filters so that all of them now have some sort of type checking. The most basic of these is equivalent to this:

Quote:URL = "(^TYPE$(oth))"

This seems to allow the web filters that previously had no file type checking to work normally while insuring they are not enabled for exe's and what not.


Finally, I would like to thank you for all the effort you put into creating the "Kill WMF-Exploit Files" filter. It made me rethink my web filters. Personally, I still use the URL match that you have since removed.

Mike
Add Thank You Quote this message in a reply
Dec. 31, 2005, 03:31 AM
Post: #3
 
Thank you for the matching expression Smile! It shall be in my next release. (the $STOP() and the %0102)

z12 Wrote:The hex code that I saw for an infected wmf file had the magic byte sequence at the start of the file (with the same hex vaules you are testing for). However, I ran across a snort rule for matching these files that had the following byte sequence:

Quote:[%01%02][%00][%09][%00][%00]

This would indicate to me that there may be other magic bytes that are in use for this expoit.

I've just come across "wmf_dcode.wmf" in my personal collection, and this is indeed true; it starts with %02.

Looks like I'll need to release another filter xD

It seems if Scott were alive, he would update Proxomitron so that blank URL Matches would actually be equal to (^TYPE$(oth))

Sad

You are very welcome.

I almost had a heart attack when I found out Proxomitron could match Hex values Smile!
Visit this user's website
Add Thank You Quote this message in a reply
Dec. 31, 2005, 04:46 AM
Post: #4
 
Kye-U Wrote:It seems if Scott were alive, he would update Proxomitron so that blank URL Matches would actually be equal to (^TYPE$(oth))

Yeah, that would probably save some grief.

Kye-U Wrote:I almost had a heart attack when I found out Proxomitron could match Hex values

That is very cool.

I haven't tested if the following matches are equivalent:

Quote:This: [%01%02]
vs : ([%01]|[%02])

But it seems they should be.

Mike
Add Thank You Quote this message in a reply
Dec. 31, 2005, 05:06 AM
Post: #5
 
z12 Wrote:I haven't tested if the following matches are equivalent:

Quote:This: [%01%02]
vs : ([%01]|[%02])

But it seems they should be.

They are Smile!

It's also equivalent to [%01-%02]

Upon some good research, I've decided to exclude matching headers, since they can vary, and instead hunt for a juicy section.
http://www.whisqu.se/per/docs/wmf.htm

It seems as though \x26[\x00-\xff]\x09\x00 is the actual exploit.

Here is a filter I'm happy with:

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

The Bytes Limit is so big because in Enhanced headers, you are allowed an unlimited description, which is stupid I think.

But assuming crapware people would want their WMF (or whatever file) to be as small and fast to download as possible, I've made it 1024.

Also, I've made it specific in the sense that I included the four "static" bytes.

It's also identical to Frank Knobbe's latest Snort filter:

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

(Well, not identical, but it's a Snort to Proxomitron conversion I think Wink
Visit this user's website
Add Thank You Quote this message in a reply
Dec. 31, 2005, 05:44 AM
Post: #6
 
That looks good. Now all I have to do is finish reading up on snort rules. Smile!

Mike
Add Thank You Quote this message in a reply
Dec. 31, 2005, 08:40 AM
Post: #7
 
Code:
[Patterns]
Name = "Windows: Kill WMF-Exploit Files [Kye-U]"
Active = TRUE
Limit = 32767
Match = "$STOP()*[%01-%02][%00][%09][%00]([%00-%FF]+{460})[%26][%00-%FF][%09][%00]"
Replace = "\k$ALERT(Infected WMF-Exploit File Killed on:\n\n\u)"

I've made sure the Matching Expression is very specific to prevent any false positives. (Requires there to be 460 bytes between the first 4 bytes and the end 4 bytes. This is because of the maxed out Bytes Limit.

Again, I experience no speed decrease when surfing on image-intensive sites.

I will wait for some feedback before going ahead and implementing this in my Security Pack.
Visit this user's website
Add Thank You Quote this message in a reply
Dec. 31, 2005, 07:26 PM
Post: #8
 
Hi Kye-U

Well, after checking todays updates on the the wmf file exploit, I've decided to just block wmf files until MS issues an update.

I don't think there is any way to keep up with the possible variations of this exploit. Also, since wmf files are not very common, I don't think it's worth the effort.

With that in mind, I've modified one of your filters like so:

Code:
Name = "Block WMF Files [Kye-U]"
Active = TRUE
URL = "$TYPE(oth)"
Limit = 4
Match = "$STOP()"
        "([%D7][%CD][%C6][%9A]|[%01][%00][%09][%00])"
Replace = "\k$ALERT(.WMF File Killed on:\n\n\u)"

This should catch wmf files, whether it's a placeable metafile or a standard metafile.

Mike
Add Thank You Quote this message in a reply
Dec. 31, 2005, 07:27 PM
Post: #9
 
Please see my new filter in the FIP Section Wink

I need some comments before I update my Security Pack.
Visit this user's website
Add Thank You Quote this message in a reply
Dec. 31, 2005, 10:26 PM
Post: #10
 
Updated this filter with better matching expression.
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 02, 2006, 10:29 AM
Post: #11
 
Updated again.
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 03, 2006, 09:55 AM
Post: #12
 
Updated again Wink
Visit this user's website
Add Thank You Quote this message in a reply
Jan. 07, 2006, 10:13 PM
Post: #13
 
Updated again.
Visit this user's website
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: