| Downloads |
|---|
| 27072.zip |
When administrators ask me how to prevent malicious email attachments from attacking users, a certain story always comes to mind. When I was the tender age of 8, neighborhood bullies harassed me whenever I took a particular shortcut through the woods on my way to the store. Mom (brilliant genius that she was) told me to stop taking the shortcut. Behold—her solution worked perfectly. The moral of the story: Don't let malicious files get to users in the first place.
Antivirus software, security patches, and user education can help you stop such files, but unfortunately, educated users are infamous for executing any malicious file attachments that make it through your defenses. To stop users from hurting themselves, you can block potentially dangerous file types from getting past your email server and client systems. To prevent users from executing malicious files that do get through, you can block Instant Messaging (IM) transfers, prevent automatic file execution or manual launching of unapproved executables, and reveal hidden file extensions so that users know what they're dealing with.
Which Files to Block?
With the possible exception of educational and research networks, most users don't have a legitimate need to execute most of the file attachments that they receive, and too many users are likely to execute a joke executable or VBScript file. Therefore, you should prevent—or at least limit—users' ability to receive potentially dangerous files. If a user has a legitimate, demonstrable need, you can educate the user in safe computing practices and permit access, but restricting access by default will help stop the free flow of dangerous file types, the majority of which aren't business-related.
Any file that can write to disk is potentially dangerous, but worry specifically about the file types that you know someone can use maliciously. (See the Web-exclusive sidebar "Registered File Types," http://www.secadministrator.com, InstantDoc ID 27077, for information about how Windows treats certain file types.) Weigh the risk and benefit of each file type, and deny those that have a poor trade-off. For example, Microsoft Office documents can easily contain malicious scripting or macros, but Office's default security settings prevent the majority of such code from executing. Most users have a legitimate reason to use such documents, so you probably want to let users receive those file types. Web Table 1 (http://www.secadministrator.com, InstantDoc ID 27072) lists the most dangerous file types (sorted by registered file extension), a brief description of each type's associated programs, and the primary risks that each type poses. Malicious coders most often use .bat, .chm, .com, .eml, .exe, .hta, .htm, .html, .js, .pif, .reg, .scr, .shb, .sms, .url, and .vbs files, so I suggest that at a minimum you restrict access to these file types by default.
After you establish a list of files to keep from users, what can you do besides implement the usual antivirus scanners, security patches, and user education programs? To begin, stop user access at the source: the email server or client.
Block Files at the Email Server or Client
Your first line of defense is to configure your organization's email server to block dangerous file attachments. In a Microsoft Exchange Server environment, you can block file access at the email server and give individual Microsoft Outlook users varying levels of access.
Administrators of Exchange Server 5.0 and later can apply the Outlook security template (outlooksecurity.oft) to regulate the file attachments that users can see and execute. (For more information about this process, see the Microsoft article "OL2000: Administrator Information About the Outlook E-mail Security Update," Q263297, http://microsoft.support.com, or the Microsoft Office Resource Kit Journal article "Customizing the Outlook 98/2000 E-mail Security Update," http://www.microsoft.com/office/ork/2000/journ/outsecupdate.htm.) You apply the security template to a new public folder called Outlook Security Settings. Outlook 2002, Outlook 2000 Service Pack 2 (SP2), and Outlook Express come with built-in file attachmentblocking ability, and the newer corporate Outlook clients automatically look for the Outlook Security Settings folder when they communicate with the Exchange server. Earlier versions of Outlook 2000, as well as Outlook 98, require the Microsoft Outlook 98/2000 E-mail Security Update patch to implement file-blocking functionality, and you must modify the registry to enable the new security settings. If you want more flexibility and functionality, products such as TenFour's TFS Secure Messaging-Server or either version of Trend Micro's ScanMail for Exchange can block attachments before they get to your Exchange servers.
You can also block attachments at the client desktop. Outlook 98 and later provide this ability. The free Outlook 2000 SR-1 Update (http://office.microsoft.com/downloads/2000/out2ksec.aspx) for Outlook 2000 systems initially blocks 37 of the file types listed in Web Table 1 and might block other file types depending on which service packs you've installed on your systems. Outlook 2002 blocks more file types by default and includes increased functionality for specifying blocked file types. Standalone Outlook 2002 users can use a registry edit to customize the blocked-file list (although they can't add more file types to the default list); see the Microsoft article "OL2002: You Cannot Open Attachments" (Q290497, http://support.microsoft.com) for more information about this approach. Of course, don't apply any security updates or registry changes that limit default functionality until you first consider and test the effects.
In a non-Exchange environment, many email servers can block certain file types according to name, extension, or contents. Many antivirus programs, enterprise firewalls, and Internet gateways also contain file-blocking functionality. You can find no less than a dozen third-party programs that sit between the Internet and your email server and inspect and block files. (Roaring Penguin Software's MIMEDefang is a good freeware product for Perl administrators with UNIX or Linux experience; Clearswift's MIMEsweeper products and Trend Micro's ScanMail for OpenMail products are excellent file-blocking and file-scanning programs.) Examine your existing software to determine whether it includes a file-blocking feature—many administrators already own the appropriate tools without realizing it. If you're still looking, an Internet search that specifies your email platform and the phrase block file attachments will return a long list of candidates.
Block IM File Transfers
IM is becoming one of the quickest ways for malicious files to sneak past firewalls and guarded email servers. If your end users have IM capabilities—and they probably do, with or without your knowledge—make sure your antivirus solution scans files sent through IM. (Keep in mind that malicious code can enter a PC through many routes—e.g., IM, network, Internet, removable media, email, PDAs—so placing antivirus protection anywhere but on the PC can let malicious code sneak by.) Most popular virus scanners automatically scan files that users save or open through IM, and a growing number of scanners specifically watch IM communications. SOFTWIN's BitDefender was one of the first scanners to specifically protect IM users, and IM file-attachment scanning is a key new feature of Symantec's Norton AntiVirus 2003. ScanMail products monitor and protect the IM functionality of Exchange 2000 Server or Lotus Notes servers.
You can also configure most client systems to refuse file transfers, or you can configure your firewall to block file transfers that use a dedicated file-transfer IP port number. And educate users about the dangers of IM file transfers. Some IM attacks don't even need a user to actively use and open an IM session; the mere installation of the IM program, which is the default on most new machines, is enough opening for an attack.
Stop Automatic File Executions
Intruders can use HTML and Internet content in dozens of ways to deliver and automatically execute malicious files. Configure email clients to disable active content by default, and you significantly decrease the threat to your environment.
Make sure you configure browsers and email clients to ask for confirmation before file downloads. When you enable default security, Microsoft Internet Explorer (IE), Outlook, and Outlook Express usually display a dialog box to prompt users to accept file transfers before downloading them. IE also lets you prompt users to decide whether to open a file after a completed download, according to each file extension in Windows Explorer's Registered file types list. To configure this dialog box in Windows 2000 systems, open Windows Explorer; select Tools, Folder Options from the menu bar; go to the File Types tab; select a file type; and click Advanced. Select or clear the Confirm open after download check box.
Also convert all incoming email content to plaintext, if possible. Permitting users to access HTML, scripting, and other active content is like asking for malicious-code problems. Outlook 2002 includes functionality to convert such content to plaintext. Apply Outlook 2002 SP1 or later. Then, open a registry editor and navigate to the HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Options\Mail registry subkey. Create the ReadAsPlain entry (of type REG_ DWORD), and assign it a value of 1. (Be aware, though, that disabling all nonplaintext content can create strange-looking or blank email messages.) You can find a few free tools, such as Russ Cooper's NoHTML, that you can use to make this conversion in Outlook 2002 or Outlook 2000.
Make sure you apply the most recent IE and Outlook patches to all client systems. Also, configure Outlook clients to apply IE's Restricted sites security setting to messages. In Outlook 2002 and Outlook 2000, choose Tools, Options from the menu bar; go to the Security tab; and view the Secure Contents section. Set the Zone option to Restricted sites. (You can use Group Policy or system policies to automate this process; see "Controlling Group Policy, Part 1," November 2000, http://www.winnetmag.com, InstantDoc ID 15704, for more information. For more information about securing Outlook, see "Access Denied: Reducing the Risk of Viruses from HTML Email," June 2002, http://www.secadministrator.com, InstantDoc ID 25015.)
Block File Launching
Any good security administrator assumes that his or her first, second, and third levels of defense will fail at some time. A malicious file will eventually sneak past the file-blocking mechanisms I've described so far, so try to prevent users from launching unapproved executables.
In Win2K or Windows NT environments, you can accomplish this goal through the use of third-party software, registry settings, policy files, and Active Directory (AD) Group Policy Objects (GPOs). I often reassociate .cs, .js, .jse, .sct, .vbe, .vbs, .ws, .wsc, and .wsf extensions so that they open in a harmless application (e.g., Notepad) rather than in Windows Script Host (WSH). If you rely on the use of scripting files with the specified extensions, you might not want to make such changes. To automate this process, you can use a .reg file containing statements such as the one that Listing 1 shows. I encourage network administrators to create administrative script files with a made-up extension (e.g., .jjs) that you then register with WSH. You can automatically apply such registry settings through logon scripts or Group Policy templates.
On machines with NTFS security, I manually restrict registry permissions or use security templates to prevent user access to the potentially dangerous file associations listed under the HKEY_CLASSES_ROOT registry key. To manually restrict permissions, open regedt32 (this method doesn't work with regedit), select the appropriate registry key, select Security from the menu bar, then set the appropriate NTFS permissions. For example, to prevent users from executing VBScript files, modify the permissions of the HKEY_CLASSES_ROOT\VBSFile\Shell\Open\Command registry subkey so that only Administrators, Power Users, and SYSTEM can read the subkey. (I give these accounts Full Control.) I explicitly deny access to all other user and group accounts. As a result, a nonauthorized user who tries to execute a VBScript file will get an error message. These techniques are safer than reassociating the .vbs extension with a harmless program because Microsoft service packs and version updates have an annoying habit of reassigning file associations without asking for permission. By denying access to a file type's subkey, you can maintain the integrity of your security setup.
Reveal Hidden File Extensions
Whatever precautions you take, the least you can do is give users a chance to see the true file type of the files they receive. Therefore, be sure to undo all Microsoft's "helpful" hidden-file-extension options. (Windows 98 and earlier include only one or two hidden-file or file-extension options, but later versions include several additional options.)
To begin revealing file extensions in Win2K, open Windows Explorer; select Tools, Options from the menu bar; and go to the View tab. Clear the Hide file extensions for known file types option in the Advanced settings window. Alternatively, you can use a .reg file such as the one that Listing 2 shows to modify the registry. (Not all the registry values in this listing work in every Windows version, but adding them does no harm.)
Even after you configure Windows to reveal file extensions, the OS doesn't automatically show certain extensions, such as .lnk, .pif, .scf, .sct, .shb, .shs, .url, and a handful of Microsoft Access extensions. Thus, a file named readme.txt.shs, which could point to a malicious executable, might appear as the harmless readme.txt file. (The Life_stages worm used this trick to infect millions of PCs.) Windows will always reveal or hide an extension depending on the existence of the AlwaysShowExt or NeverShowExt entry in the file type's registry subkey. (The value of the entry doesn't matter, as long as the entry exists and is spelled correctly.) When both values are present, the NeverShowExt value overrides the AlwaysShowExt value. Therefore, use regedit's Edit, Find menu option to look for and delete any NeverShowExt entries and to add the AlwaysShowExt entry to the registry subkey of potentially dangerous file types. Alternately, you can use security templates to accomplish this task. (Creating and implementing .inf security template files are beyond the scope of this article, however.) Although you can't use .reg files to delete values reliably, you can use .reg files, such as the one that Listing 3 shows, to add AlwaysShowExt to selected file types. (Note that adding AlwaysShowExt to the .lnk file type's registry subkey causes desktop shortcuts to show their hidden extensions—a habit that can be disconcerting to some users.)
Prevent and Protect
As network administrators, you need to prevent potentially dangerous file types from reaching users. At the very least, block files that have little legitimate value and a high risk, such as executable (.exe), screen saver (.scr), and scripting (.hta, .js, and .vbs) files, from getting past your email servers and client systems—then take additional steps to prevent execution if such files make it past your defenses. No computer security plan is perfect (as the sidebar "No Plan Is Perfect" explains), but following this approach will give you significantly more protection than most networks enjoy—without compromising functionality.
