Less dangerous forms of these attacks can automatically cause the recipient's computer to display some content the attacker wishes, such as automatically opening an advertising or pornography web page when the message is opened, or perform a Denial-of-Service attack on the recipient's computer through code that freezes or crashes the browser or the entire computer.
The simplest way to completely avoid such attacks is to not use a web browser or HTML-enabled email client to read your email. Since many of these attacks do not depend on bugs in the email client software, they cannot be prevented through patches to the email client. If you use a web browser or HTML-aware email client, you will be vulnerable to these kinds of attacks.
Also, as some of these attacks depend on the email client being able to execute scripted HTML rather than depending on the weaknesses of any particular operating system, these attacks can be cross-platform. An HTML-enabled email client on a Macintosh is just as vulnerable to active-HTML email attacks as an HTML-enabled email client on Windows or Unix. The vulnerabilty will vary from system to system based on the email client rather than the operating system.
Switching to a non-HTML-aware email client is not a realistic option for many people. An alternative is to filter out or alter the offending HTML or script code before the email client gets a chance to process it. It may also be possible to configure your email client to turn off the interpretation of script code. See your program documentation for details. Turning off scripting in your email client is strongly recommended - there is no good reason to support scripted email messages.
Microsoft Outlook users should visit this page that describes tightening down Outlook's security settings.
The recently-announced Outlook email worms are an example of this attack. See the Bugtraq Vulnerability database for more details.
Another way to defend against active-content attacks is to mangle the scripting before the mail program has a chance to see it. This is done on the mail server at the time the message is received and stored in the user's mailbox, and in its simplest form consists of merely changing all <SCRIPT> tags to (for example) <DEFANGED-SCRIPT> tags, which causes the mail program to ignore them. Since there are many places that scripting commands can be used within other tags, the defanging process is more complicated than this in practice.
A buffer overflow attack is an attempt to utilize this weakness by sending an unexpectedly long string of data for the program to process. For example, in the case of an email program, the attacker might send a forged Date: header that is several thousand characters long, in the assumption that the email program only expects a Date: header that's at most one hundred characters long and doesn't check the length of the data it is saving.
These attacks can be used as Denial-of-Service attacks, because when a program's memory gets randomly overwritten the program will generally crash. However, by carefully crafting the exact contents of what overflows the buffer, it is in some cases possible to supply program instructions for the victim's computer to execute without the victim's consent. The attacker is mailing a program to the victim, and it will be run by the victim's computer without asking the victim's permission.
Note that this is the result of a bug in the program under attack. A properly written email client will not allow random strangers to run programs on your computer without your consent. Programs subject to buffer overflows are incorrectly written and must be patched to permanently correct the problem.
Buffer overflows in mail programs occur in handling the message headers and attachment headers, which is information the email client needs to process in order to know details about the message and what to do with it. The text in the body of the message, which is simply displayed on the screen and which is expected to be a large amount of text, is not used as the vehicle for buffer overflow attacks.
The recently-announced overflow bugs in Outlook, Outlook Express and Netscape Mail are examples of this. Patches for Outlook are available via the Microsoft security site.
The message headers and attachment headers can be preprocessed by the mail server to limit their lengths to safe values. Doing this will prevent them being used to attack the email client.
A variation on the buffer overflow attack is to omit information where the program is expecting to find some. For example, Microsoft Exchange reacts badly when it is asked to process MIME attachment headers that are explicitly empty - for example, filename="". This attack can only be used to deny service.
A Trojan Horse is a malicious program that masquerades as something benign in an attempt to get an unwary user to run it.
These attacks are usually used to breach security by getting a trusted user to run a program that grants access to an untrusted user (for example, by installing remote-access back door software), or to cause damage such as attempting to erase all of the files on the victim's hard disk. Trojan Horses can act to steal information or resources or implement a distributed attack, such as by distributing a program that attempts to steal passwords or other security information, or may be a "self-propagating" program that mails itself around (a "worm") and also mailbombs a target or deletes files (a worm with an attitude :).
The "I Love You" worm is an excellent example of a Trojan Horse attack: a seemingly-innocuous love letter was actually a self-propagating program.
For this attack to succeed the victim must take action to run the program that they've received. The attacker can use various "social engineering" methods to convince the victim to run the program; for example, the program may be disguised as a love letter or joke list, with the filename specially constructed to take advantage of Windows' propensity for hiding important information from the user.
Most people know that the .txt extension is used to indicate that the file's contents are just plain text, as opposed to a program, but Windows' default configuration is to hide filename extensions from the user, so in a directory listing a file named textfile.txt will appear as just "textfile" (to avoid confusing the user?).
An attacker can take advantage of this combination of things by sending an attachment named "attack.txt.exe" - Windows will helpfully hide the .exe extension, making the attachment appear to be a benign text file named "attack.txt" instead of a program. However, if the user forgets that Windows is hiding the actual filename extension and double-clicks on the attachment, Windows will use the full filename to decide what to do, and since .exe indicates an executable program, Windows runs the attachment. Blam! You're owned.
Typical combinations of apparently-benign and dangerously-executable extensions are:
- xxx.TXT.VBS - an executable script (Visual Basic script) masquerading as a text file
- xxx.JPG.SCR - an executable program (screen saver) masquerading as an image file
- xxx.MPG.DLL - an executable program (dynamic link library) masquerading as a movie
This attack can be avoided simply by not running programs that have been received in email until they have been checked over, even if the program seems to be harmless and especially if it comes from someone you don't know well and trust.
Double-clicking on email attachments is a dangerous habit.
Up until recently, simply saying "don't double-click on attachments" was enough to be safe. Unfortunately this is no longer the case.
Bugs in the email client or poor program design may allow the attack message to automatically execute the Trojan Horse attachment without any user intervention, through either the use of active HTML, scripting or buffer overflow exploits included in the same message as the Trojan Horse attachment or a combination of these. This is an extremely dangerous scenario and is currently "in the wild" as a self-propagating email worm that requires no user intervention for infection to occur. You can be sure that this won't be the only one.
In an attempt to prevent this, the names of executable file attachments can be changed in such a way that the operating system no longer thinks they are executable (for example, by changing "EXPLOIT.EXE" to "EXPLOIT.DEFANGED-EXE"). This will force the user to save and rename the file before it can be executed (giving them a chance to think about whether it should be executed, and giving their antivirus software a chance to examine the attachment before it starts running), and it reduces the possibility that other exploits in the same message will be able to find and execute the Trojan Horse program automatically (since the name has been changed).
In addition, for known Trojan Horse programs the attachment format itself can be mangled in such a way that the email client no longer sees the attachment as an attachment. This will force the user to contact technical support to retrieve the attachment, and gives the system administrator a chance to examine it.
Unmangling a mangled attachment is fairly straightforward for the administrator. In mangling the attachment the original MIME attachment header is shifted down and an attack warning attachment header is inserted. No information is deleted.
Here is a list of recent Trojan Horse executables and documents, gleaned from bugtraq and Usenet newsgroup warnings and antivirus vendor advisories:
Of course, worm authors are now wising up and naming the attachments randomly, which leads to the conclusion that all .EXE files should be blocked.
Another channel for Trojan Horse attacks is via a data file for a program that provides a macro (programming) language, for example, modern high-powered word processors, spreadsheets, and user database tools.
If you cannot simply discard attachments that may put you at risk, it is recommended that you install anti-virus software (which detects and disables macro-language Trojan Horses) and that you always open data file attachments in the program's "do not automatically execute macros" mode (for example, by holding down the [SHIFT] key when double-clicking the attachment).
Also: if your system administrator (or someone claiming to be your system administrator) emails you a program and asks you to run it, immediately become very suspicious and verify the origin of the email by contacting your administrator directly by some means other than email. If you receive an attachment claiming to be an operating system update or antivirus tool, do not run it. Operating system vendors never deliver updates via email, and antivirus tools are readily available at the antivirus vendor websites.
Many programs running under Unix and similar operating systems support the ability to embed short shell scripts (sequences of commands similar to batch files under DOS) in their configuration files. This is a common way to allow the flexible extension of their capabilities.
Some mail-processing programs improperly extend this support for embedded shell commands to the messages they are processing. Generally this capability is included by mistake, by calling a shell script taken from the configuration file to process the text of some headers. If the header is specially-formatted and contains shell commands, it is possible that those shell commands will get executed as well. This can be prevented by the program scanning the header text for the special formatting and changing that formatting before it gets passed to the shell for further processing.
Since the formatting needed to embed a shell script in an email header is fairly special, it's fairly easy to detect and alter.
Applying this to HTML email involves putting an image reference in the body of the email message. When the mail program retrieves the image file as part of displaying the mail message to the user, the web server logs the time and the network address of the request. If the image has a unique filename, it is possible to determine precisely which email message generated the request. Typically the image is something that won't be visible to the message recipient, for example an image that consists of only one transparent pixel, hence the term Web Bug - it is, after all, intended to be "covert surveillance."
It is also possible to use a background sound tag to achieve the same result.
Most mail clients cannot be configured to ignore these tags, so the only way to prevent this snooping is to mangle the image and sound reference tags at the mail server.
I can be contacted at <firstname.lastname@example.org> - you could also visit my home page.
I'd be very interested in hearing from people who'd be willing to translate this page.