If at first you don't succeed; call it version 1.0
Monday, 25 September 2006

The code for exploiting the unpatched VML vulnerability is in-the-wild for a week or so. This was enough time for Anti Virus, IPS/IDS and other reactive security products' vendors to create a signature for the in-the-wild exploit.
So, I put my hand on one of the in-the-wild and tested it using Virus Total. The results were not so good. Only 10 of 27 Anti-Viruses detected the exploit on the malicious web page.
According to ISC diary: "Some reports indicate that client-side anti-virus is not sufficient to protect, some AV apparently only catches the VML exploit code once Internet Explorer writes the temp file to disk, which can be too late.".
Now, what if the exploit is detected by the AV signatures? Are those signatures generic enough? I've decided to check it out.

I've used 5 simple methods, trying to evade being detected by the signature:
1) I've replaced the location where EIP should jump when the exploit is activated, with a different valid address.
2) I've replaced the VML element from "rect" with one of the other VML elements.
3) I've replaced the payload with a different valid shell code.
4) I've replaced the namespace key with a random key.
5) A combination of all of the above.

Please note that when I changed the code using any of the methods, the exploit still worked.

The following is the results of each evasion method, when tested using Virus Total:
1) Only 8 of the 10 Anti-Viruses detected the exploit.
2) Only 6 of the 10 Anti Viruses detected the exploit.
3) Only 5 of the 10 Anti-Viruses detected the exploit.
4) Only 5 of the 10 Anti-Viruses detected the exploit.
5) Only 1 (one!) of the 10 Anti-Viruses detected the exploit.

IPS/IDS vendors also wrote signatures for detecting exploitation of the VML vulnerability.
According to a post in the Bleeding Edge Snort forums: "this signature 2003106 that should detect a vml exploit is a bit too generic." .
I say the opposite! The signature is too specific. It can be easily bypassed, by using method 2 or method 4.

As you can see, evading AV/IPS/IDS signatures of web page exploits is too easy.

P.S. Randomization of any of the evasion methods (e.g. using a random VML element) can be implemented by using server side scripting.

[UPDATE:] H.D. Moore has published a new metasploit module for the VML vulnerability. This module uses evasion methods 2 and 4. It also uses an evasion technique I did not mention - Randomizing javascript variables. So, it will probably not be detected by most AV/IPS/IDS signatures.
[UPDATE2:] According to H.D. Moore, the new module is not detected by any of the current AV/IPS/IDS signatures. Virus Total test confirms this.

Monday, 25 September 2006 00:13:58 UTC | Comments [4] | Security#
Thursday, 28 September 2006 07:28:25 UTC
Good point in that the signature 2003106 is too specific and can be worked around with the methods you describe. However, I think it is also too generic as it would fire on any ol vml contained in a page. I think, considering this specific case, we need an enumeration of specific rules that address these evasion techniques. Do you have any suggestions on how signatures should be structured to catch these evasion techniques or specific tests signature creators should use to catch potential "evasion holes" in the signatures they create?
Thursday, 28 September 2006 08:37:47 UTC
There is no possible generic rule without implementing a fully scaled Javascript interpreter. Anything else can easily be circumvented. It's always easier to point out problematic things with an approach than to come up with a working solution. That's why so many people point and scream, but are unable to contribute in a positive manner to fix the problem or even offer protection.

Aviv, you're stating the obvious for security experts (useless effort), and show script kids the way to get undetected (morally questionable). And no I am not a fan of security by obscurity, but I am an enemy to teaching people how to do bad stuff.
Thursday, 28 September 2006 18:13:50 UTC
@Christian: frug is partially right. You will need a lexical parser to create a sort of generic rule.

@frug: Sorry, but I disagree. There are solutions out there that do the work just fine. I just point and scream about that signature based solutions are not enough. If it's too obvious for security experts, they wouldn't suggest signature based solutions for their customers, and we all agree that they do that as of today.
Thursday, 28 September 2006 19:46:26 UTC
Show me the solution on a gateway, without false positives and reasonable scan times/performance which detect all types of obfuscation... Snort rules certainly cannot be what you mean ;) I've had a look at them, and they are ridiculously inefficient both in reliability and false positives.

Gateway scanners at their ISP still are the only line of defense for many careless/unknowing users.
Comments are closed.     
Send me an Email
Follow me on Twitter
RSS Feeds
Admin Login
Sign In
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.