Network Defense by Rik Farrow Beware geeks bearing gifts--The wonders of active content that made Melissa and Explorer-worm.zip possible In the good old days, active content was hardly a glimmer in some developer's eye. Transferring executable content took a conscious effort on both the sender and the receiver's ends, and you didn't have to worry about automatically executing anything. Rocket scientists, programmers, and engineers used the Internet, and the only dangerous things shipped by email were practical jokes. Netscape, in its push to make its Web browser more useful and interesting, introduced the concept of including executable code in Web pages. And, several years prior to this, Internet email had been extended so that it could include executable content, and support mail readers that could automatically execute attachments. It is this extension to email that makes email viruses, Melissa, and the explorer Worm possible--the Multipurpose Internet Mail Extension, or MIME. While it is possible to disable the execution of attachments or downloaded Web-content, you will find controlling peoples' desktops almost impossible in practice. If you choose a policy of denying dangerous gifts, the place to block them is at the entrance to your network, your firewall. MIME MIME became an Internet standard (RFC 1341) in 1992. Earlier versions of Internet email only supported US ASCII for a couple of reasons. In those days, the Internet was a US experiment, so US ASCII was an acceptable character set. The designers of email also wanted to avoid creating a standard that would not be interoperable in all (US) environments. Plain, old US ASCII was a useful lowest common denominator, and would also support conversion to the other email systems of that time. But using only text limits what email can do. The developers of MIME intended to overcome these limitations by creating a flexible framework that could support almost any type of content imaginable, while still maintaining a standard that would work equally well in all situations. Since first being accepted as a standard, MIME has been revised twice (RFC 1521 and 2045), most recently in 1996. Internet email still does not support the direct transmission of binary files. Binary files, such as images, zip archives, or executable files, must be encoded so that they appear as ASCII within email. But the MIME headers provide information to the mail user agent (MUA) so that it can invoke the right application to display the image, unzip the archive, or execute the encoded program. And this is where the fun begins. As typical in RFCs, the security requirements for MIME consist of one paragraph covered in RFC 2048, the registration procedures. Easily summarized, an entity registering a new subtype should identify known risks. The authors state that it is not necessary to conduct a full security review, but simply that if there is some risk, the risk should be mentioned. PostScript is used as an example. The PostScript language was designed for depicting pages to be printed, and included syntax for executing commands and deleting files. So, you could execute a PostScript viewer on your desktop, and it would then run a program or delete files, depending on the content of the PostScript document. While this is potentially dangerous, it is nothing compared to some of the application subtypes now registered. And PostScript viewers are rare except on UNIX systems, and UNIX vendors have modified the viewers so that they cannot delete files or execute commands by default. As examples go, PostScript is very benign. A better example would be any interpretive language, such as bash, Java, Perl, VBScript, Tcl, or Python. If the MUA could be convinced that the mail message should be passed to one of these interpreters, just about anything can be done--files deleted, mail messages sent, systems probed, or trojan horses installed. Fortunately, UNIX systems, where MIME was first used, did not configure interpreters as part of MIME-capable MUAs. The Web You may be wondering what email and MIME have to do with Web browsers. As has often happened, the designers of HTTP borrowed from other, existing and functioning standards for the new HTTP standard. In particular, the headers used in HTTP bear some resemblance to mail headers, and include MIME as well. MIME turned out to be perfectly suited for supporting Web browsers. With just two lines, a Web server can tell the Web browser how to handle the contents that follow the header. The first line is always the same: MIME Version: 1.0. Even though MIME has been revised twice, there has been no reason to change the version number. A comment in parentheses may be included in this line, but can safely be ignored. The next critical line for a browser or a MUA is the Content-Type, for example, text/html. The content-type is split into one of seven top level types and a subtype by a slash. The top level content-types are fixed, although anyone can use an extension type simply by beginning the type with X- (or x-). Vendors and programmers are free to add new subtypes, following the instructions in RFC 2048. MIME helps a browser by telling it how to interpret the body of the file just received. If the content-type is text/html, then the browser simply displays the message as HTML. When the content-type is image/gif, the browser expects a binary image file, and displays it within the browser window. But if the content-type is application/ms-word, the browser cannot handle this on its own, but must execute a helper application, in this case, Microsoft Word. Then, depending on the version of the browser involved, the user may be prompted and Word, if installed, will be executed. And the content-type application/msword is preconfigured into both Internet Explorer and Netscape Navigator/Communicator. MIME makes it possible to email the Word macro virus of your choice to the victim of your choice. Newer versions of Internet Explorer will not automatically execute Word, but will instead prompt the user first. Internet Explorer will also prompt the user anytime the content-type indicates that it needs to start a helper application, or, in the case of a file ending in .exe or .com, simply execute the received binary file as the application itself. The Melissa virus used VBScript to carry out its deeds. If the email message was received from someone within your local network, Internet Explorer's security may permit executing the VBScript without asking for permission. If the mail message came from any other source, the user gets prompted first. In the case of Melissa, the attack relied on social engineering to convince the user to permit execution. Social engineering will not work every time, but once one internal user permits execution, Melissa will spread like wildfire on the internal network. The Explorer-worm.zip was an executable file. Like the Melissa virus, it relied on social engineering to get someone within the organization to get the virus going which the worm did by pretending to be a self-extracting zip archive. Once executed, the worm changed the registry so it would be restarted on reboot and sent auto-replies to the senders of any email still in the inbox. Again, this was clever social engineering, as more people will trust what looks like a reply to some of their own email. The payload of the worm deleted various Office files, making it a destructive virus. Desktop Blockade Users can disable helper applications in their browsers and MUAs, but it is unlikely that they will want to do so. Both Internet Explorer and Outlook use the same registry entries to control active content. You reach the same control panel taking two different paths. For Outlook, you select the Tools/Options pull down, and pick the Security tab then choose Settings. For IE, you start with View/Internet Options, then choose the Security tab. In either case, you will discover settings for four different sources, the Internet Zone, the local Intranet, Trusted Sites, and Restricted Sites. In IE 4.0, the default security level is Medium for the local Intranet and the Internet zone, which means that you will be prompted befor IE will run "potentially damaging content". Only the Restricted Zone, which is empty until you add sites to it, is in the High security zone, where potentially damaging content is never executed. The Trusted Zone, which requires the use of SSL and a valid site certificate, has the default security level set to low. If you are running an earlier, buggy version, of IE, any computer could be included in the local intranet if its domain name does not include dots (as it does when a URL uses the octal value for the 32 bit IP address). What this means to the desktop user is that before they can read the Word document a co-worker just emailed to them, they must answer Yes to the dialog Outlook displayed. The same dialog would appear when an outsider sent the user a Word document. And unless the user either changes the Security setting for the Internet Zone, this will always be true. So what is easier for the user: setting the security setting to Low, so he or she will never be prompted, or leaving things as they are? Even if the user does not change the security setting, the user can still answer Yes when the answer should be No. Netscape 4.0 does not include zones. But Netscape does make it easier to determine what you should do with dangerous content. You can see how Netscape handles applications by selecting View/Preferences, then looking under Navigator/ Applications. By default, Excel and Word documents on the MacOS 8 version of Navigator are saved to disk, preventing the automatic execution of files that might contain Word macro viruses. IE does not make the linkage between the content-type or filename extension visible, but you can find these by using regedit, and looking under HKEY_CLASSES_ROOT. Filename extension mappings appear right in the beginning of this hive. The High Road Being able to receive and view Word documents received in email is just too appealing for most people. While I personally never permit my MUA to invoke Word, most people do. And what about other dangerous content-types, such as VBScript, Perl, or executables? Because you really cannot trust your users, what can you do? The simplest approach, although not without its drawbacks, is to use your firewall. Many firewalls permit you to selectively block certain content-types. For the firewall, this is easy enough to do (for application gateways): look for the content-type headers, and replace content designated by firewall configuration as dangerous with a message saying that the potentially dangerous content has been deleted. My local firewall happily deletes potentially dangerous content, including all attached Office files. I am certain that you can see the problem with this approach immediately. If your firewall begins deleting all Word documents, your users will be up in arms faster than you can say "Sorry". A good compromise would be to check emailed Office documents for macro viruses, and to block other potentially dangerous applications at your firewall (zipped files, anything ending in .exe, anything with a subtype indicating that an interpreter must be used to execute it--Perl, VBScript, Python, bash, etc). Someday, we may be able to rely on using digital signatures that can authenticate the sender of potentially dangerous content. But until that day has arrived, I suggest you not allow unexpected gifts through the front door. Resources: You can download the Request for Comments (RFCs) mentioned in this article using the search page at: http://www.rfc-editor.org/rfcsearch.html. Just fill in the RFC number in the box in the left hand panel. The current list of registered type/subtypes can be downloaded from: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ media-types. The on-line version of Securing Java, a book with information specific to Java, but also information about the problems inherent in mobile code: http://www.securingjava.com/.