Microsoft's hasty response to last year's LoveLetter virus doesn't provide real protection from hostile programs, say two professors from the US Air Force Academy. Dr. Martin C. Carlisle and Capt. Scott D. Studer will present a paper at an information security workshop in June that details the weaknesses in Microsoft's Outlook Email Security Update and provides sample VBScript code to defeat one of the update's key features.
Most of the media attention given to the tightened Outlook security features has spotlighted the blocking of particular attached files. In their paper, "Reinforcing Dialog-Based Security," the professors focus instead on the "object model guard" that pops up a dialog box whenever an external program—or even code on an Outlook form—tries to access address information or send a message. The program or form can't proceed unless the user authorizes it by clicking a button.
Carlisle and Studer assert that with a small amount of code, programmers can easily circumvent these dialog boxes. With a compiled executable (.exe) file, they say, you can defeat them and even keep them hidden from the user.
I agree with Microsoft's response that once a malicious party tricks the user into running an .exe file, that program can pretty much do anything on the user's machine. Having the security update dialog boxes hidden becomes the least of your worries if a rogue program runs on your system.
Microsoft hasn't commented about the professors' demonstration of using VBScript code to get around the dialog boxes. Not being an expert on the Windows Script Host (WSH) 2.0, I didn't realize that WSH supports the AppActivate, SendKeys, and Sleep methods. WHS 2.0 was available on Windows 2000 machines and as a separate download before Microsoft released the Outlook Email Security Update.
The professors' paper (see the URL at the end of this column) includes sample VBScript code that creates a script on the user's machine. The code employs AppActivate and Sleep to wait for the object model guard to pop up the address book or send prompt, and then uses SendKeys to press the necessary button on the dialog box. This approach works despite the 5-second delay on the send authorization dialog box.
I wonder whether the Outlook team charged with building the object model guard into the security update consulted the WSH programmers and challenged them to defeat the object model guard. Given the ease of using a script to defeat the prompts, I guess not.
Carlisle and Studer suggest alternative approaches to the Outlook object model guard, plus some changes in the OS to tighten dialog box-based security. They suggest placing Outlook's security at the level of the address book and transport components, rather than at the application level. For the object model guard dialog boxes, they'd like to see Microsoft take measures to prevent an executable file from hiding the dialog boxes, or at least warn the user if a program tries to hide a dialog box.
The professors also recommend measures to defend the computer's system clock to stop a malicious program defeating the 5-minute delay for the send authorization dialog box. A bitmap—a picture on the dialog box—could tell the user the key sequence to press for authorized access.
As a simple protection, Carlisle and Studer recommend dissociating VBScript .vbs files from the WSH so that those files can't run code when the user double-clicks them. Another idea would be to improve the OS by beefing up the dialog box mechanism, achieving a secure dialog box that requires user response and can't be defeated by something as simple as SendKeys.
Microsoft had several months between the release of the initial security update and the release of Outlook 2002, yet the object model security features in Outlook 2002 vary little from those in the initial update release. Maybe Microsoft will take a look at the professors' suggestions for the next Outlook version. While they're at it, maybe they can create a mechanism that will secure Outlook code against harmful external programs while letting standalone users and corporations that don't use Exchange Server take advantage of Outlook's superb programmability.
In the meantime, I suggest you review your mail system to make sure it blocks all .vbs files.
