Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security NTBugtraq
[Top] [All Lists]

FW: [Unpatched] Shell and Drag'n'Drop vulnerabilities

Subject: FW: [Unpatched] Shell and Drag'n'Drop vulnerabilities
Date: Fri, 3 Sep 2004 17:00:25 -0700
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@pivxlabs.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@pivx.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>

-----
NTBugtraq Editor's Note:

Want to reply to the person who sent this message? This list is configured such 
that just hitting reply is going to result in the message coming to the list, 
not to the individual who sent the message. This was done to help reduce the 
number of Out of Office messages posters received. So if you want to send a 
reply just to the poster, you'll have to copy their email address out of the 
message and place it in your TO: field.
-----

<Prev in Thread] Current Thread [Next in Thread>