Threat Level: green Handler on Duty: Daniel Wesemann

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

* New exploit released for the WMF vulnerability - YELLOW

Published: 2006-01-01
Last Updated: 2006-01-03 15:10:59 UTC
by Swa Frantzen (Version: 10)
0 comment(s)

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 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 S
ETABORTPROC (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
Keywords:
0 comment(s)

Leap Second

Published: 2005-12-31
Last Updated: 2005-12-31 20:36:52 UTC
by Deborah Hale (Version: 1)
0 comment(s)
Just a reminder that tonight is one of those special times that we see some strange things.  One of those things is the fact that 12-31-2005 23:59:60 UTC is not the same as 01-01-2006 00:00:00 UTC (and it is just before midnight UTC that the leap second will be inserted), but most OSes can't handle a 61 second minute.  So when reviewing your logs next Tuesday morning remember to cross reference the times.  If you use NTP to sync machine times, your clock should gradually adjust back to the correct time and you'll probably never notice.

Keywords:
0 comment(s)

From extreme to in depth

Published: 2006-01-01
Last Updated: 2006-01-01 15:45:17 UTC
by Tom Liston (Version: 2)
0 comment(s)
Warning: some might get offended by some of the initial thoughts in this story. Please read till the end before you vent the frustration.

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
Suppose you are basically just not capable of accepting the risk associated with the WMF vulnerability, almost no matter what you break. In such a case you have big avenues to walk:
  • 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
With those extreme paths in mind, think about what it can do for you, which parts can help you in your setup and  with your risk assessment help.

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.
So basically I'm back to a very in depth security approach that when compared to medieval defenses is the equivalent of not trying to build a city with a huge wall around it, because it's too much of a hassle and too costly. But instead trying to build a city with a somewhat flimsy wooden palisade and build for the few nobles we have a big sturdy donjon to protect them, even at the cost of some discomfort in the process.
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







Keywords:
0 comment(s)

New IM Worm Exploiting WMF Vulnerability

Published: 2005-12-31
Last Updated: 2005-12-31 16:33:11 UTC
by Deborah Hale (Version: 1)
0 comment(s)
We have received information that a new IM Worm is hitting the Netherlands.  Apparently the worm is spreading with MSN and is spreading with a malformed WMF file called "xmas-2006 FUNNY.jpg".

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.
Keywords:
0 comment(s)

2006 Predictions

Published: 2005-12-31
Last Updated: 2005-12-31 16:21:50 UTC
by Deborah Hale (Version: 1)
0 comment(s)

 On December 27th I asked for predictions for 2006.  Here is what we got.  Many thanks to all of you that responded.  Now let's see how close these guys are.


From Dan:

You asked for them...

http://www.websensesecuritylabs.com/blog/

 Below is a list of some of the topics we may be seeing in the New Year:

*Web-born worms

 Not a lot of these around yet. Myspace and some other online sites were infected, but with the mass amounts of exploits for Web scripting languages and un-patched machines this is bound to happen.

 * RSS malcode

 Great technology. As more browsers embed this and include exploits,  the frequent / unattended nature of RSS will be used to infect.

* Trojans outpace worms

 We already are starting to see this. New Trojans and variants of Trojans are coming out daily in volume.

 * Voice-over-IP Phishing (Vishing )

 Somebody had to come up with another name :-). Using Voice over the Internet could introduce another means to deceive unsuspecting users to do something they should not be.

 * Toxic Blogs

 Yes, blogs are everywhere. Including here. Fact is that most of them do not check for scrupulous scripting, scan their file posts, and allow active content in posts.

 * Xbot 360

 The Xbox connecting over the Internet for updates and other things leads me to believe that this will simply be another way for attackers to use your PC and your connection at home for their own purposes.

 * Cross Site scripting attacks

 High-profile ecommerce and financial websites have had (and will have cross site scripting vulnerabilities). Attackers will leverage these for Phishing , Trojan Downloader's and for other nefarios reasons more frequently.

 
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:

  1. "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.
Again - thanks to the contributers.
Keywords:
0 comment(s)

NOT a Quiet Day

Published: 2005-12-31
Last Updated: 2005-12-31 16:03:18 UTC
by Deborah Hale (Version: 1)
0 comment(s)
On December 27th when I did the diary I commented on how quiet it had been.  Well it appears the quiet ended and I perhaps jinxed us.  The question is - how many of the new computers out of the box and connected to the Net have been fully updated, patched and AV protected?  How many new computers are being protected by a firewall of some type?

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.
Keywords:
0 comment(s)

WMF and Indexing

Published: 2005-12-31
Last Updated: 2005-12-31 12:24:04 UTC
by Patrick Nolan (Version: 1)
0 comment(s)

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).
Keywords:
0 comment(s)

Call 1-866-727-2338 for free virus and security-related support from Microsoft

Published: 2005-12-31
Last Updated: 2005-12-31 11:58:48 UTC
by Patrick Nolan (Version: 1)
0 comment(s)

 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.
Keywords:
0 comment(s)
Diary Archives