Infocon gone Yellow

The Infocon status is now yellow, due to the MSDDS.DLL exploit now available. We moved to Yellow as we feel widespread malicious use of this vulnerability is imminent, and the workarounds shown here provide sufficient countermeasures to be applied quickly. We expect to move back to green by the end of the day or early tomorrow.

Internet Explorer (.Net) 0day msdds.dll Exploit & Patch

Yesterday, FrSIRT (aka K-otik) released a working 0-day exploit against
a .Net component with is accessible remotely via Microsoft Internet Explorer.

Update 1600 EST:

http://www.microsoft.com/technet/security/advisory/906267.mspx

Microsoft has released a security advisory with regards to MSDDS.DLL.
<H3>Impact</H3>

The exploit will open a remote shell if you visit a malicious website.
Other payloads are possible. The exploit will have all the privileges
assigned to the user running Internet Explorer. We do not see any use of
the exploit at this time, but consider widespread use imminent.

<H3>Am I Vulnerable ?</H3>

You are only vulnerable if you have "msdds.dll" installed on your system.
By default, Windows will not install this DLL. See below for details.
The DLL can be found in Program Files\Common Files\MicrosoftShared\MSDesigners7. Note that the directory may be named
differently in non-english versions of Windows.

The vulnerable version is: 7.0.9064.9112 . Later versions are not
vulnerable (in particular 7.10.x)

Workarounds

While there are no official patches available, there are a number of
workarounds:

* Set "kill bit" for the ActiveX component. We released a number of scripts
to set the "kill bit" for the affected ActiveX component. This will prevent
use of the vulnerable ActiveX component by Internet Explorer. msdds.dll may
still be used by local applications (and this is ok). But this may break
activex applications accessed via the browser, if they make use of this
vulnerable function.
.
* you can make the same change using the registry editor. Change this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{EC444CB6-3E7E-4865-B1C3- 0DE72EF39B3F}\Compatibility Flags=0x00000400" [Jerry] I added a space in the key to avoid the above mentioned content filter rule [John].

* Remove the vulnerable DLL from your system. This may break various applications that installed the DLL.

* Use 'DropMyRights' to limit the impact of an exploit.

* Use an alternative browser (Firefox, Opera) which does not provide ActiveX.

Note that other browsers may in fact use the MSIE engine to render code, for example ActiveX such as this one. Netscape 8 for example has this capability, and may be vulnerable. This has not yet been confirmed. [AB]

* If you are able to apply content filters to your internet gateway (e.g. a proxy server), filter for this string:

(in order to allow you to still visit this page, we substituted the '-' with the word '(dash)' ...)

EC444CB6(dash)3E7E(dash)4865(dash)B1C3(dash)0DE72EF39B3F

How do I recognize a web page which contains exploit code?

Look for this pattern:

<object classid="EC444CB6(dash)3E7E(dash)4865(dash)B1C3(dash)0DE72EF39B3F"></object>

If you visit a page with the exploit, it will load very slowly. In some
cases, we got a warning that the system is low on virtual memory.

Current virus scanners may recognize the exploit using rules developed for
older, similar exploits.

What software may install the DLL?

Here is a list of applications that may install this component:

