evilrouters.net

This has been a fun one already, and our offices are still officially closed. We reopen tomorrow and I predict it will become even more fun after that.

First, some links for those who live in a cave and haven’t heard about it yet:

• Microsoft Security Advisory (912840)
• SANS Internet Storm Center
• WebSense Security Labs Alert
• eWeek: Workaround, Protections Emerge for WMF Exploit
• ZDnet: Update on WMF exploit

There, that should get you started. The gist of it is that there’s a 0-day vulnerability in damn near every version of Windows. It has to do with the way Windows Metafiles (.WMF) are parsed. By design, they are able to execute arbitrary code. By design, an attacker can specially craft a .WMV file and when it is parsed on a Windows box, it will run the attacker’s code.

This is big. This is bad. This is very big and very bad. There isn’t an “official” patch from Microsoft. Respected researcher Ilfak Guilfanov has created his own unofficial patch for the WMF vulnerability. IF YOU USE WINDOWS, I HIGHLY RECOMMEND YOU INSTALL THIS PATCH!

There’s really not much more that you can do. About the only other thing is to unregister the responsible DLL, but that’s not foolproof. It is better than nothing, however. If you don’t install the patch listed above, at the very minimum do the following:

Click Start, then Run. In the command box, enter “regsvr32 /u shimgvw.dll” and press OK.

You’ll get a dialog box that pops up that tells you the command was successful.

I wrote an article a few days ago called Blocking .WMF at the Perimeter. In this article, I mentioned how we were blocking .WMF files through the Squid proxy server and McAfee GroupShield on our Microsoft Exchange servers.

Since then, I’ve done a bit more. Since malicious files don’t have to come in WMF form, I decided that we at least need to unregister the shimgvw.dll on all our PCs. This is what I consider the very least that one do in an attempt to mitigate this. This isn’t easily done, however, when one has an assload of Windows boxes to manage. Obviously, we couldn’t send out an e-mail to everyone and ask them all to do it themselves — it’d never get done.

I ended up writing a batch file that silently unregisters the DLL, then creates a small text file on a network share with its filename derived from the computer name. This gives us a small way of tracking which PCs have had the DLL unregistered. First was the batch file:

@echo off %windir%\system32\regsvr32.exe /u /s shimgvw.dll echo “unregistered” > \server\share\%computername%

The second line silently unregisters the DLL, meaning users wouldn’t get a popup confirmation box (this would only confuse them, most likely). The last line is the one that creates the small text file. Next, I needed a way to get this script to execute on every PC. Enter Group Policy.

I created a new Group Policy object at the domain level. This GPO has only one setting. The setting in question is Computer Configuration -> Windows Settings -> Scripts (Startup/Shutdown). I added my batch file as a computer startup script — it will be ran every time a PC boots up.

Now, what happens if a PC isn’t rebooted? Well, the script won’t run until it is. Our users mostly leave their PCs on and logged in (and hopefully locked) while they’re away. When they come back tomorrow morning, chances are good that they won’t reboot them. To address this, I turned to the good ol’ “ldapsearch” command-line utility on my Linux boxes. Using ldapsearch, I generated a couple of LDAP queries to return a list of all PCs in our domain (using “objectclass=computer”). I went through the list manually to remove a few servers, etc. and then transferred that list to one of my Windows desktops which has psshutdown.exe from Sysinternals. psshutdown.exe can take a text file as a list of PCs to shutdown/reboot. Then, a simple command like “psshutdown.exe -r -t 60 -f @pc_list.txt” was all that was necessary.

Once executed, psshutdown would run through the list of PCs in the file, connect to each one and schedule an automatic reboot in 60 seconds. After I started up psshutdown, I opened a Windows Explorer window, browsed to the network share mentioned above where each PC will create a text file, and was able to watch, in real-time, the text files being created. This gave me confirmation that the PCs were, indeed, rebooting and that the DLL file was being unregistered.

Fun stuff, let me tell ya.

On a side note, I grep’d through the Squid proxy server log files and found at least one instance of a .WMF file being blocked. I retrieved the file manually (on a Linux box, using wget) and submitted it to VirusTotal. Here are the results:

Scan results File: wmf_exp.wmf

Date: 01/02/2006 16:40:21 (CET)

AntiVir 6.33.0.70/20060102 found [EXP/IMG.WMF] Avast 4.6.695.0/20051230 found [Win32:Exdown] AVG 718/20060102 found [Exploit.WMF] Avira 6.33.0.70/20060102 found [EXP/IMG.WMF] BitDefender 7.2/20060101 found [Exploit.Win32.WMF-PFV] CAT-QuickHeal 8.00/20060102 found [WMF.Exploit] ClamAV devel-20051123/20060102 found [Exploit.WMF.A] DrWeb 4.33/20060102 found [Exploit.MS05-053] eTrust-Iris 7.1.194.0/20060101 found [Win32/Worfo!Trojan] eTrust-Vet 12.4.1.0/20060101 found [Win32/Worfo] Ewido 3.5/20060102 found [Exploit.MS05-053-WMF] Fortinet 2.54.0.0/20051231 found [W32/WMF-exploit] F-Prot 3.16c/20060101 found nothing Ikarus 0.2.59.0/20060102 found [Exploit.Win32.IMG-WMF] Kaspersky 4.0.2.24/20060102 found [Trojan-Downloader.Win32.Agent.acd] McAfee 4665/20060102 found [Exploit-WMF] NOD32v2 1.1348/20060102 found [Win32/TrojanDownloader.Wmfex] Norman 5.70.10/20061231 found [W32/Exploit.Gen] Panda 9.0.0.4/20060102 found [Exploit/Metafile] Sophos 4.01.0/20060102 found [Exp/WMF-A] Symantec 8.0/20060102 found [Download.Trojan] TheHacker 5.9.2.067/20060102 found [Exploit/WMF] UNA 1.83/20051230 found nothing VBA32 3.10.5/20060101 found nothing

Stay tuned!