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

From: Thor Larholm (thor_at_PIVX.COM)
Date: 09/04/04

  • Next message: simon edwins (BITS): "SQL Server 2000 SP2 xp_sendmail bug" 
    Date:         Fri, 3 Sep 2004 17:00:25 -0700
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

    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.
    -----

  • Next message: simon edwins (BITS): "SQL Server 2000 SP2 xp_sendmail bug"

    Relevant Pages