▶ 14.3 Email Security Problems
The ease of email forgery is not, by itself, a security problem. Remember that typewriters allow anyone to type another person’s name on a piece of paper. The problems arise when attackers exploit forgeries to defraud people or take advantage of open systems. In the world of email, there are four major security problems:
Connection-based attacks: Incidents in which someone sniffs or intercepts another’s email session. We can prevent this type of technical attack.
Spam: Unsolicited email, often—but not always—of a commercial nature. Spam often is used to distribute classic financial frauds.
Phishing: Email that tries to trick the reader into disclosing confidential identification data.
Email viruses: Email that contains malicious software that spreads via email.
An unfortunate side effect of easy email forgery is that attackers can distribute emails that claim anyone as the author. Thus, it isn’t unknown to receive spam or email viruses that claim to be from well-known and respected computer security experts.
Connection-Based Attacks
Because email protocols use TCP connections, they are vulnerable to attacks on those connections. Given a typical TCP connection, the attacker may sniff its contents, insert or modify data, or even hijack the connection completely.
Even if the account owner handles no sensitive data, the connection carries the login name and password. This gives the attacker the materials needed to hijack the account. No additional attack techniques are really necessary beyond that.
Some RFCs describe challenge-response authentication techniques to use with email. For example, RFC 2195 suggests a technique to use with IMAP or POP3. Although challenge-response authentication would prevent password sniffing, it does not prevent an attacker from hijacking a connection after it has been authenticated. This is a more challenging attack, because it waits for the moment when the user logs in.
We defend against connection-based attacks by using SSL encryption. SSL prevents sniffing and connection hijacking. It also may prevent attacks in which a site masquerades as the email service in an attempt to capture login credentials, because SSL can authenticate the server. However, masquerade risks may remain if the client does not authenticate the server certificate correctly.
14.3.1 Spam
Unsolicited email, usually called spam, relies heavily on the absence of email authentication. Although many jurisdictions have laws in place against distributing spam, a certain community of vendors still rely on spam to generate business. Organizations sell prescription drugs without prescriptions or drug alternatives of questionable value; others promote dubious investments that legitimate brokers won’t touch. These vendors operate on questionable legal ground already. They want to attract customers while drawing as little legal attention as possible.
Spam is perfect for advertising such things. The “From” address on the spam email can be completely fake. Contact information given to potential customers can change with every round of spam sent, making it hard for police or fraud investigators to follow.
Classic Financial Fraud
Spam has also become a popular medium for distributing classic financial frauds. Spam often carries investment offers that border on fraudulent; the technique is as old as investing, only the delivery medium makes it seem new.
The same is true for the advance-fee fraud, typified today by the so-called “Nigerian scam.” This scam begins with an email from a wealthy individual in a third-world country who supposedly needs to transfer tens of millions of dollars to another country. The person who is willing to transfer the money into their personal bank account is promised a “service fee” of 10 percent or even 15 percent of the money. Unfortunately, the funds transfer process requires the payment of various fees and bribes, which must be paid up front.
These payments represent the “advance fee.” The scam is to collect a lot of fees allegedly needed to complete the transaction. The actual windfall—10 to 15 percent of the money— doesn’t really exist. The fraudster demands more and more up-front fee payments until the victim is wiped out or otherwise gives up on the transaction.
Another variant is an email announcing that someone has won an overseas lottery contest. Again, the scammer requires an advance fee to release the lottery funds. In 1997, the U.S. Secret Service reported that more than $100 million had been lost to advance-fee scams over the previous 15 months.
A similar fraud took place by mail in the early 1900s; people received letters from an alleged “Spanish prisoner,” a wealthy man unjustly imprisoned in Spain. If someone could forward the fees to support his release from prison, the alleged prisoner would pay that person a handsome reward. Again, the wealth never existed; the whole point was to collect fees as long as the victim was gullible enough to keep paying.
A clever version of the Spanish Prisoner has arisen recently; it exploits vulnerable email and social networking sites that keep a list of friends’ emails. Here is an example:
Bob received an email from his Uncle Joe. The email says that Joe is in London, and someone has stolen his wallet, luggage, and all of his money. He begs Bob to wire him some money in London so he can buy food and lodging while waiting for the embassy to sort things out.
In fact, Bob’s Uncle Joe is at home in Peoria. A fraudster managed to hack into Uncle Joe’s email account. The fraudster then sent the email to every address in Uncle Joe’s account, masquerading as Uncle Joe—and, unfortunately, Great Aunt Hilda wired money to London for him.
Just about every type of fraud appears in email. There are fraudulent investment offers, fraudulent vendors, fraudulent charities, and so on. No matter how well-written the email, keep in mind that there is no way to confirm the email’s authorship or accuracy by examining the email alone. A careful examination may detect a forgery, but the examination can’t prove the email’s authenticity.
Evolution of Spam Prevention
From a networking perspective, spam is a flood of email directed at unsuspecting recipients. Email administrators at large sites say that the majority of email they process is spam. The better a site is at filtering out spam before it hits their users’ mailboxes, the better its overall performance. Thus, network administrators often work diligently at eliminating spam.
In the early, precommercial days of the internet, MTAs accepted connections from anyone. People could easily construct and submit bogus email via such connections. However, the problem was more of a nuisance than a risk. The internet community valued openness over safety and assurance.
As the internet became commercial, MTA operators noticed that their servers were spending more and more time processing spam. Moreover, users complained that an increasing proportion of email was spam. Initially, sites tried to control spam through the following strategies:
■ Enforce MTA access restrictions—Distinguish between reputable hosts that don’t generate spam and hosts that do generate spam. Only allow access by reputable hosts or by those belonging to the ISP’s customers. If spam comes from one of the ISP’s customers, block access and consider canceling the customer’s service.
■ Identify consistent patterns in the spam email so it may be filtered out of legitimate email—Most filtering software marks every email matching a spam pattern, often with a special email header. Email client software uses the mark to sort spam into a separate “junk mail” folder or to delete it.
MTA Access Restriction
The original internet email design assumed that MTAs were public utility devices available to any internet user. Such an MTA was called an open relay, because it would relay any email it received. To send email, the user simply connected to a nearby open relay. Spam distributors took advantage of this.
As the spam problem grew, ISPs established acceptable-use policies that forbade spam delivery through their systems. Customers who violated the policy were denied email service. To enforce this, the ISPs eliminated open relays and modified their MTAs to accept email only from approved sources. Individual users had to log in to submit email. ISPs also blocked email connections from spam-friendly MTAs while accepting email from respectable MTAs.
In the mid-1990s, interested ISPs constructed lists of trustworthy and untrustworthy MTAs. These lists were stored in the domain name system. An MTA could retrieve a list by using DNS commands. Different teams managed different MTA lists. Each list reflected a different policy to identify either good (“white”) or bad (“black”) MTAs. This yielded two sets of lists:
Whitelists identify reputable MTAs or those deemed reputable by the list’s maintainer. MTAs would accept email only from hosts who were on the list.
Blacklists identified MTAs that carried spam. In some cases, the MTAs were actually part of an enterprise that generated or supported spam production. In other cases, the MTAs were unmanaged and easily exploited to transfer spam. Legitimate MTAs avoided accepting email from hosts who were on the list.
Today, spam delivery relies heavily on botnets. (See Section 3.2.4.) Instead of sending a flood of email through a single MTA, the botnet sends several spam emails from each of its bots. The trickle from individual bots doesn’t arouse suspicion, but the overall email flow from the botnet produces the desired quantity of email.
Filtering on Spam Patterns
This is another example of the pattern matching introduced in Section 2.4. When email spam volumes increased dramatically in the 1990s, the spam campaigns often sent the same email message repeatedly to people on a variety of lists. Clever administrators realized that they could eliminate such messages by looking for the repeated email subject lines or contents.
As spam became a more lucrative business, the spam authors adapted their campaigns to defeat simple filters. The email’s subject and body would incorporate random data so that messages were superficially different. Antispam software developers fought back by developing more sophisticated filtering and detection techniques. As with other pattern matching systems, the matching falls into two general categories:
Binary matches: The filter either returns “Match” if the email contains specific text in a particular arrangement and “No Match” otherwise. The matching may be very sophisticated and include “wild card” values or other context-sensitive tests. Ultimately, however, the filter returns either of the two answers.
Statistical matches: The filter calculates a likelihood that the email is spam. This often uses “Bayesian filtering,” based on Bayes’s theorem from the study of statistics. The filter examines individual words in the email and calculates the likelihood that the presence or absence of particular words indicates a spam email. Thus, the filter returns a numerical value.
Antispam developers soon learned that no single rule or technique worked in all cases. Recently, statistics suggest that four out of five emails are, in fact, spam. The problem is to identify spam emails, yet not mistake a legitimate email as spam. This problem of false positives makes the detection process especially challenging. There is an ongoing struggle between spam authors and spam filter designers: As the filters get more sophisticated, the spam authors find new ways to trick them.
Modern systems, notably the open-source package SpamAssassin, improve detection by applying numerous filters to each email message. The result yields a spam score for that email: A higher positive number indicates spam, while a lower or negative number indicates a legitimate email.
Spam often is handled both at MTAs and at the recipient’s email client. In some cases, MTAs have specific information about the format and contents of a particular spam campaign and may be able to identify and delete the spam emails safely. However, such specific information usually isn’t available until after the emails have been received and processed.
It is dangerous to have an MTA automatically delete emails suspected of being spam, because the filtering and scoring process isn’t 100 percent reliable. The filtering procedure occasionally produces a false positive in which it identifies a legitimate email as spam. Because of this, server-based spam detectors often limit themselves to marking likely spam. In some cases, the filter simply may insert the text “[SPAM]” at the beginning of the email’s subject line. In other cases, the filter may add a special spam detection header. For example, Figure 14.4 shows a spam calculation by the proprietary package IronPort.
Email clients may filter spam based on the user’s personal experiences; they may also take into account the results of MTA-based spam detection. In the first case, a user marks spam emails as spam, and the client software applies its own Bayesian filter or other detection technique. This “trains” the client’s filter to detect spam. In the second case, the client looks for indicators left by MTA-based spam filters. These may include “[SPAM]” markers or other headers provided by the filters. SpamAssassin, for example, inserts its own header that includes the spam score it calculated.
14.3.2 Phishing
For many people, warning messages from banks cause a lot of anxiety. A troubled bank account can start a cascade of financial troubles, touching many other business relationships. The natural reaction is to fix matters as quickly as possible.
Most people now know that an email warning from a bank may simply be a trick: a phishing attack. FIGURE 14.9 illustrates an example. The email link displayed this sign-on window atop a bank’s actual website.
FIGURE 14.9 A window from a 2003 phishing attack.
Courtesy of Dr. Richard Smith.
In fact, the sign-on window was hosted a half a world away from the bank’s New York headquarters. The account, PIN, and expiration date were collected for later use in ATM fraud.
Phishing relies to some extent on spam; thousands or even millions of people receive the email. If only a hundred respond, the attack may net thousands of dollars from their bank accounts. In 2009, researchers identified more than 150,000 separate phishing attacks. The majority that year were attributed to a single criminal group.
A variant of the phishing attack is the drive-by download. (See Section 3.2.4.) In this case, the victim clicks on a link that visits a website and the web page itself tries to attack the victim’s computer. Such attacks succeed if the victim’s computer contains a vulnerability that the web page can exploit. Web-based attacks often rely on scripts embedded in web pages. We discuss scripts in Section 15.3.1.
Tracking a Phishing Attack
Although attacks directly affect internet users and their financial institutions, internet vendors are closely involved in efforts to prevent phishing attacks. To understand these efforts, let us look at the resources used in phishing:
■ Spam email—This is the medium for distributing the phishing attacks.
■ Website—This is where the phisher hosts the web page that masquerades as the bank or other institution.
■ Domain name—The email refers to the site through a domain name.
One way of tracking down those responsible for phishing attacks is to track the resources they use. Although it’s rarely worthwhile to trace spam that involves low-valued crimes, phishing can involve serious money. If the spammer leaves a trail when sending a phish, that trail may be worth following. To counter this risk, phishers must rely on spammers that are exceptionally hard to trace, like those that rely on botnets or other illegal techniques to transmit their spam.
Clearly, a phishing website must be under the control of some ISP somewhere in the world. If we track down the ISP, we should be able to track down the site’s owner. In practice, however, many ISPs handle site rental purely online and will rent to anyone whose credit card transaction clears the bank. If the transaction uses a credit card that is stolen but unreported, the trail leads nowhere.
Like the website, the domain name must lead back to a domain registrar and a genuine individual or organization who registered the domain. Although this ought to provide a link to the phishers, it hasn’t always worked that way in practice. There are gaps in the domain registration process, and phishers have found ways to deploy domain names while the actual registration process is incomplete. Thus, attempts to retrieve domain registration information for the phishing site doesn’t yield usable WHOIS (pronounced as “who is”) information.
A typical phishing attack takes place over a matter of hours. The emails are sent, the victims fall for the ruse, account data is collected, and then everything is shut down. The websites disappear. The domains disappear. The data has been collected and moved for safekeeping. This leaves few clues for investigators to follow.
14.3.3 Email Viruses and Hoaxes
An email virus is a virus that spreads by email, usually through an attachment. The simplest approach was to attach an executable and to somehow trick the recipient into running it. Another approach was to embed the virus in a document; the virus would be activated when the document was opened. Many email viruses are implemented as macro viruses. (See Section 3.2.3.)
Several early email viruses took advantage of the extensive capabilities of Microsoft’s MAPI. Any program or Visual Basic macro could use the API to examine the user’s email address book and send email. A virus could create a copy of the virus email and send it to recipients in the user’s address book. The first significant virus of this type was named “Melissa” and appeared in early 1999.
In 2000, Bob’s Aunt Carol was managing the IT department of a medium-sized company. She had heard about email viruses making the rounds. She was very careful not to click on anything suspicious. The Melissa and ILOVEYOU viruses were obvious and silly. She felt confident that she’d dodged that bullet.
In the cubicle next to her, the mail administrator was monitoring email traffic flow. The mail system was very busy and just keeping up with traffic. A hard drive failure left the server short on storage. If anything happened to slow down the system, mail might back up, fill the disks, and grind the server completely to a halt.
Carol turned to her email. She needed to hire another administrator, and an email popped up with the subject “résumé.” She opened the message and clicked on the attached Microsoft Word file without another thought.
She waited. Nothing was happening. Microsoft Word was running, but no résumé appeared.
Then she heard a cry of anguish from the next cubicle as the email server crashed.
As email viruses evolved, they became more sophisticated on how they appealed to recipients. The “ILOVEYOU” virus masqueraded as a love letter. Many opened it out of curiosity, assuming it was sent to them by mistake. The “Résumé” virus appealed to understaffed IT managers, like Aunt Carol. When opened, the virus sent emails to everyone in her lengthy contact list. Although email viruses did not always crash mail systems, they often put them under a great deal of strain.
Virus Execution
When the virus resides inside an email attachment, we infect ourselves if we double-click on the attachment and open it. Some email viruses are just executable files with misleading names. For example, “Invoice.txt.exe” will appear on some systems simply as “Invoice.txt” if the system is configured to hide file suffixes. It’s almost impossible to infect ourselves by opening a text file. If the system hides the real suffix, we might be tricked into running the virus code.
It’s possible to infect our computer just by reading an email. For example, early versions of Microsoft’s MAPI allowed email messages to embed scripts that could perform virus infections. Emails using html format could include executable scripts. Many email clients block this risk by not implementing script languages or by implementing weakened versions of them.
Email Chain Letters
A chain letter is a message whose sender asks each recipient to forward it to others. Classic chain letters were scams that tried to collect money through a pyramid scheme. Chain emails often seek publicity or produce trouble for a selected victim by producing excessive email traffic.
A common type of chain email claims to promote some charitable activity by generating lots of email traffic. These are almost always bogus; no well-known charity has ever intentionally promoted such an activity. In particular, numerous chain emails have claimed that each email sent will yield a donation for cancer research, or specifically, to the American Cancer Society. Here is a 1997 chain email that illustrates the hoax:
LITTLE JESSICA MYDEK IS SEVEN YEARS OLD AND IS SUFFERING FROM AN ACUTE AND VERY RARE CASE OF CEREBRAL CARCINOMA. THIS CONDITION CAUSES SEVERE MALIGNANT BRAIN TUMORS AND IS A TERMINAL ILLNESS. THE DOCTORS HAVE GIVEN HER SIX MONTHS TO LIVE.
AS PART OF HER DYING WISH, SHE WANTED TO START A CHAIN LETTER TO INFORM PEOPLE OF THIS CONDITION AND TO SEND PEOPLE THE MESSAGE TO LIVE LIFE TO THE FULLEST AND ENJOY EVERY MOMENT, A CHANCE THAT SHE WILL NEVER HAVE. FURTHERMORE, THE AMERICAN CANCER SOCIETY AND SEVERAL CORPORATE SPONSORS HAVE AGREED TO DONATE THREE CENTS TOWARD CONTINUING CANCER RESEARCH FOR EVERY NEW PERSON THAT GETS FORWARDED THIS MESSAGE. PLEASE GIVE JESSICA AND ALL CANCER VICTIMS A CHANCE.
IF THERE ARE ANY QUESTIONS, SEND THEM TO THE AMERICAN CANCER SOCIETY AT [email protected]
The alleged fund-raising effort never existed. The American Cancer Society received so many inquiries about this that they posted a web page disavowing it and similar hoaxes that followed. These hoaxes can generate incredible amounts of email traffic and yield no charitable results. Fortunately, the listed email address does not actually reach the American Cancer Society.
Virus Hoax Chain Letters
A peculiar combination of chain letters and email viruses are the virus hoaxes. These are chain letters that encourage recipients to forward a “virus warning” or other security-related warning to everyone they know. An early form was called “Good Times,” and contained a message like this:
Happy Chanukah everyone, and be careful out there. There is a virus on America Online being sent by E-Mail. If you get anything called “Good Times”, DON’T read it or download it. It is a virus that will erase your hard drive. Forward this to all your friends. It may help them a lot.
The earliest reported outbreak of “Good Times” was in late 1994, but variants crop up quite regularly, including one called “Olympic Torch” in 2006 and another called “Free Money” in 2007. In 2010, a similar virus hoax involving a nonexistent “Christmas tree app” was distributed through social networking sites, notably Facebook.
If an email security warning recommends that it be forwarded to “everyone you know,” then it is a hoax. Legitimate warnings are never distributed through email acquaintances. They arrive through news announcements or through direct emails from legitimate system administrators. To forward such an email does no good and often causes harm, if only by wasting time and resources. If everyone forwards the email, then everyone receives numerous duplicates in their inbox. Meanwhile, the email service is kept busy carrying unnecessary messages.