(Disclaimer: We can't test them all... but it should help you prioritize)

MS Visual Studio .Net

.Net Framework 1.1

Microsoft Office (2000, 2002, XP) [Karl, Juha-Matti]

Microsoft Project

Visio [Chris]

Access 11 (2003) runtime [Scott]

ATI Catalyst driver installed by newer ATI video cards [Eric]
MSDDS.DLL is not found on Win2003 SP1 SERVER with .net installed (not Visual Studio .net). [Andy].

Not all default Office 2000 installs have msdds.dll installed. [Emmanuel]

We get conflicting reports, likely due to various configuration and install choices. Please verify yourself the version before concluding that you are not vulnerable.

The version of MSDDS.DLL installed with Office 2003 is not vulnerable.

If you test your system using the PoC exploit, please let us know if

it succeeded, and what version of MSDDS.DLL you are using. Version 7.10.3077.0 may not be vulnerable (according to Secunia and our testing). [Juha-Matti]

Version 7.0.9064.9112 is vulnerable [Gilles].

MSDDS Trivia:

- MSDDS stands for "Microsoft Design Tools - Diagram Surface".

- you sometimes may find the (wrong) spelling of msdss in earlier versions of our diaries.
Related Links:

http://secunia.com/advisories/16480/

Open letter from the handlers

It merits pointing out that this particular vulnerability really isn't
0-day, it's more like 380-day, as the underlying vulnerability has
been around for a LONG TIME.

See http://www.informationweek.com/story/showArticle.jhtml?articleID=22102487&tid=5979
for example.

Microsoft (and others; sorry Tom) have been recommending that users set
"kill bits" on individual ActiveX/COM objects for a year now, as an
ultimate fix for the issue. In MS05-038's writeup:

"Because not all COM objects are designed to be accessed through
Internet Explorer, this update sets the kill bit for a list of Class
identifiers (CLSIDs) in COM objects that have been found to exhibit similar
behavior to the JVIEW Profiler vulnerability that is addressed in Microsoft
Security Bulletin MS05-037. To help protect customers, this update prevents
these CLSIDs from being instantiated in Internet Explorer. For more
information about kill bits, see Microsoft Knowledge Base Article 240797."
http://support.microsoft.com/kb/240797

Have we all forgotten the lessons of taking a default-permit stance with
regard to defense? The underlying vulnerability is not that javaprxy.dll
(MS05-037) or shell32.dll (MS05-038) or msdds.dll can be invoked from a
web page; the real issue is that the MSIE Renderer, which can be invoked
from nearly every Microsoft application (Office, Outlook, ...) is allowed
to access any object within the operating system without any controls
whatsoever.

There should be a default-deny setting, allowing only a white-list of
"known good" ActiveX objects. Microsoft, this situation demands a more
effective and encompassing solution, it needs to be enabled by default,
and it cannot afford to wait for Vista & IE7 to be released.

Update 2005-08-18 23:35 UTC: Reader M. writes in to remind us that
there are a couple of ways that technically-savvy users can harden MSIE
against this sort of attack:

"They already have two available: the Administrator Approved list at
HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\
Internet Settings\AllowedControls
which is enabled by setting "Run ActiveX Controls and Plug-ins" (value 1200)
in the Internet security zone to "Administrator Approved"
This has been available since IE 5 and works in IE 6 on both XP Pro and
XP Home. The details are documented in KB article 182569.

There is also a way to implement a whitelist using the new add-on management
functionality that was added in IE 6 on XP SP2. Just set the "Deny all
Add-ons unless specifically allowed in the add-on list." The details are
in the technet documentation that describes the new security features in IE
on XP SP2." Thanks! [ Now, if only we could get that enabled by the
next round of kill-bit patches. ;-) ]

Apple OX-X 2005-007 patches

Apple released patch set #7 for this year:

http://docs.info.apple.com/article.html?artnum=302163
A number of critical issues are fixed by this patch sets. Highlights include
Apache2, Bluetooth and zlib. It is recommended that OS-X users apply these patches expeditiously. For some of these issues, exploit code is available for other platforms and may be adapted to OS-X.

Make sure you use version 1.1. of this patch set. Initially, Apple released 1.0 but it was missing a critical 64 bit library and broke some applications. [Harry].

Port 1433 scans after Zotob infection

One reader reported that he obsevered a significant increase in port 1433 scanning after a host in his network was infected with Zotob. The implication may be that miscreants are monitoring for Zotob infected machines and scan them assuming weak security practices in the respective network.
---------

Malicious Software Removal Tool updated for Zotob

This Alert is to notify you that on 17 August 2005 the Microsoft Windows

Malicious Software Removal Tool has been updated with added detection

and cleaning capabilities for the following Malicious Software:



*       Zotob.A

*       Zotob.B

*       Zotob.C

*       Zotob.D

*       Zotob.E

*       Bobax.O

*       Esbot.A

*       Rbot.MA

*       Rbot.MB

*       Rbot.MC



The updated version of the Microsoft Windows Malicious Software Removal

Tool is available for download from the Download Center at this

location:

 http://www.microsoft.com/downloads/details.aspx?FamilyId=AD724AE0-E72D-4F54-9AB3-75B8EB148356&displaylang=en



NOTE: This updated version is currently NOT available on Windows Update,

Microsoft Update or through Windows Server Update Services.

- Thank you Susan!

--------------------

We received a lot of great input from readers.
I started acknowledging reader input using square brackets and their first name.
THANKS!!! Keep it coming!!!
Johannes, Adrien, and the ISC handler team