Updated version of Ilfak Guilfanov's patch / ,msi file
Ilfak Guilfanov has released an updated version of his unofficial patch for the Window's WMF issue. We have reverse engineered, reviewed, and vetted the version here. Note: If you've already successfully installed the patch, this new version adds nothing new. It only adds code to make it able to install on some other very specific configurations and code to recognize when the patch has already been installed.
MD5: 15f0a36ea33f39c1bcf5a98e51d4f4f6 - wmffix_hexblog14.exe
PGP Signature (signed with SANS ISC key) is here
We have pulled the .msi that we posted earlier due to some issues with the file. We will attempt to make a new .msi available, but until we do, you'll need to use the wmffix_hexblog14.exe above.
Update: We finally have the new .msi available, please see the new story.
MD5: 15f0a36ea33f39c1bcf5a98e51d4f4f6 - wmffix_hexblog14.exe
PGP Signature (signed with SANS ISC key) is here
We have pulled the .msi that we posted earlier due to some issues with the file. We will attempt to make a new .msi available, but until we do, you'll need to use the wmffix_hexblog14.exe above.
Update: We finally have the new .msi available, please see the new story.
Keywords:
0 comment(s)
* 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
Keywords:
0 comment(s)
WMF FAQ
This version has been updated to reflect the release of the official patch by Microsoft. Take care with the translations as they might very well not be up to date.
[a few users offered translations of this FAQ into various languages. Obviously, we can not check the translation for accuracy, nor can we update them. Most of these translations are hosted on servers operated by the translation authors. So use at your own risk: Deutsch and Deutsch (pdf), Catalan , Español , Italiana and Italiana, Polski, Suomenkielinen, Danish, Japanese, Slovenian, Chinese, Norwegian and Nederlands ]
To assist with internal presentations about this issue, we made a slide set available:
PDF, Power Point , OpenOffice 2.0
To re-register the DLL, click State, click Run, type
This is the same command as you used to unregister, with the -u part).
To remove the patch, open the control pannel, open the "Add/Remove Programs" icon, find the patch in the list and uninstall.
To uninstall the patch from the command line (vs. using the Control Panel), enter this command:
[a few users offered translations of this FAQ into various languages. Obviously, we can not check the translation for accuracy, nor can we update them. Most of these translations are hosted on servers operated by the translation authors. So use at your own risk: Deutsch and Deutsch (pdf), Catalan , Español , Italiana and Italiana, Polski, Suomenkielinen, Danish, Japanese, Slovenian, Chinese, Norwegian and Nederlands ]
To assist with internal presentations about this issue, we made a slide set available:
PDF, Power Point , OpenOffice 2.0
- Why is this issue so important?
The WMF vulnerability uses images (WMF images) to execute arbitrary code. It will execute just by viewing the image. In most cases, you don't have click anything. Even images stored on your system may cause the exploit to be triggered if it is indexed by some indexing software. Viewing a directory in Explorer with 'Icon size' images will cause the exploit to be triggered as well. Microsoft initially announced that an official patch would not be available before January 10th 2006 (next regular update cycle). But they did release a patch out of cycle earlier.
- Is it better to use Firefox or Internet Explorer?
Internet Explorer will view the image and trigger the exploit without warning. New versions of Firefox will prompt you before opening the image. However, in most environments this offers little protection given that these are images and are thus considered 'safe'.
- What versions of Windows are affected?
Windows XP, (SP1 and SP2), Windows 2003 are affected by the currently circulating exploits. Other versions may be affected to some extent. Mac OS-X, Unix or BSD is not affected.
Note: If you're still running on Win98/ME, this is a watershed moment: we believe (untested) that your system is vulnerable and there will be no patch from MS. Your mitigation options are very limited. You really need to upgrade.
Note: If you're still running on Win98/ME, this is a watershed moment: we believe (untested) that your system is vulnerable and there will be no patch from MS. Your mitigation options are very limited. You really need to upgrade.
- What can I do to protect myself?
The unofficial patch was made available by Ilfak Guilfanov. Our own Tom Liston reviewed the patch and we tested it. The reviewed and tested version is not available form us any longer (last version was 1.4, MD5: 15f0a36ea33f39c1bcf5a98e51d4f4f6), PGP signature (signed with ISC key) here. THANKS to Ilfak Guilfanov for providing the patch!!
We also advised the suggested mitigation action by Microsoft to unregister another DLL, due to the availability of an official patch there is no more need for that.- How do I re-register the DLL and remove the patch?
To re-register the DLL, click State, click Run, type
regsvr32 %windir%\system32\shimgvw.dllThis is the same command as you used to unregister, with the -u part).
To remove the patch, open the control pannel, open the "Add/Remove Programs" icon, find the patch in the list and uninstall.
To uninstall the patch from the command line (vs. using the Control Panel), enter this command:
msiexec.exe /X{E1CDC5B0-7AFB-11DA-8CD6-0800200C9A66} /qn- How does the unofficial patch work?
The wmfhotfix.dll is injected into any process loading user32.dll. The DLL then patches (in memory) gdi32.dll's Escape() function so that it ignores any call using the SETABORTPROC (ie. 0x09) parameter. This should allow Windows programs to display WMF files normally while still blocking the exploit. The version of the patch we distributed was carefully checked against the source code provided as well as tested against all known versions of the exploit. It would work on WinXP (SP1 and SP2) and Win2K. The documentation provided by Microsoft show the official patch does remove exactly the same functionality from gdi32.dll than the unofficial patch prevent from begin used.
- Are there other patches?
- Is there a test to see if I am vulnerable?
- Would unregistering the DLL (without using the official or unofficial patch) protect me?
It might help. But it is not foolproof. We want to be very clear on this: we have some very stong indications that simply unregistering the shimgvw.dll isn't always successful. The .dll can be re-registered by malicious processes or other installations, and there may be issues where re-registering the .dll on a running system that has had an exploit run against it allowing the exploit to succeed. In addition it might be possible for there to be other avenues of attack against the Escape() function in gdi32.dll. We strong recommend to install the official patch.
- Should I just delete the DLL?
It might not be a bad idea, but Windows File Protection will probably replace it. You'll need to turn off Windows File Protection first. Also, once an official patch is available you'll need to replace the DLL. (renaming, rather than deleting is probably better so it will still be handy).
- Should I just block all .WMF images?
This may help, but it is not sufficient. WMF files are recognized by a special header and the extension is not needed. The files could arrive using any extension, or embeded in Word or other documents.
- What is DEP (Data Execution Protection) and how does it help me?
With Windows XP SP2, Microsoft introduced DEP. It protects against a wide range of exploits, by preventing the execution of 'data segements'. However, to work well, it requires hardware support. Some CPUs, like AMD's 64 Bit CPUs, will provide full DEP protection and will prevent the exploit. You can learn more about DEP, how to enable it and check that it is running, here.
- How good are Anti Virus products to prevent the exploit?
At this point, we are aware of versions of the exploit that will not be detected by all the antivirus engines. We hope they will catch up soon. But it will be a hard battle to catch all versions of the exploit. Up to date AV systems are necessary but likely not sufficient.
- How could a malicious WMF file enter my system?
There are too many methods to mention them all. E-mail attachments, web sites, instant messaging are probably the most likely sources. Don't forget P2P file sharing and other sources.
- Is it sufficient to tell my users not to visit untrusted web sites?
No. It helps, but its likely not sufficient. We had at least one widely trusted web site (knoppix-std.org) which was compromissed. As part of the compromise, a frame was added to the site redirecting users to a corrupt WMF file. "Tursted" sites have been used like this in the past.
- What is the actual problem with WMF images here?
WMF images are a bit different then most other images. Instead of just containing simple 'this pixel has that color' information, WMF images can call external procedures. One of these procedure calls can be used to execute the code.
- Should I use something like "dropmyrights" to lower the impact of an exploit.
By all means yes. Also, do not run as an administrator level users for every day work. However, this will only limit the impact of the exploit, and not prevent it. Also: Web browsing is only one way to trigger the exploit. If the image is left behind on your system, and later viewed by an administrator, you may get 'hit'.
- Are my servers vulnerable?
Maybe... do you allow the uploading of images? email? Are these images indexed? Do you sometimes use a web browser on the server? In short: If someone can get a image to your server, and if the vulnerable DLL may look at it, your server may very well be vulnerable.
- What can I do at my perimeter / firewall to protect my network?
Not much. A proxy server that strips all images from web sites? Probably wont go over well with your users. At least block .WMF images (see above about extensions...). If your proxy has some kind of virus checker, it may catch it. Same for mail servers. The less you allow your users to initiate outbound connections, the better. Close monitoring of user workstations may provide a hint if a work station is infected.
- Can I use an IDS to detect the exploit?
Most IDS vendors are working on signatures. Contact your vendor for details. Bleedingsnort.org is providing some continuosly improving signatures for snort users. Recent releases of this exploit take advantage of http compression and randomization of the exploit to evade IDS signatures.
- If I get hit by the exploit, what can I do?
Not much :-(. It very much depends on the exact exploit you are hit with. Most of them will download additional components. It can be very hard, or even impossible, to find all the pieces. Microsoft offers free support for issues like that at 866-727-2389 (866 PC SAFETY).
- Does Microsoft have information available?
There was information on the workarounds and impact available from Microsoft at
http://www.microsoft.com/technet/security/advisory/912840.mspx
but Microsoft in the mean time has release an official patch
http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx
http://www.microsoft.com/technet/security/advisory/912840.mspx
but Microsoft in the mean time has release an official patch
http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx
- What does CERT have to say?
Keywords:
0 comment(s)
Recommended Block List
Update:
Based on feedback from Intercage customers, we no longer
recommend to block them. Please let us know if you see any problems from 69.50.160.0/19 and we will try to facility contact and a resolution.
Updated Update:
Sunbelt posted this blog documenting the issues with Intercage. As a comment: We do not say that Intercage is a safe and clean network now. However, they appear to have some valid customers. Please decide for yourself if you need the valid sites badly enough to risk exposure to the malware hosted at Intercage.
I hate block lists... maybe because I have been on the 'wrong end' of them in the past. But after careful consideration, we do recommend blocking traffic from these two netblocks:
InterCage Inc.: 69.50.160.0/19 (69.50.160.0 - 69.50.191.255)
Inhoster: 85.255.112.0/20 (85.255.112.0 - 85.255.127.255)
Based on feedback from Intercage customers, we no longer
recommend to block them. Please let us know if you see any problems from 69.50.160.0/19 and we will try to facility contact and a resolution.
Updated Update:
Sunbelt posted this blog documenting the issues with Intercage. As a comment: We do not say that Intercage is a safe and clean network now. However, they appear to have some valid customers. Please decide for yourself if you need the valid sites badly enough to risk exposure to the malware hosted at Intercage.
I hate block lists... maybe because I have been on the 'wrong end' of them in the past. But after careful consideration, we do recommend blocking traffic from these two netblocks:
InterCage Inc.: 69.50.160.0/19 (69.50.160.0 - 69.50.191.255)
Inhoster: 85.255.112.0/20 (85.255.112.0 - 85.255.127.255)
The list may be updated later. We do not expect to make this a "regular feature". But at this time we find that it is necessary to point out these particular two netblocks.
They have been associated with a number of high profile criminal activities in the past. A good number of WMF exploits use name servers or other resources in these netblocks. They have been non responsive to current and past requests to remove malicious content.
Keywords:
0 comment(s)
Overview of the WMF related articles at the ISC
Since this is one of the more complex stories to follow I've made a quick overview of the WMF issues.
The first story on the WMF vulnerability and the initial exploit
http://isc.sans.org/diary.php?storyid=972
The update explaining why we went to yellow the first time around
http://isc.sans.org/diary.php?storyid=975
The story pointing to the Microsoft bulletin
http://isc.sans.org/diary.php?storyid=976
The availability of the first snort sigs
http://isc.sans.org/diary.php?storyid=977
The going back to green article
http://isc.sans.org/diary.php?storyid=978
More WMF signatures
http://isc.sans.org/diary.php?storyid=980
Lotus notes affected
http://isc.sans.org/diary.php?storyid=981
The bandaid post: deregistering not reliable, extension filtering not enough
http://isc.sans.org/diary.php?storyid=982
The free phone number for micrsoft support
http://isc.sans.org/diary.php?storyid=985
Indexing and WMF
http://isc.sans.org/diary.php?storyid=986
Musings on how to protect organisations beyond the trivial
http://isc.sans.org/diary.php?storyid=990
An IM worm found using the WMF stuff
http://isc.sans.org/diary.php?storyid=991
The second exploit, back to yellow, new sigatures and an unoffical patch
http://isc.sans.org/diary.php?storyid=992
The WMF FAQ
http://isc.sans.org/diary.php?storyid=994
2nd generation exploit use in spam
http://isc.sans.org/diary.php?storyid=995
Trustwothy computing
http://isc.sans.org/diary.php?storyid=996
Recommended block list
http://isc.sans.org/diary.php?storyid=997
Status of the anti-virus detection after one day
http://isc.sans.org/diary.php?storyid=998
Updated version of Ilfak Guilfanov's patch
http://isc.sans.org/diary.php?storyid=999
More .wmf woes
http://isc.sans.org/diary.php?storyid=1002
Installing a Patch Silently
http://isc.sans.org/diary.php?storyid=1004
.wmf FAQ Translations
http://isc.sans.org/diary.php?storyid=1005
Checking for .wmf Vulnerabilities
http://isc.sans.org/diary.php?storyid=1006
MS to Release Update on Jan 10
http://isc.sans.org/diary.php?storyid=1009
.MSI installer file for WMF flaw available
http://isc.sans.org/diary.php?storyid=1010
--
Swa Frantzen
The first story on the WMF vulnerability and the initial exploit
http://isc.sans.org/diary.php?storyid=972
The update explaining why we went to yellow the first time around
http://isc.sans.org/diary.php?storyid=975
The story pointing to the Microsoft bulletin
http://isc.sans.org/diary.php?storyid=976
The availability of the first snort sigs
http://isc.sans.org/diary.php?storyid=977
The going back to green article
http://isc.sans.org/diary.php?storyid=978
More WMF signatures
http://isc.sans.org/diary.php?storyid=980
Lotus notes affected
http://isc.sans.org/diary.php?storyid=981
The bandaid post: deregistering not reliable, extension filtering not enough
http://isc.sans.org/diary.php?storyid=982
The free phone number for micrsoft support
http://isc.sans.org/diary.php?storyid=985
Indexing and WMF
http://isc.sans.org/diary.php?storyid=986
Musings on how to protect organisations beyond the trivial
http://isc.sans.org/diary.php?storyid=990
An IM worm found using the WMF stuff
http://isc.sans.org/diary.php?storyid=991
The second exploit, back to yellow, new sigatures and an unoffical patch
http://isc.sans.org/diary.php?storyid=992
The WMF FAQ
http://isc.sans.org/diary.php?storyid=994
2nd generation exploit use in spam
http://isc.sans.org/diary.php?storyid=995
Trustwothy computing
http://isc.sans.org/diary.php?storyid=996
Recommended block list
http://isc.sans.org/diary.php?storyid=997
Status of the anti-virus detection after one day
http://isc.sans.org/diary.php?storyid=998
Updated version of Ilfak Guilfanov's patch
http://isc.sans.org/diary.php?storyid=999
More .wmf woes
http://isc.sans.org/diary.php?storyid=1002
Installing a Patch Silently
http://isc.sans.org/diary.php?storyid=1004
.wmf FAQ Translations
http://isc.sans.org/diary.php?storyid=1005
Checking for .wmf Vulnerabilities
http://isc.sans.org/diary.php?storyid=1006
MS to Release Update on Jan 10
http://isc.sans.org/diary.php?storyid=1009
.MSI installer file for WMF flaw available
http://isc.sans.org/diary.php?storyid=1010
--
Swa Frantzen
Keywords:
0 comment(s)
Trustworthy Computing
Looking forward to the week ahead, I find myself in the very peculiar position of having to say something that I don't believe has ever been said here in the Handler's diary before: "Please, trust us."
I've written more than a few diaries, and I've often been silly or said funny things, but now, I'm being as straightforward and honest as I can possibly be: the Microsoft WMF vulnerability is bad. It is very, very bad.
We've received many emails from people saying that no one in a corporate environment will find using an unofficial patch acceptable.
Acceptable or not, folks, you have to trust someone in this situation.
To the best of my knowledge, over the past 5 years, this rag-tag group of volunteers hasn't asked for your trust: we've earned it. Now we're going to expend some of that hard-earned trust:
This is a bad situation that will only get worse. The very best response that our collective wisdom can create is contained in this advice - unregister shimgvw.dll and use the unofficial patch. You need to trust us.
Looking back over the past year, the ISC handlers have faced up to any number of challenges: from worms and viruses to DNS poisoning and hurricanes. We've done our best to keep you informed and to tell it like it is. Somehow, it seems fitting that on the last day of 2005 we rang in the New Year in what can only be described as typical ISC style.
On December 31st, we received word that a "new and improved" version of the WMF exploit had been published. This new exploit code generated WMF files that were sufficiently different that they bypassed nearly all AV and IDS signatures. Publishing exploit code such as this for an unpatched vulnerability on a holiday weekend is, without any doubt, a totally irresponsible act.
And so, as the hours to the New Year slowly counted down, a group of volunteers gave up their holiday weekend to come together as a team and put their collective knowledge and intellect to work on the problems this reckless disclosure created. Some tested the exploit, some talked to AV vendors, some worked toward finding a means to mitigate the vulnerability, some tested "fix" ideas and the resulting patches.
I was privileged to be a part of that team, and I'm incredibly proud of everyone who participated. As it became obvious that the "fix" that we were working toward was essentially what had already been created by Ilfak Guilfanov, we wrote to him to ask if we could redistribute his patch from the ISC. He was incredibly gracious and courteous in allowing us to do so and we were able to work with him to verify several changes that allowed the patch to work on a wider variety of Windows systems.
We have very carefully scrutinized this patch. It does only what is advertised, it is reversible, and, in our opinion, it is both safe and effective.
The word from Redmond isn't encouraging. We've heard nothing to indicate that we're going to see anything from Microsoft before January 9th.
The upshot is this: You cannot wait for the official MS patch, you cannot block this one at the border, and you cannot leave your systems unprotected.
It's time for some real trustworthy computing. All we're asking is if we've proved ourselves to be worthy of your trust.
I've written more than a few diaries, and I've often been silly or said funny things, but now, I'm being as straightforward and honest as I can possibly be: the Microsoft WMF vulnerability is bad. It is very, very bad.
We've received many emails from people saying that no one in a corporate environment will find using an unofficial patch acceptable.
Acceptable or not, folks, you have to trust someone in this situation.
To the best of my knowledge, over the past 5 years, this rag-tag group of volunteers hasn't asked for your trust: we've earned it. Now we're going to expend some of that hard-earned trust:
This is a bad situation that will only get worse. The very best response that our collective wisdom can create is contained in this advice - unregister shimgvw.dll and use the unofficial patch. You need to trust us.
Looking back over the past year, the ISC handlers have faced up to any number of challenges: from worms and viruses to DNS poisoning and hurricanes. We've done our best to keep you informed and to tell it like it is. Somehow, it seems fitting that on the last day of 2005 we rang in the New Year in what can only be described as typical ISC style.
On December 31st, we received word that a "new and improved" version of the WMF exploit had been published. This new exploit code generated WMF files that were sufficiently different that they bypassed nearly all AV and IDS signatures. Publishing exploit code such as this for an unpatched vulnerability on a holiday weekend is, without any doubt, a totally irresponsible act.
And so, as the hours to the New Year slowly counted down, a group of volunteers gave up their holiday weekend to come together as a team and put their collective knowledge and intellect to work on the problems this reckless disclosure created. Some tested the exploit, some talked to AV vendors, some worked toward finding a means to mitigate the vulnerability, some tested "fix" ideas and the resulting patches.
I was privileged to be a part of that team, and I'm incredibly proud of everyone who participated. As it became obvious that the "fix" that we were working toward was essentially what had already been created by Ilfak Guilfanov, we wrote to him to ask if we could redistribute his patch from the ISC. He was incredibly gracious and courteous in allowing us to do so and we were able to work with him to verify several changes that allowed the patch to work on a wider variety of Windows systems.
We have very carefully scrutinized this patch. It does only what is advertised, it is reversible, and, in our opinion, it is both safe and effective.
The word from Redmond isn't encouraging. We've heard nothing to indicate that we're going to see anything from Microsoft before January 9th.
The upshot is this: You cannot wait for the official MS patch, you cannot block this one at the border, and you cannot leave your systems unprotected.
It's time for some real trustworthy computing. All we're asking is if we've proved ourselves to be worthy of your trust.
Keywords:
0 comment(s)
2nd generation WMF exploit: status of the anti-virus products after one day.
Yesterday in a colaborative effort, we sent a true 0-day sample of the 2nd generation WMF exploit to virustotal. As expected, no detections were made. The payload in that sample was a very basic, commonly known and available payload. So the payload might get detected without the exploit being detected. But even there, we had no such luck then.
We sent in a similar sample today.
The results are not all that good:
eTrust-Vet 12.4.1.0 01.01.2006 Win32/Worfo
McAfee 4664 01.01.2006 Exploit-WMF
Symantec 8.0 01.01.2006 Backdoor.Trojan
All the others failed to detect the sample.
Do note that the Symantec detect is most likely on the payload. That payload isn't what any of the bad guys playing with this will insert. They will insert far nastier and far less off-the-shelf stuff than what we did.
So for now you still have the best chance with following the advice in this diary entry.
--
Swa Frantzen
We sent in a similar sample today.
The results are not all that good:
eTrust-Vet 12.4.1.0 01.01.2006 Win32/Worfo
McAfee 4664 01.01.2006 Exploit-WMF
Symantec 8.0 01.01.2006 Backdoor.Trojan
All the others failed to detect the sample.
Do note that the Symantec detect is most likely on the payload. That payload isn't what any of the bad guys playing with this will insert. They will insert far nastier and far less off-the-shelf stuff than what we did.
So for now you still have the best chance with following the advice in this diary entry.
--
Swa Frantzen
Keywords:
0 comment(s)
From extreme to in depth
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:
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 ?
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 ...
Swa Frantzen
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
Keywords:
0 comment(s)
2nd generation WMF 0day Exploit Spammed
According to F-Secure's blog today, the 2nd generation WMF exploit has been spammed and "When the HappyNewYear.jpg hits the hard drive and is accessed (file opened, folder viewed, file indexed by Google Desktop), it executes and downloads a Bifrose backdoor (detected by us as Backdoor.Win32.Bifrose.kt) from www[dot]ritztours.com."
Trend Micro is calling it TROJ_NASCENE.H
Trend Micro is calling it TROJ_NASCENE.H
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments