Subject: [NT] Force Feeding files to Internet Explorer
Date: Tue, 27 Jun 2000 19:46:44 +0200

          Force Feeding files to Internet Explorer
--------------------------------------------------------------------------------

SUMMARY

Microsoft Internet Explorer 5 and accompanying mail and news clients on
Win95, Win98 and Win2000 suffer from a security hole that enables remote
attackers to force a file onto the target computer despite all prompts and
warnings.

DETAILS

Vulnerable Systems:
IE5.0 (all Windows platforms)
IE5.1 (all Windows platforms)

Example:
Create a very simple html frameset and embed our file in base 64 encoding:

<frameset rows="10%,*">
<frame src="mars.exe" >
</frameset>

Create a simple html mail or news file and send it to the target computer.
Upon receipt and opening, the recipient will be prompted whether they wish
to 'save' or 'open' or 'cancel'. However, neither of these work. While the
recipient contemplates the choices, the file is placed into the temp
folder. Selecting any one of the three choices proves useless - the file
is still delivered to the temp folder. Even when setting the so-called
Security Zone settings to DISABLE generates an error message, but the file
is still delivered to the temp folder.

The Vulnerability

Create a second file containing a new ActiveX control
(CLSID:15589FA1-C456-11CE-BF01-00AA0055595A) which allows us to execute
files locally. Embed the simple JavaScript that runs this together with
the ActiveX control in base64 and embed that in a second html frame:

<frameset rows="10%,*">
<frame src="mars.exe" >
<frame src="lunar.mhtml" >
</frameset>

Apply the very simple HTTP-EQUIV meta tag known as refresh:

<meta http-equiv="refresh"content="5;
url=mhtml:file://C:\WINDOWS\TEMP\lunar.mhtml">

(NOTE: Since some temp directories do not reside on C:\WINDOWS\TEMP, and
therefore this demonstration will not always work).
Repack the binary once again in base64.

On the following generic and diluted web-based working example the link is
clicked, the file mars.mhtml will deposit both the *.exe and second
*.mhtml files into the temp. The client will be prompted as to either
'save' 'open' or 'cancel' regardless of the choice as soon as the prompt
has been closed down, the meta refresh will bounce to the *.mhtml in the
temp, open it and execute the JavaScript and ActiveX control and run the
*.exe.

Since the html file will be launched locally (from C:\WINDOWS\TEMP) none
of the so-called Security Zone settings apply.

Working Example:
 <http://members.xoom.com/malware/mars.mhtml>
http://members.xoom.com/malware/mars.mhtml

(NOTE: to be executed off the web. Harmless *.exe incorporated. 5-second
delay after clearing the prompt).

Can we do this from an email?

Yes. However, with greater likelihood of failure. Consider the following:

Create two sets of html messages:

(a) one comprising the file to be delivered:

<frameset rows="10%,*">
<frame src="refresh.bat" >
</frameset>

Working Example:
 <http://members.xoom.com/malware/refresh.eml>
http://members.xoom.com/malware/refresh.eml

(NOTE: to be executed from mail client. Simple *.bat containing @exit)

(b) the second comprising a fraudulent, manufactured *.url:

 Content-Type: application/octet-stream;
 name="Microsoft TechNet Security.url"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 filename="Microsoft TechNet Security.url"

 [DEFAULT]
 BASEURL=C:\WINDOWS\TEMP\refresh.bat
 [InternetShortcut]
 URL=C:\WINDOWS\TEMP\refresh.bat

We include a fake link: <font color=blue style="cursor:hand">....

The recipient will then be forced to entertain the fraudulent *.url

Working Example:
 <http://members.xoom.com/malware/secureme.eml>
http://members.xoom.com/malware/secureme.eml

(NOTE: to be executed from mail client.)

Far Fetched Scenario?

Yes indeed. Send the first mail message to the target computer followed by
the second. The recipient will open the first mail message, be advised
that a file is attempting to download and what would they like to do:
'save' or 'open' or 'cancel' while this is being contemplated, the file is
delivered to the temp folder. The recipient then continues with their
morning activities of reading their email and opens the second mail
message. Certainly innocent enough looking and of course Urgent and from a
Trusted SourceT. Through the false link, they are then forced open the
attached *.url which points to the C:\WINDOWS\TEMP\ where the delivered
file waits.

This scenario can be incorporated into one single self-contained mail
message. However the likelihood of the recipient opening the *.url after
seeing an attempted file download warning would (or should) be slim.

ADDITIONAL INFORMATION

The information has been provided by  <mailto:sinkhole@malware.com>
CareTaker.

========================================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.