De-registering vgx.dll in an enterprise

Published: 2006-09-25
Last Updated: 2006-09-26 00:08:34 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)
The following is one experience in a global enterprise environment sent in by a reader.

=========

The following post is my experience with de-registering vgx.dll in a large, corporate and R&D environment with sites around the globe.

The purpose is to present our actions and findings.  I make no promises, guarantees, etc. that this will work for others. So please be sure to do your own testing and risk analysis.

All of that said ... I hope that my point of view helps to possibly aid others in their efforts to find and effective mitigation strategy for this vulnerability.

Since the early whisperings of exploits for the vulnerability, and then 'suggested' work-arounds, de-registration of the vgx.dll has been at the top of our list of possible mitigations.

Starting (very) early on Friday morning, and going through an 11 hour day, our InterOp team tested the affects of the de-registration on as many different system configurations as they could.  In the end they found no issues and supported this recommendation for mitigation.  Early Friday evening we put our plan in place and commenced with the de-registration of vgx.dll from all of our ~38,000 corporate and ~8,000 R&D systems.  By late-evening 1/3 of our targets had the dll de-registered; there were no reported issues with business critical systems and applications, there were calls to the help desks and there were no issues from our R&D folks.

Two and a half days after putting the plan in place 98% of our systems have had the dll de-registered and things remain stable and quiet on all fronts.

There have been some reports of system slow-downs by employees but after investigation there no clear linkages between the actions taken and the symptoms observed.  In most cases a simple reboot solved the problem.

We continue to monitor the situation as well as staying in contact with Microsoft to ensure that our environment remains stable and malware free.

=========

Thanks for sharing Eric.

Cheers,
Adrien de Beaupré
Cinnabar Networks/BSSI

Keywords:
0 comment(s)

VML vuln being actively exploited

Published: 2006-09-25
Last Updated: 2006-09-25 23:41:46 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)
Messagelabs has reported that E-cards are being used as an attack vector, exploiting the VML vulnerability in MS Internet Explorer to download malware. There has been an upswing of web sites hosting the exploit, and of course downloading malware.

A reader wrote in after having seen a VML exploit and reviewing his firewall logs. The following web site URLs are deliberately munged and obfuscated until the site owners respond to emails and phone calls advising them of the problem, do not click on them using any web browser on a Microsoft platform.
The first site is
http:// www .allied(snipped) parts .com
The bottom of tha page contains an iframe which loads:
http:// www .traffl(snipped) .info/out.php?s_id=1
Which goes and gets:
http://www .webmasters(snipped) .com/s_test/test/ vml_sp2_gamer .htm

Which contains the VML exploit. The fun doesn't stop there!
By now this system is thoroughly owned, and more malware follows.

vml_sp2_gamer.html pulls gamer.exe off the same site, which in turn grabs gamer1.exe and counter.exe and also reports successful infection to another URL, raff loads.info.  gamer1.exe is a password stealer that is even seen by Clamav: Trojan.Spy.Goldun-141

Many thanks to Daniel and Swa and the other ISC handlers.

Cheers,
Adrien de Beaupré
Cinnabar Networks/BSSI



Keywords:
0 comment(s)

Using ISA to help block VML exploit

Published: 2006-09-25
Last Updated: 2006-09-25 23:11:25 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)
For those of you that use MS ISA as a proxy, or even as a perimiter protective mechanism, Microsoft has posted an article on "Learn How Your ISA Server Helps Block VML Vulnerability Traffic (925568)"
This would be highly recommended measure in a Microsoft centric environment, as one of the defence-in-depth layers of protection, not by itself. Please see the earlier diary entries on the VML vulnerability and its current exploitation here.

Cheers,
Adrien de Beaupré
Cinnabar Networks/BSSI
Keywords:
0 comment(s)

Yellow: MSIE VML exploit spreading

Published: 2006-09-25
Last Updated: 2006-09-25 00:49:40 UTC
by Swa Frantzen (Version: 9)
0 comment(s)

History

We've refreshed this article for those of you checking in on their Monday morning as a reminder. On Friday 22nd (and for some of our readers past their working day), we have raised our Infocon to Yellow for 24 hours in order to increase the awareness of the problem and call for action. We went back to Green -as intended- after 24 hours.

New versions of exploits continue to be released publicly. We also still get new sites detecting exploits and reporting this to us. There is still reason to act if you haven't done so yet. This exploit is one that's going to stay with us, so you do need protection. Waiting will not make the problem go away.

Reason for Yellow

The VML exploit is now becoming more widespread, so we changed the InfoCon level to yellow to emphasize the need to consider fixes.

If you have not taken measures yet, please consider some emergency fixes to cover the weekend (especially for those laptops surfing the web from home; they might be at high risk). The exploit is widely known, easy to recreate, and used in more and more mainstream websites.  The risk of getting hit is increasing significantly.

Outlook (including outlook 2003) is - as expected - also vulnerable and the email vector is being reported as exploited in the wild as well.

Weekends are moreover popular moments in time for the bad guys to build their botnets.

Actions

We suggest following actions (do them all: a layered approach will work when one of the measures fails):
  • Update your antivirus software, make sure your vendor has protection for it (*).
  • Unregister the vulnerable dll (**):
regsvr32 /u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
or
regsvr32 /u "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"

And reboot the machine to make sure all in memory copies are gone as well.
  • Consider asking your users to stop their usage of MSIE, we know it's hard to break an addiction, but you're using the most targeted browser in the world.
Reregistering a DLL (which you might want to do after an official patch is released) is done with the same command as unregistration, but without the "/u".

Quotes

Ken Dunham from iDefense claims they have seen a significant increase in attacks over the last 24 hours and "[at] least  one domain hosts provider has suffered a large-scale attack leading to index file modifications on over 500 domains". Those domains pointed visitors to a VML exploit. We're happy to note they join us in recommending "implementing a workaround ASAP" and see the upcoming weekend as a factor in it.

References


(*): It's important to note the difference of your antivirus solutions detecting the exploitation itself (very rare) and detecting the payload of known exploits (common). Only the first will offer real protection against new threats.
(**): There are a few rare reports of relatively uncommon applications out there that suffer from disabling this DLL, so check your mission critical applications before disabling it. Since VML never made it as a standard, it is not widely used at all. Using it means the web site does not work properly in other browsers.

--
Swa Frantzen -- Section66
Keywords: 0day msie vml yellow
0 comment(s)

Comments


Diary Archives