* New exploit released for the WMF vulnerability - YELLOW
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
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 15f0a36ea33f39c1bcf5a98e51d4f4f6), PGP signature (signed with ISC key) here.
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.FAQ
We are maintaining a FAQ on the WMF vulnerability.Thanks
Thanks to all handlers working on this today, especially Lorna, Tom, Kevin, Jim, Scott, Daniel, Patrick 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.
--Swa Frantzen
Leap Second
From extreme to in depth
I'm also not trying to bash on Microsoft. If I were I'd have borrowed a subject of some spam message I got recently: "forget microsoft, get big and hard". I'm just trying to show how you can come from an extreme reasoning to a workable solution to protect those assets that need protection.
Suppose you defend a place that has high to very high security needs and wants to avoid the wmf thing at all cost. Reasons to do this should be based on a risk assessment, but elements that might lead to such extreme conditions might include:
- No patch in sight from Microsoft
- Not wanting to infect peers such as customers
- Not wanting to rely on anti-virus signatures when people are developing versions of the exploit with a highly random nature
- Not wanting to rely on IDS devices due to the same randomness and the "it's too late already" aspect
- Ban Microsoft products in your environment
- I told you we were going to start from the extreme viewpoint, so hold your horses.
- What does it buy?
- No windows, no windows WMF vulnerability
- What does it not buy?
- You still can pass on dangerous payload to others like to your customers.
- If a single escaped machine remains or a single machine snuck back in, you still might get affected.
- Ban all communication and/or file exchanges
- Extreme again isn't it? Moreover it is perceived very hard in a modern world.
- What does it buy you?
- You prevent yourself from getting and giving dangerous payload to all peers
- What does it not buy you?
- If a single file would sneak in, or be present already, you might still have a major problem
- You have sacrificed a lot of the availability to gain confidentiality and or integrity
Most of our readers do not have the extreme "at all cost" risk situations.
Most of us have a situation where we have a business, and the business must continue to operate. In such a business however you will identify -if you look for it- areas that might need more protection and are willing to sacrifice more for that protection than other parts of the same business. That difference in need for protection is what you can play on to do something.
E.g.: Suppose I know the accounting department was considered sensitive and due to the risk analysis performed, worthy of more extreme measures then other departments.
What could I try to do to use some of the very extreme ideas and build a safer solution for them now and in the next weeks ?
- Isolate them frmm the rest of the company. Plug a firewall between them and the rest of the internal networks. Disallow all unneeded communication with the rest of the company, making sure their servers are on their new inside.
- Use advanced networking solutions to prevent (accidental) hookup of unauthorized equipment to the sensitive network. E.g.:
- Make sure switch ports automatically shut down when try try to learn a second MAC address
- Assign only DHCP addresses to known MAC addresses
- Kick unknown MAC addresses into a separate VLAN
- Use layer 2 measures (such as private VLANs) to prevent client-to-client communication
- Disallow dangerous usage:
- Disallow IM
- Disallow web surfing
- Disallow email, or strip all attachments from the more secure email server they get access to.
- Now no surfing, no email, ... etc can be hard on the users and they might have really good arguments to have the functionality back.
- Build a second less sensitive network on different infrastructure
- Add machines for those that need the web/email/...
- Allow them to surf the web (with traditional restrctions) on those "less" secure machines but not on the "sensitive" machines which are to be used exclusively for their sensitive application(s).
- Be very procedural and build the needed infrastructure if you want to allow transfers between the two environments.
- The more traditional stuff should not be forgotten, especially not on the more secure side:
- Take a tough stance on updating Anti-virus signatures
- Look for unregistering the DLL as per Microsofts suggestion
- May be consider an unofficial patch from some reputable source
- Look for other platforms
- This is hard as training users to switch platforms takes time, and worse applications might not have clients for other platforms that work properly. Still it's one way out of the de-facto monoculture of operating systems and related vulnerabilities. We know from agriculture monoculture has risks. If we want not to accept the risks we need to act on it as well.
- Look for other strongholds to build
- If you have more than one sensitive section in you company, build more of these strongholds, do not build larger ones.
- More smaller ones will contain the spread of infections and the associated risks and costs in clean up better under control.
Add to that that families of nobles get their own donjon so as not to risk all nobles getting wiped out in one go should disease strike the city.
UPDATE We received some suggestions to help far less extreme than what is above here. However I feel it is hard to actually recommend any of them as the protection it might give has a huge risk of giving a false sense of security. Yet for soem organisations it might be what does the trick for them ...
- Allowing only non windows machines to acces the Internet was suggested as an approach. While it might protect that machine, the downloaded files might easily migrate to the windows machines and as such be a risk regardless. Also users might find a way to tunnel thtough the allowed machines. But as always it gives something and for some environments it might help to mitigate the risk.
- Remote display clients from a windows desktop to a unix server was suggested. While it might work again some of the tools have file transfer capabilites and/or accellerate the display by using the graphical power in the workstation. You will never be sure the windows machines are fully secure. But it might help in some environments to mitigate some of the risk without giving much assurances.
Swa Frantzen
New IM Worm Exploiting WMF Vulnerability
Kaspersky Lab Blogs
Be very careful when opening the New Years Greetings that you receive folks. We wouldn't want you to have to spend the rest of your holiday weekend rebuilding your computer.
Thanks to Juha-Matti for providing the information.
2006 Predictions
From Dan:
* Trojans outpace worms
From Jeremy:
I believe that one of the
biggest threats are going to be insecure databases. The proof of concept database worm that was
released about a month or so ago is just the very beginning of what we will see
over the next year+. To me this is a
very real problem as I have audited environments where there was a huge focus
on securing hosts and servers, but zero or minimal focus on securing the
database.
From Jim:
My 2006 predictions/paranoid
phobias:
- "Zero-Day" exploits that are discovered and exploited by The Bad Guys, with no one being the wiser until it is far, far too late; 2. Tightly-targeted malware (currently being used) that, once it gleans information from financial institutions, allows the attacker(s) to then completely trash the entire information store - causing panic/chaos (if only for the targeted company(s); 3. Hackers taking the Fed's recent announcement that "the Internet is not vulnerable to widespread attack" as a personal challenge.
NOT a Quiet Day
I purchased new computers for my grown, married children and their families for Christmas. They each had really old hand me downs and it was time to get them up to date. My daughter and her husband didn't even have an email address of their own, they came to my house and used mine. So for Christmas I decided to give their families something they could really use.
Before those machines even made it under the tree - they were completely updated. (That is what I spent late Christmas Eve doing). I installed a software firewall program and antivirus program on them as well as AdAware and Spybot. I uninstalled all of the junk programs that the vendor had put on the machines (Kazaa Lite, etc...). Their email was setup and all of the updates were done. They have been instructed on running scans and making sure that the live update is running. I have instructed them on what not to do (open unsolicited emails, click on links or attachments from unsolicited emails), don't download, stay out of chat rooms, etc.....
I contacted them yesterday and reminded them not to open ANY attachments or links in any email that they were not specifically expecting. And to stay out of the IM's.
Here is hoping that this will keep them safe for the next few days. How about you? Have you adequately protected your computer? Do you have a current AV program that has updated defs? Do you have a firewall?
Have a Happy New Year everyone.
WMF and Indexing
WMF Indexing, White Elephants and White Rabbits
The WMF White Elephant in the room as far as I'm concerned is Indexing. YMMV. How many Vendors have other Indexing services installed that are going to automagically enable WMF exploitation on or across your network?F-Secure pointed out the White Elephant when they recommended you "disable indexing of media files (or get rid of Google Desktop) if you're handling infected files under Windows" and said "This is enough to invoke the exploit and infect the machine. This all happens in realtime as Google Desktop contains a file system filter and will index new files in realtime.". And I agree, turn all Indexing off until a fix is out.
Microsoft, Google and other vendors should immediately address what the role is of their indexing services, particularly as it relates to shares, synchronization and potential mitigation activities. Their lack of comment on this issue is glaring.
MS Indexing (White Rabbit Link)
F-Secure's blog today has a new vulnerability workaround (unrelated to indexing).
Call 1-866-727-2338 for free virus and security-related support from Microsoft
Preparation for the Inevitable (and New Years Resolution?)
When your Family and friends inevitably ask for help to "clean" their systems exploited by malicious WMF (or other) attacks, refer them to MS's free phone support.Microsoft's No-Charge support phone number for virus and other security-related issue support is 1-866-727-2338, and "is available 24 hours a day for the U.S. and Canada."
"Outside of the U.S. and Canada", click here and then select your region to obtain the free support phone number for virus and other security-related issue.
Comments