New exploit
On New Year's eve the defenders got a 'nice' present from the full disclosure community.
The source code claims to be made by the folks at metasploit and xfocus, together with an anonymous source.
Note: We have been able to confirm that this exploit works. We are in the process of getting information to AV vendors ASAP. We can also confirm that having the file and simply opening the directory can be enough to get the exploit running.
The exploit generates files:
* with a random size;
* no .wmf extension, (.jpg), but could be any other image extension actually;
* a random piece of junk in front of the bad call; carefully crafted to be larger than the MTU on an ethernet network;
* a number of possible calls to run the exploit are listed in the source;
* a random trailer
From a number of scans we did through virustotal, we can safely conclude there is currently no anti-virus signature working for it. Similarly it is very unlikely any of the IDS signatures for the previous versions of the WMF exploits work for this next generation.
Judging from the source code, it will likely be difficult to develop very effective signatures due to the structure of the WMF files.
Infection rate
McAfee announced on the radio yesterday they saw 6% of their customer having been infected with the previous generation of the WMF exploits. 6% of their customer base is a huge number.
Yellow
Considering this upsets all defenses people have in place, we voted to go to yellow in order to warn the good guys out there they need to review their defenses.
We hate going back to yellow for something we were yellow on a couple of days ago and had returned to green, but the more we look at it and the uglier it gets.
UNofficial patch
We want to be very clear on this: we have some very strong indications that simply un-registering the shimgvw.dll isn't always successful. The .dll can be re-registered by other processes, and there may be issues where re-registering the .dll on a running system that has had an exploit attempted against it will cause the exploit to succeed.
For those of you wanting to try an unofficial patch with all the risks involved, please see here. (md5 99b27206824d9f128af6aa1cc2ad05bc)
Initially it was only for Windows XP SP2. Fellow handler Tom Liston worked with Ilfak Guilfanov to help confirm some information required to extend it to cover Windows XP SP1 and Windows 2000.
Note: Tom has taken this thing apart and looked at it very, very closely. It does exactly what it advertises and nothing more. The wmfhotfix.dll will be injected into any process loading user32.dll. It then will then patch (in memory) gdi32.dll's Escape() function so that it ignores any call using the SETABORTPROC (ie. 0x09) parameter. This should allow for Windows to display WMF files normally while still blocking the exploit. We want to give a huge thanks to Ilfak Guilfanov for building this and for allowing us to host and distribute it.
Note #2: When MS comes out with a real patch, simply uninstall this from Add/Remove programs on the Control Panel. Mr. Guilfanov did a great job with this ...
Patching with unofficial patches is very risky business, this comes without any guarantees of any kind.
Please do back out these unofficial patches before applying official patches from Microsoft.
Belt and suspenders
There is possibility to do the proven belt and suspenders approach here. Using the unofficial path and using the workaround from Microsoft together. Just remember to unto the damage done before applying any official patch for this vulnerability.
New Snort signatures
We are receiving signatures from Frank Knobbe that detect this newest variant, but we haven't done much testing for false positives or negatives at this point.
http://www.bleedingsnort.com/...
Frank also restated some warnings:
There is one important note in regards to ALL published signatures including this one. All these signatures will fail to detect the exploits when the http_inspect preprocessor is enabled with default settings. By default, the flow_depth of the preprocessor is 300 which is too short to cover the whole exploit. Should the exploit be transmitted on port 80 and http_inspect is enabled, no alert will occur. Note that it will still alert on any ports (using the all port sig below) that are not configured in http_inspect (ie FTP).
One solution is to add the statement "flow_depth 0" to the http_inspect preprocessor (actually the appropriate http_inspect_server line in the config). This will tell the preprocessor not to truncate the reassembled pseudo-packet, but it will have an adverse impact on performance. On busy networks, this will lead to 100% CPU utilization of the Snort process and major packet drops.
So we're between a rock, a solid surface, and a hard place. The exploits are web based, yet the signature will fail with http_inspect enabled. With it disabled, Snort will miss all rules containing uricontent and pcre/U statements. With it enabled, and flow_depth set to 0, Snort will alert on the exploit, but also process all uricontent rules in such a fashion that its CPU utilization is skyrocketing.
The only viable solution at this point is to run two instances of Snort. One with your normal set of rules and http_inspect enabled with either the default or "sane" values for flow_depth. The second instance should run with http_inspect disabled or flow_depth set to 0 (in the appropriate http_inspect_server config line), and process only rules that have to cover a larger than 300 byte area for content matches on ports configured in http_inspect. This two-pronged approach assures that Snorts performance is kept at normal levels, preventing packet loss.
Overview
A chronological overview of all WMF related articles on this site.
Thanks
Thanks to all handlers working on this today, especially Lorna, Tom, Kevin, Jim, Scott and all those I forgot. This was a cooperative effort.
Wishing all windows machines, their users, owners and administrators a happy New Year, with a bit fewer nasty exploits.
