Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Date: Thu Feb 07 2002 - 17:52:38 CST
Thursday, February 7, 2002
Default installation of Internet Explorer 5.5 and 6.0 still allows us
to execute files on default installations of the target computer,
technically trivial silent delivery and installation of an executable
on the target computer.:
We cobble together new and old Components as follows : -
The manufacturer has done a really tremendous job of tightening down
any possibility to effect either 1 or 2 above. Nothing can be
activated through the Temporary Internet Files unless full path names
are known for both showHelp calling and Click() of our link.
Previously it was possible as long as all components were in the same
directory and only file names known.
We are able to retrieve from the Temporary Internet File our
trojanised html, determine the location of it, write this location
out to our showHelp call and thereafter execute our remote link.
We create a very simple *.html file like so:
this will pull our *.chm into the Temporary Internet File
when then include the Guninski scripting to determine the location of
our *.html file like so:
we then take that location information and write it to a simple html
form like so:
document.write(\'<form><input type=\"hidden\" size=\"40\"
technical note: it seems the myriad of patching to date does not make
it possible to pass the location directly to the showHelp call. It
must be written to the form which can then be automatically submitted:
before we do all that we create our very simple malware.chm and
include our link object like so:
this is particularly interesting as we are able to pass a link to the
mshta.exe, which in turn will open from the remote site our *.hta
which includes our executable. All without warning.
technical note: the possibility is excellent to repeat the entire
process above directly inside the *.chm file and drop an *.exe from
within the *.chm into the same Temporary Internet File. Using our
Guninski scripting to determine the location of the *.chm and write
that to the link parameter within it: value=\"\'+path+\'\\\\malware
.exe\"> and execute it.
So what happens?
We construct our trojanised *.html file and send it off to our target
computer. This can be via mail or news. The recipient receives the
mail message and attached *.html file. We then convince our
unsuspecting recipient to open our *.html. This should be quite
trivial, particularly in news as the attached file is in fact nothing
more than a 500 byte html file.
Consider the following scenario in your favourite web design news
Carefully note: there is a hardened security warning when attempting
to open attached *.html file. However our combination call for
assistance coupled with nothing more than a legitimate *.html file
should prove more than tempting:
(screen shot: http://www.malware.com/duh.png 18KB)
Why does it happen?
Because our simple *.html file is an attachment, security has it
transfer to the Internet Temporary File for opening, under the
security browser\'s settings. However, precisely because it is
physically opened within the TIF, we can use our Guninski scripting
to determine the exact location, write that exact location to our
form and call our *.chm where it too resides.
Working Example: (includes harmless *.exe -- the *.chm is hardcoded
[note: due to pathetic technical reasons our *.chm is off-site and
may delay in transferring to the TIF and could possibly fail]
nb: working example must be attached to mail or news
1. Be aware of \"innocent\" *.html files in mail and news
2. Disable Active Scripting and Active X controls
3. Disable the HHCtrl ActiveX control
4. Disable or Remove Mshta.exe [although if an *.exe embedded
directly into the *.chm then this has no impact]
Critical Note: we are seeking a competent fast hosting service, that
can maintain exotic mime types on the server (including all windows
media files, *.chm files, *.mhtml files etc], we cannot demonstrate
when slob services cannot maintain the correct mime types on the
server, and files parse as text regardless of what they are. We
require much, +/-25MB space, handful of email addresses, must have
PHP, server should be fast and stable. Not much bandwidth required,
only +/-1.2 million hits since June 2002. Contact sinkhole
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Delivery co-sponsored by Qualys - Make Your Network Secure oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Go Beyond PARTIAL Security: FREE White Paper
Stop hassling with half-baked ENTERPRISE SECURITY. FREE White Paper shows you how to ensure TOTAL security for your Internet perimeter with the most current and most complete PROACTIVE Vulnerability Assessment solution. Get your FREE White Paper now. Click here! https://www.qualys.com/forms/techwhite_86.html oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo