Can HIPS Such as DefenseWall or Online Armor Guard Against the WMF Exploit?

Can HIPS such as DefenseWall or Online Armor guard against the wmf exploit? Any comments or opinions would be greatly appreciated regarding this matter.


Peace & Love,

CogitoErgoSum

 

There are at least two approaches to guarding against this exploit:

1) block the wmf file from downloading/caching

See the ongoing thread at BBR about the various methods, including KyeU's great work and test site (also mentioned here in the Security forum); and the various patches available. Many AVs now catch it but it is a cat-and-mouse game to keep up with the continuous variants.

2) block the wmf file from carrying out its payload.

I know of the following successful ways of preventing the executing of the payload - product and number of users reporting:

BOClean (3)
Process Guard (2)
Anti-Executable (2)
Winsonar (2)​

It would be interesting to see which other such products have also blocked. I would guess that the two you mention would.

Note that these were successful at a known site with the exploit, where the wmf file was blocked from letting a trojan dropper install or run.


said by catseyenu in the BBR thread:

"From what I'm hearing.. this metasploit is just a newer version/built upon of the '03 version Internet Explorer/Windows Media Player WMF Overflow exploit which used/allowed a little over 5K of memory. Enough for pretty much any trojan downloader to go and grab something real.

The latest, as of December 27th, only allows about 1.7K and there's only a few downloaders that can be collapsed into such a small size. A few scriptings have been used and worked, but the favorite method is to use something really small and compact. All it's really worth is running a downloader to grab a real trojan, the hole is too small to do much of anything else with.

So, if you have the downloaders and trojans covered... it's a non-event."​

said by ZOverLord:

"Yep the Framework for this was actually done and used on June 4, 2003 and now used again, with different versions since 27, Dec, 2005"​

________________
~~Be ALERT!!! ~~

 

Here is Defensewall against the exploit you have mentioned:
http://www.softsphere.com/articles/in-the-wild-intrusion-prevention/

 

Thanks Rmus and toadbee for your input.


Peace & Love,

CogitoErgoSum

 

This method doesn't seem to me to be considered as really guarding against the exploit. Particularly not in the case of PG,AE,Winsonar which require whitelisting of exes.

I would also think that Boclean is catching of the payload is situational, wouldn't it be possible for the payload to be changed so Boclean doesn't catch it? After all it's signature based.

 

KyeU's great work and test site

http://my.opera.com/community/forums/topic.dml?id=117908&page=1#comment1330125

http://kyeu.info/WMF/

 

True guarding would be blocking at 1).

If that fails, then the applications the original poster was inquiring about will stop a payload which uses a trojan dropper.

I don't know how BOClean works - I was aware of three cases where it snagged the trojan dropper.

For the others using white list - a trojan dropper.exe would be blocked from running.

As mentioned in the other thread, executing a dropper is only one type of payload, and since this thread started, already one test.wmf has demonstrated using shell code to do other things. Blocking at 2) is now no longer a reliable option

So, one is left to find a solution for 1)

Mine is to stay with my Win2K system, which seems to be not vulnerable (so far, anyway.)



________________
~~Be ALERT!!! ~~

 

How 'bout using SSM? Or Prevx home? I wonder if they would help to stop it.

I have heard of some folks using Analogx's Script Defender.
http://www.analogx.com/contents/download/system/sdefend.htm
I'm not sure it would work, but some claim it can. You have to set it to block the exploit though, it won't just do it without setting it up to do so first.

Here's some info on setting it up:

said by Libra:

BTW, how do you add the extensions WMF and EMF in Script Sentry? I went to configure>file associations and they weren't listed and I didn't see a way to add new extensions.
Sincerely, Libra

... open windows explorer (e.g., click on My Computer), select Tools, Folder Options, File types ... scroll to .emf and .wmf file extensions, under 'details' where it lists what it opens with, select 'change' and point it to ScriptSentry in the drop-down selection box (or browse to it if not listed) ... still not proven to work, but I think it's worth a shot ... when I finally got the .wmf test file past eTrust SS kicked in, so I'm hopeful ...

Above response originally posted by Antiserious on Dslreports.


The unofficial patch seems to be the best temp fix for the problem so far.
http://www.grc.com/sn/notes-020.htm

 

*Exactly* my point. Saying that such approaches block the exploit is somewhat misleading. Ditto for approaches like Defensewall, which merely migitate the damage done.

That said, in most cases, using a dropper is the most common payload since the efficiency of shellcode is strictly limited, and often eventually requires a dropper anyway.

 

That is simply not correct. In 2) I defined blocking as "preventing the executing of the payload." The applications listed were from posts by those saying the trojan dropper had been caught before executing. I tested myself 7 different sites as they became known, and had the same results. I posted three examples. To quote catseyenu again, "So, if you have the downloaders and trojans covered... it's a non-event."

There has been at least one POC, a harmless test.wmf file that starts calc.exe and shuts down Windows Explorer. What other possibilities there are for shell code in these files have yet to be demonstrated.

So, while preventing at 2) has covered all real situations so far, preventing at 1) is the only way to be completely sure.

I haven't investigated any of the workarounds/patches because I'm using Win2K and the home users I take care of also use either Win2K or Win98.


________________
~~Be ALERT!!! ~~

 

I don't care about your definitions, I'm trying to make a point.

Of course, i'm not saying it didn't stop the payload, but that's utterly different from stopping the exploit! And yes most common uses of the exploit make it a none event. But this is just incidental.

As TNT has taught you the lesson in another thread "Zero exploit are you ready?", the exploit can damage you by overwriting files, without using a trojan payload. There can be a lot of cleverer things it can do
as well.

LOL, do you even know what shellcode is? It's equiavalent to scripts. Now tell me what can you do with scripts.... Lots...There are dozens of possbilites , only limited by size, and even then there are methods that work around this size limit without triggering your AE. I have seen examples personally.

Thinking of Clever things to do with the attack code is (normally) seperate from the issue of the exploit...... For most part, most people don't borther to think of clever things to do because few people use Antiexecutables so it's just easier just to use a dropper.

The only reason your precious AE protects you is because, most users do not use such methods, so few people borther to work around it and just do the simple thing of using a dropper. If an attacker was targetting you, you can bet the shell code could do a lot more than just opening notepad!

My point is not to spread fear and discourage people from using Antiexecutable, but a much more important point, it's much better to stop the exploit from working in the first place, then relying on Anti exectuables after the exploit has triggered.

As some one used to like to say Prevention is better than cure. Blocking the dropper is like stopping the symptom (granted early symptom) but it's better to not get sick at all.

Your obvious fondness for antiexectuable has blinded you to to the major difference between the two.

 

I'm sure I made that point quite clear.




________________
~~Be ALERT!!! ~~