CyberInsecure.com

Microsoft Office Web Components ActiveX Control ‘msDataSourceObject’ Vulnerability Allows Remote Code Execution

Microsoft has released an advisory related to an Office Web Components ActiveX vulnerability. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. When using Internet Explorer, code execution is remote and may not require any user intervention.

This vulnerability exists in the ActiveX control used by IE to display Excel spreadsheets. Microsoft mentions that they are aware of active exploits against this vulnerability and at the moment there is no patch, just a a workaround. Workaround refers to a setting or configuration change that does not correct the underlying vulnerability but would help block known attack vectors before you apply the update. Microsoft advisory can be found here.

The list of affected products include:

Microsoft Office XP Service Pack 3;
Microsoft Office 2003 Service Pack 3;
Microsoft Office XP Web Components Service Pack 3;
Microsoft Office Web Components 2003 Service Pack 3;
Microsoft Office 2003 Web Components for the 2007 Microsoft Office system Service Pack 1;
Microsoft Internet Security and Acceleration Server 2004 Standard Edition Service Pack 3;
Microsoft Internet Security and Acceleration Server 2004 Enterprise Edition Service Pack 3;
Microsoft Internet Security and Acceleration Server 2006;
Internet Security and Acceleration Server 2006 Supportability Update;
Microsoft Internet Security and Acceleration Server 2006 Service Pack 1; and
Microsoft Office Small Business Accounting 2006.

The vulnerability is being actively exploited on web sites as attackers just modify the code with a fresh download and payload to slightly modified malware. There is a .cn domain that is using a heavily obfuscated version of the exploit – which may become an attack kit (think MPACK) and is similar to recent DirectShow attacks.

Earlier today there was a highly targeted attack against an organization who received a Microsoft Office document with embedded HTML. It was specifically crafted for the target – with the document being tailored with appropriate contact information and subject matter that were specific to the targeted recipient. Analysis of the document and secondary payload found the attacker used a firewall on the malicious server so that all IP traffic outside of the targeted victim’s domain/IP range would not reach with the server.

Here is the workaround details from Microsoft Technet Blog:

By default, if the control is installed, it can be instantiated and scripted as seen by the tool output below:

C:>ClassId.exe {0002E541-0000-0000-C000-000000000046} (*)
Clsid: {0002E541-0000-0000-C000-000000000046}
Progid: OWC10.Spreadsheet.10
Binary Path: C:PROGRA~1COMMON~1MICROS~1WEBCOM~110OWC10.DLL
Implements IObjectSafety: True
Safe For Initialization (IObjectSafety): True — IE will allow loading
Safe For Scripting (IObjectSafety): True — IE will allow scripting
Safe For Initialization (Registry): False
Safe For Scripting (Registry): False
KillBitted: False — It is not killbitted

(*) This example uses the OWC10 classid. Same applies to the OWC11 classid: {0002E559-0000-0000-C000-000000000046}

In order to protect your system you can issue the killbit for the two classids by adding the following value in the registry following these steps:

1) Use Registry Editor to view the data value of the Compatibility Flags DWORD in the following two registry keys:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility{0002E541-0000-0000-C000-000000000046}

HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility{0002E559-0000-0000-C000-000000000046}

2) Change or add the value of the Compatibility Flags DWORD value to 0×00000400.

After applying the killbit you can check it again with the ClassId.cs tool:

C:>ClassId.exe {0002E541-0000-0000-C000-000000000046} (*)

Clsid: {0002E541-0000-0000-C000-000000000046}
Progid: OWC10.Spreadsheet.10
Binary Path: C:PROGRA~1COMMON~1MICROS~1WEBCOM~110OWC10.DLL
Implements IObjectSafety: True
Safe For Initialization (IObjectSafety): True
Safe For Scripting (IObjectSafety): True
Safe For Initialization (Registry): False
Safe For Scripting (Registry): False
KillBitted: True — Since the kilbit has been applied, IE will refuse to load the control

(*) This example uses the OWC10 classid. Same applies to the OWC11 classid: {0002E559-0000-0000-C000-000000000046}

At this point you are no longer vulnerable to this threat through the IE vector.

As mentioned in the advisory, we are also providing a way to apply this workaround automatically. You can click the button below to set the kill-bit on this control.

Credit: SANS ISC
Credit: Microsoft TechNet Blogs

Share this item with others:

Posted in Malware, Mass Web Attacks, Microsoft, Software, Trojans & Worms, Vulnerabilities, Windows |  Print This Post