Round One: "DLL Proxy" Attack Easily Hijacks SSL from Internet Explorer

From: Disclosure From OSSI (disclosure_at_ossecurity.ca)
Date: 02/09/04

  • Next message: Gadi Evron: "Re: Outbreak warning: possibly Mydoom.C (Now Deadhat/Vesser)" 
    To: <bugtraq@securityfocus.com>
Date: Mon, 9 Feb 2004 13:24:04 -0500

    Topic
    LoadLibrary / LoadLibraryEx Weakness

    Release Date:
    February 9, 2004

    Date Reported:
    Reported to Microsoft on December 9, 2003

    Severity:
    Medium (Interception of SSL traffic, RSA encryption, and others)

    Systems Affected:
    Windows 95, 98, ME;
    Windows NT, 2000, XP, 2K3 (ACL limitations apply)

    Summary:
    A LoadLibrary / LoadLibraryEx weakness makes SSL on Internet Explorer very
    vulnerable to a “DLL proxy” attack. If exploited, unencrypted data can be
    intercepted before Internet Explorer (IE) uses the SSL module to encrypt the
    data. Therefore, confidential information such as bank accounts and
    passwords could be stolen. Many applications are vulnerable to “DLL proxy”
    attack with different ramifications.

    Description:
    There is a system-wide Win32 weakness on Windows platforms. It is a
    LoadLibrary / LoadLibraryEx weakness attributed to how it dynamically
    searches and loads DLLs into processes.

    (Reference: the documentation for LoadLibrary / LoadLibraryEx from Microsoft
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
    e/loadlibrary.asp - When no path is specified for calling LoadLibrary /
    LoadLibraryEx the system searches the directory from which the application
    is loaded first, before it searches the system or other directories.)

    Microsoft has provided mitigation such as Access Control List (ACL) for
    program folders using NTFS. But this mechanism can only protect a limited
    segment of WINDOWS users against this “DLL proxy” attack. For example, XP
    Home Edition (SP1) is installed by default with administrator privileges for
    accounts and therefore ACL for program folders are wide open to be modified.
    Many Windows platforms use an un-secured file system such as FAT or FAT32
    without ACL protection.

    To exploit this weakness, a malicious DLL module can be introduced to the
    directory for a targeted application such as IE. When the application
    intends to load a DLL from the system directory, it instead loads a
    malicious DLL module from the application directory. The malicious DLL
    module intercepts all the function calls originally intended for a DLL, such
    as wintrust.dll, located in the system folder. This kind of operation has
    been termed “DLL proxy” by some in the past.

    OS Security has verified this weakness in IE, on Windows NT, 2000, XP:

    I. Malicious DLL can be delivered using the following typical ‘delivery
    techniques’:
    1. Any un-patched remotely exploitable BOF vulnerability;
    2. Any new program users download and run from the Internet; and
    3. Any un-patched web-browser vulnerability allowing targeted file saving
    within scripts.

    II. Using this malicious DLL to exploit this Win32 system-wide vulnerability
    as described above to:
    1. Log and send out so-called “secured” SSL traffic in its unencrypted HTML
    format to others on the Internet;
    2. Intercept plain messages before RSA encoding and after RSA decoding and
    send out the plaint text out;
    3. Plant delayed DoS scheme;
    4. Launch viruses/worms within normal processes as threads, and etc.

    For additional details please contact: info@ossecurity.ca or visit
    www.ossecurity.ca

    Recommended Protection:
    · Migrate from Windows 9X to a securable Windows platform such as Windows
    NT, 2K, XP and follow proper security configurations to enable Access
    Control List protection to mitigate “DLL Proxy” attack. For daily normal
    usage, do not use an account with administrative privileges.
    · Use other Web browsers than Internet Explorer to do online transactions on
    Windows 95, 98 or ME;
    · Download a free Secure Transaction Module (STM) program from OS Security,
    Inc. to verify whether Internet Explorer is under “DLL Proxy” attack every
    time when IE is used to do online transaction. Click
    http://www.ossecurity.ca/code/getdl.php?ID=5002&Code=4567 to download; or
    · Consider using other operating systems such as Linux as an alternative to
    do online secure transactions or perform sensitive data processing.

    Vendor Status:
    Microsoft was informed of this weakness in December 2003. As of February 5,
    2004, Microsoft has not provided any indication that they intend to provide
    any remedies for the affected Windows configurations.

    Copyright (c) 2003-2004 OS Security, Inc.
    Permission is hereby granted for the redistribution of this alert
    electronically. It is not to be edited in any way without express consent of
    OS Security, Inc.

    Disclaimer
    The information within this paper may change without notice. Use of this
    information constitutes acceptance for use in an AS IS condition. There are
    NO warranties with regard to this information. In no event shall the author
    be liable for any damages whatsoever arising out of or in connection with
    the use or spread of this information. Any use of this information is at the
    user's own risk.

    Feedback
    Please send suggestions, updates, and comments to:

    OS Security, Inc.
    http://www.ossecurity.ca
    info@ossecurity.ca

  • Next message: Gadi Evron: "Re: Outbreak warning: possibly Mydoom.C (Now Deadhat/Vesser)"

    Relevant Pages

    • [Full-Disclosure] Round One: "DLL Proxy" Attack Easily Hijacks SSL From Internet Explorer
      ... A LoadLibrary / LoadLibraryEx weakness makes SSL on Internet Explorer very ... Many applications are vulnerable to “DLL proxy” ... the documentation for LoadLibrary / LoadLibraryEx from Microsoft ...
      (Full-Disclosure)
    • Re: Loading DLL
      ... It's what your DLL ... When I load this dll the first time using Loadlibrary API I get an error, ... I tried also in VC using the api LoadlibraryEx and if I disable the ... MessageBox(NULL, (char *)lpMsgBuf, "GetLastError", ...
      (microsoft.public.win32.programmer.kernel)
    • Re: questions about using LoadLibrary, MessageBox and FreeLibrary in DllMain
      ... > It must not call the LoadLibrary or LoadLibraryEx function (or a ... > function that calls these functions), because this may create dependency ... > loops in the DLL load order. ... This can result in a DLL being used before ...
      (microsoft.public.win32.programmer.kernel)
    • Loading DLL
      ... I made a dll in VC 2003. ... When I load this dll the first time using Loadlibrary API I get an error, ... I tried also in VC using the api LoadlibraryEx and if I disable the ... MessageBox(NULL, (char *)lpMsgBuf, "GetLastError", ...
      (microsoft.public.win32.programmer.kernel)
    • Load dll
      ... I made a dll in VC 2003. ... When I load this dll the first time using Loadlibrary API I get an error, ... I tried also in VC using the api LoadlibraryEx and if I disable the ... MessageBox(NULL, (char *)lpMsgBuf, "GetLastError", ...
      (microsoft.public.vstudio.development)