We take a few steps sdrawkcab and examine the forcing of a file onto the target computer manually and executing it under false pretences. Certainly less spectacular, but equally as important: Saturday, 24 June 2000 Microsoft Internet Explorer 5 and accompanying mail and news clients on win95, win98 and win2000 enjoy a unique status in that they choose to ignore user input. Specifically, we are able to manually force a file onto the target computer despite all prompts and warnings. A) 1. How so? We again create a very simple html frameset and embed in base64 our file: <frameset rows="10%,*"> <frame src="mars.exe" > </frameset> 2. What will happen? We 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' - none of these work. While the recipient contemplates the choices, the file is injected into the temp folder. Selecting any one of the three choices proves useless. The file is still delivered to the temp folder. In addition setting the so-called Security Zone settings to: DISABLE generates a different prompt that is: "...your security settings do not allow file downloads...[something to this effect]" with the only option being: OK. Again selecting this proves useless. The file is still delivered to the temp folder. 3. And? We then create a second file containing a different new ActiveX control (CLSID:15589FA1-C456-11CE-BF01-00AA0055595A) which allows us to execute files locally. We embed the simple JavaScripting 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> We again 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"> and repack once again in base64. 4. Results being? 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. Again, because we are working locally (from C:\WINDOWS\TEMP) none of the so-called Security Zone settings apply. DISCLAIMER Working Example: Note: to be executed off the web. Harmless *.exe incorporated. 5-second delay after clearing the prompt [win2000 places the files in c:\documents - this working example is constructed for default installs of win95 and 98] mars.mhtml Yes; and for those seemingly quick on the uptake: Here: mars.eml and here: mars.nws B) 5. Can we do this from 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> DISCLAIMER Working Example: Note: to be executed from mail client. Simple *.bat containing @exit refresh.eml (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 DISCLAIMER Working Example: Note: to be executed from mail client. secureme.eml 6. 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 Source�. Through the false link, they are then forced to 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 after noting an attempted file download warning and then continuing with opening the *.url would (or should) be even slimmer. However, you never know. Notes: 1. Tested on default installs of win95, win98 and win2000 and IE5.0 and IE5.1 with accompanying mail and news clients. All up-to-date with security patches and all with the so-called Security Zone set to: DISABLE where possible. 2. The Outlook Patch should effectively contain or disallow the *.url attachment. There is a workaround for that. 3. The files are still delivered to the default temp folder. Relocate the default temp folder. 4. Submitted to CERT 6/23/00 VU#26654 http://www.cert.org/advisories/CA-2000-14.html Submitted Saturday, 24 June 2000 to BUGTRAQ http://www.securityfocus.com/bid/1394 [ 20 July, 2000 - Manufacturer's Solution: http://www.microsoft.com/technet/security/bulletin/MS00-046.asp ] |