Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    Thor Larholm
    RE: Internet explorer .clsid vulnerability
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Internet explorer .clsid vulnerability

    This is actually a behavior that is part of Windows Explorer, not
    Internet Explorer. I think we have covered this in the past on lists as
    well. If it is not already documented somewhere it should be, as this is
    how Windows file queries (inside IE) are performed on the local file
    system.

    Basically, you must first circumvent security zone restrictions and gain
    access to execute HTML files from the local file system in the first
    place before this is an issue. At this time, it is much more interesting
    to use your newly gained privileges to plant an EXE file and execute it
    instead of just launching the already installed applications.

    When your HTML document is opened from the local file system, it's
    working directory is C:\DIR\test.html ( equivelant to the URL
    FILE://C:/DIR/test.html ). If you click on a link to "XX" from here or
    have it open automatically through an iframe, the browser asks for
    FILE://C:/DIR/XX ( "XX" through the FILE protocol from the C:/ host in
    the DIR directory ).

    In this case, we are asking the browser to retrieve
    "FILE://C:/DIR/Roozbeh.{3E9BAF2D-7A79-11d2-9334-0000F875AE17}". IE
    queries
    HKCU\Software\Microsoft\Windows\CurrentVersion\Exp lorer\MountPoints\C to
    see if the Host is known (btw, all temporary NetBIOS sessions are stored
    here as integers, my currently open share in the dirty network to
    \\someserver\c$ is labelled 6 instead of C). It then checks both HKCU
    and HKCR in order for instances of that GUID and eventually finds
    "C:\PROGRA~1\NETMEE~1\conf.exe" in
    HKCR\CLSID\{3E9BAF2D-7A79-11d2-9334-0000F875AE17}\LocalServer32\(Default
    ) which it then launches.=20

    You can see this entire registry brawl at
    http://jscript.dk/2004/5/clsid.regmon.log

    If you try to test your POC from an Internet or Intranet site you will
    see that the browser simply asks for a document on the server and in
    return gets a 404 Not Found.


    Regards

    Thor Larholm
    Senior Security Researcher
    PivX Solutions
    24 Corporate Plaza #180
    Newport Beach, CA 92660
    http://www.pivx.com
    thor@pivx.com
    Stock symbol: (PIVX)
    Phone: +1 (949) 231-8496
    PGP: 0x5A276569
    6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

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


    -----Original Message-----
    From: roozbeh afrasiabi [mailtooozbeh_afrasiabi@yahoo.com]=20
    Sent: Thursday, May 20, 2004 3:52 PM
    To: bugtraq@securityfocus.com
    Subject: Internet explorer .clsid vulnerability
    <snip>

    <a href=3DRoozbeh.{3E9BAF2D-7A79-11d2-9334-0000F875AE17}>dose not
    exist!</a>

    <snip>

  2. #2
    roozbeh afrasiabi
    RE: Internet explorer .clsid vulnerability
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Internet explorer .clsid vulnerability

    In-Reply-To: <8B32EDC90D8F4E4AB40918883281874D523591@pivxwin2k1 .secnet.pivx.com>

    >This is actually a behavior that is part of Windows Explorer, not

    Internet Explorer. I think we have covered this in the past on lists as
    well. If it is not already documented somewhere it should be, as this is
    how Windows file queries (inside IE) are performed on the local file
    system.


    The following would execute netmeeting on ie.6 when tested from an
    internet site but it dose not work on ie.6+sp1 .

    <a href="c:\x.{3E9BAF2D-7A79-11d2-9334-0000F875AE17}">here</a>
    <a href="c:\.{3E9BAF2D-7A79-11d2-9334-0000F875AE17}">here</a>


    Thanx for the info ---> me gone searching fo' more

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics