Message-ID: <653D74053BA6F54A81ED83DCF969DF082A9ACB@pivxes1.pivx.com>
Date: Fri, 3 Sep 2004 17:03:59 -0700
From: "Thor Larholm" <thor@...x.com>
To: <bugtraq@...urityfocus.com>
Subject: FW: [Unpatched] Shell and Drag'n'Drop vulnerabilities


This is a post forwarded from the Unpatched mailing list (
http://www.pivx.com/pivxlabsUnpatched.asp ), a mailing list that receive
advance notification of any security research from PivX Labs.


Cheers

Thor
 

________________________________

From: Thor Larholm
To: unpatched@...xlabs.com
Subject: [Unpatched] Shell and Drag'n'Drop vulnerabilities




Shell and Drag'n'Drop vulnerabilities

In the recent weeks there has been a lot of exploit activity surrounding
the Shell URL protocol which has so far resulted in the several exploits
and the "Akak" trojan. Joe Stewart wrote an excellent analysis [1] of
what the Akak trojan does once it has infected its users, and in this
post I will clarify both how the trojan infects a user and how to
protect against exploitation of these vulnerabilities.

When visiting the Akak website the PoC from MikX [2] is used to infect
the user, barely changed except for pointing at a different EXE. In
addition to this, the site links to "index1.html" which in turn tries to
use the older and long-patched modal script injection and MHTML Redirect
vulnerabilities to plant the file. However, of primary interest is the
MikX exploit for which there are currently no vendor supplied patches
and which also affects XPSP2.

The premise behind this Drag'n'Drop exploit is two-fold, one is the
ability to open a window with local content and the other is the fact
that dropping an IMG element will pass its DYNSRC attribute instead of
its SRC attribute. Microsoft has repeatedly tried to prevent IE from
referencing local content and even went so far as to disallow any
navigation requests to the FILE protocol in IE6SP1 from any non-local
zones. This was quickly circumvented [3] and as history shows there
continues to exist ways to reference local content. The ability to
reference local content has been the key component in most IE exploits
over the years.

When a request to Shell:startup is requested the standard rules of URL
protocols come into play. Internet Explorer determines whether a Shell
protocol exist and whether there is an associated URL protocol handler.
As with the recent AIM URL protocol handler vulnerability, you can
choose to disable all communication to the Shell protocol by
implementing a non-existant or empty URL Protocol handler, as
demonstrated below.

====== neutershellurl.reg ==========
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\PROTOCOLS\Handler\shell]
"CLSID"="{3050F406-98B5-11CF-BB82-00AA00BDCE0B}"
====== neutershellurl.reg ==========

You can find a copy of this file at

http://www.pivx.com/research/freefixes/neutershellurl.reg

The above takes care of any requests that are sent through the standard
URL protocol architecture. However, as the Akak trojan shows you can
also use the AnchorClick behavior to force IE to reference local
content. The AnchorClick behavior  circumvents the traditional request
handling and in turn renders the local directory by using the
Shell.Explorer ActiveX object. This component is designated for use by
Windows Explorer and should never be used inside IE. Taking the cue from
MSKB #240797 [4] we can killbit this component and prevent it from being
used by IE, as demonstrated below

===== neutershellexplorer.reg ======
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{8856F961-340A-11D0-A96B-00C04FD705A2}]
"Compatibility Flags"=dword:00000400
===== neutershellexplorer.reg ======

You can find a copy of this file at

http://www.pivx.com/research/freefixes/neutershellexplorer.reg

By combining the above two configuration changes you are protected
against exploitation of the Shell protocol, any DHTML Behaviors that use
Shell.Explorer for local file referencing, the Akak trojan and any
variants thereof. You can verify this independently by testing the MikX
PoC [2] or the http-equiv PoC [5]. Remember to close any already open IE
windows after you have implemented these changes.

Qwik-Fix Pro users were protected in advance against the Akak trojan
without additional updates. You can find a free copy of Qwik-Fix Pro for
personal use at

http://www.pivx.com/qwikfixDownload.asp


References:

[1] Akak analysis by Joe Stewart of LURHQ http://www.lurhq.com/akak.html

[2] Proof of Concept code from MikX
http://www.mikx.de/scrollbar/

[3] Notes on IE6SP1 by Thor Larholm
http://www.securityfocus.com/archive/1/291170/2004-03-22/2004-03-28/2

[4] How to Stop an ActiveX Control from Running in Internet Explorer
http://support.microsoft.com/?kbid=240797

[5] Proof of Concept code from http-equiv
http://www.malware.com/wottapoop.html



Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
23 Corporate Plaza #280
Newport Beach, CA 92660
http://www.pivx.com
thor@...x.com
Stock symbol: (PIVX.OB)
Phone: +1 (949) 231-8496
PGP: 0x4207AEE9
B5AB D1A4 D4FD 5731 89D6  20CD 5BDB 3D99 4207 AEE9

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation.
<http://www.pivx.com/qwikfix>

Powered by blists - more mailing lists