lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: 1 at ( )
Subject: How to Break Windows XP SP2 + Internet Explorer 6 SP2

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.

d) 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


Powered by blists - more mailing lists