Avivra, I acknowledge the research you and Ertunga (http://www.immunitysec.com/pipermail/dailydave/2006-September/003557.html) have put up. Protection against client-side scripting vulnerabilities is the Achilles' Heel for all network-style IDS/IPS vendors. These languages offer too much flexibility over the syntax and semantics, thus becoming the pain-point for the underlying architecture for network-style IDS/IPS which are better accustomed to analyze structured data (like protocols and even file-formats). There's is simply too much you can mutate here and you can't expect vendors to develop on-the-fly javascript parsers! Thus the protection they develop is simply a business objective, as they can loose a lot mileage here if they don't cover vulnerabilities like this one. They had the same stance for file-format vulnerabilities till they were forced to add decoding routines for them by the sheer number of new file-based vulnerabilities which were coming out. AV and local-style protection is the best defense mechanism here (but even they failed in this case!). However, the other way out is to gather the maximum number of exploit variants as you can (from mutual cooperation between security companies) and provide real-time exploit-facing protection against them. This is what they generally do and it provides almost 99% protection (might surprise many) because most out-in-the-wild exploits are derived from few sources only. Thanks, Pukhraj On 9/26/06, avivra <avivra@xxxxxxxxx> wrote:
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. 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. More info: http://aviv.raffon.net/2006/09/25/VMLExploitVsAVIPSIDSSignatures.aspx -- Aviv.
