Phishing Solutions

Chris Brenton

The Gartner Group has reported that from May 2004 through May 2005 1.2 million people have lost an estimated one billion dollars due to phishing attacks, which are attempts to fraudulently acquire sensitive information, such as passwords or credit card details. These estimates are just for the U.S. market, so you can imagine how big this problem has become at the global level. Also, note that we are just starting to see phishing that targets organizations rather than individuals. With this in mind, the problem will only get worse.

In this article, I'm going to focus on what can be done to protect your users from phishing attacks. There are several possible solutions depending on your requirements.

Web Servers

Banks and popular Internet sites are prime targets for phishing attacks. We are just starting to see solutions being developed for the targeted Web servers, with varying degrees of success. For example, eBay has been promoting their "inbox" solution for quite some time. The concept is that any administrative email that is sent to you from eBay will also be copied to the inbox maintained with your eBay account. If you don't see the message in your inbox, it is not a legitimate message. Of course, the problem is that this approach does not keep the phishing message out of the user's regular mail account and does not prevent the end user from following a phishing link.

Bank of America has implemented an interesting concept that they call "SiteKey". With SiteKey, users are allowed to customize their logon page with graphical images. Whenever you return to the site, you should see your customized logon page. If you do not, you have been redirected to a fraudulent site.

Green Armor Solutions has begun marketing a commercial product, called Identity Cues, which can bring similar functionality to any commercial Web site. The difference is that Identity Cues changes the logon screen every time the user types a password character. This pattern of screen changes now becomes a unique identifier for the site.

End Users

The Mozilla crew has developed a simple but elegant task bar plug-in to help keep end users from falling prey to phishing attacks. It is called "petname", and an example is shown in Figure 1. The first block in the figure shows what the users will see when they visit a site that does not use SSL encryption. Note that the site is identified as "untrusted", and the box is grayed out so the end user cannot change it.

The second box shows what users will see when they visit a site that does use SSL encryption. Note that the site is still identified as "untrusted", but the box is no longer grayed out. After installing petname, the user should manually type in the URLs of all the sites they wish to protect and verify the server's digital certificate. When the box turns yellow, simply delete the word "untrusted" and type in some form of short description of the site (such as "small payments"). Then, whenever the user returns to the site, that box should appear in green displaying the entered description. If the green box does not appear, the user has reached a different site regardless of how the URL may appear.

If you prefer a commercial offering, FraudEliminator also has an interesting package. The product adds an additional toolbar to your Firefox or Internet Explorer task bar. The software is frequently updated with known phishing sites, and end users are blocked from accessing these sites through their Web browsers. The tool also has the ability to perform some rule-based filtering to help prevent access to unregistered phishing sites.

Mail System

For the majority of this article, I will focus on solving this problem at the mail server. This makes the most sense because it permits an organization to have a single point of management for resolving the problem. Although all of the solutions discussed so far do provide end users with better tools to avoid phishing attacks, it can be argued that users who frequently fall prey to such schemes could still be vulnerable. By targeting the problem before the phishing email is forwarded to the end user, we have far more flexibility in dealing with it.

Of course, the concern with addressing phishing on the mail server is that we will only be protecting this one potential conduit. The Achilles heel of this solution is that it only protects against email-based phishing. If phishing is received via Internet messaging, it may sneak right through. With this in mind, defense in depth is the preferred posture.

Anti-Virus Software

It may sound odd at first to try to address phishing through an anti-virus solution, but consider how the software functions. Your anti-virus software scans all inbound email for known malicious signatures. Phishing emails are certainly "malicious" and contain known pattern on which we can filter. Thus, checking for phishing can (and arguably should be) a natural extension of anti-virus functionality.

Companies such as Trend Micro, Panda Software, and fire|trust have begun adding phishing detection to their anti-virus solutions. Some of the best work, however, has been done with the GPL project ClamAV. At the time of this writing, approximately 450 of ClamAV's 39,000+ signatures are specifically designed to detect phishing-based attacks, with more being added every day.

Anti-Spam Software

Like anti-virus software, anti-spam software is designed to analyze inbound email messages. Instead of looking for malicious patterns, however, anti-spam software looks for abnormalities within the message to identify the probability that message is spam. These abnormalities could be keywords within the message body or problems within the message header.

Consider the output shown in Figure 2. This is a report from Spamassassin on a phishing message that claims to have originated from LaSalle Bank. Spamassassin has identified a number of problems with this message, including forged headers and improper use of HTML. The source IP also appears to be a known spamming host within the Razor database.

This sample phishing message shares enough in common with a spam message to generate a spam score of nine. Because most environments consider a score of five or higher to be spam, this score is high enough for us to take some form of action, such as quarantining or deleting the message.

One of the nice things about Spamassassin is the ease with which it can be customized. This means that you can create a set of customized rules specifically designed to detect phishing attempts. For example, Murty Rompalli has created a cool set of Spamassassin rules designed to identify phishing-based attacks. The rules first check to see whether the message claims to be associated with a bank or known popular Internet site. The rules then check whether the user is being redirected to a site using SSL. If not, the Spamassassin score is increased. Although it is certainly possible for a phishing site to use SSL, the phishing site's digital certificate would not match that of the legitimate site.

Murty has posted a copy of his rules here:

http://solar.murty.net/~murty/sa.php

One of my favorite solutions for dealing with phishing is MailScanner. This is an open source tool (although commercial support and solutions are available) that is designed to be a wrapper that combines and manages your mail transfer agent, anti-virus solution, and Spamassassin all through a single interface. MailScanner also adds quite a bit of functionality on its own, including the capability to detect phishing-based attacks.

For mail transfer agents, MailScanner supports Sendmail, Qmail, and Postfix. Approximately 25 different anti-virus scanners are supported, including ClamAV. Installation instructions can be found through the "Documentation" link on the main Web page. So, I refer you to that link for help with installation, and I'll jump right into configuration. The default location for all the configuration files is /etc/MailScanner/.

Configuration

Let's start with the easy files. The file "filename.rules.conf" is where you define all the file types that are deemed unacceptable to pass through your mail system, regardless of whether they pass virus checking. For example, a file with a .reg extension would be processed as registry key changes on a local Windows system. Because this can be extremely dangerous, you can choose to block all files that contain this extension.

The file "filetype.rules.conf" is where you can define permit and deny rules based on the type of file attached to the email. For example, Elf binaries can contain any file extension. The only way to properly identify them is through their headers. With this in mind, a rule in this file stating that Elf binaries should be filtered would check the contents of the binary rather than the file extension.

The file "spam.lists.conf" is used to define which DNS black lists you want to use (e.g., Spamhaus, ORDB, or Spamcop). I'll discuss the use of these lists later in this article.

The file "phishing.safe.sites.conf" is used by MailScanner to whitelist certain sites during its phishing check. I will also discuss this feature later in this article.

The main configuration file you will be working with is "MailScanner.conf". This is where you will define the mail transfer agent you want to use, the anti-virus software package, and a host of other options. It's beyond the scope of this article to discuss every possible configuration option in depth. With this in mind, I'll hit on some of the more important highlights. The configuration file is heavily commented so, if you are familiar with mail system functionality, you can probably create a stable setup without ever referring to the documentation.

Most of the settings within MailScanner are defined as either "yes" or "no". For example, if you wanted to block all attachments containing an archive that requires a password to open them, you would set the "Allow Password-Protected Archives" parameter to "no" as follows:

Allow Password-Protected Archives = no

Allow WebBugs = disarm

Another nice feature of MailScanner is the ability to handle potential spam differently based on different scoring ranges. For example, you could define a spam score of less than three to be "not spam", three to ten to be "spam low" and above ten to be "spam high". We can then handle each of these ranges in a different fashion. For example, for anything thought not to be spam, we could simply deliver it to the end user. For "spam low", we could still choose to deliver it, but to first change the subject line identifying it as potential spam, strip out all HTML tags, and replace the message body with a corporate spam warning while turning the original message body into an attachment. If the message is ranked as "spam high", we could instead quarantine the message, forward it to an email administrator, or just delete it. Obviously, any combination of these options can be used.

If you've done time as a mail server administrator, you probably have experience with DNS black lists. These are lists of "known spammers" or open mail relays that you can use to tell your mail system to reject all mail messages received from that IP address. The problem is none of these lists are perfect. I've personally seen everything from AT&T to SANS to Security Focus end up on these lists. Relying on any single list can lead to legitimate email being turned away. Luckily, MailScanner has a setting to help solve this problem:

Spam Lists To Reach High Score = 2

There are three phishing-related settings within MailScanner. These are:

Find Phishing Fraud = yes/no
Also Find Numeric Phishing = yes/no
Phishing Safe Sites File = %etc-dir%/phishing.safe.sites.conf

The second option works in the much the same way, only it looks for numeric IP addresses within the URL. Figure 3 shows an example. Note the text in red. MailScanner has changed the body of the message to identify that a potential phishing attempt has been discovered. The end user receives a clear indication that there is something phishy about this email.

The third option simply specifies where the phishing white list can be found. This file contains a list of legitimate sites that typically fail the phishing test. For example, American Express will typically send out mailings to its customers where the displayed text reads "www.americanexpress.com", but the URL actually points to some other host within the americanexpress.com domain. You can add sites to this white list as needed.

So, with the above configuration, potential phishing attempts end up going through three levels of verification:

1. Anti-virus software (if phishing emails are detected)

2. Spamassassin

3. MailScanner checks

At each verification point, we have the option of deleting or quarantining the email message so the end user does not even see it. This gives us a very strong posture in protecting against phishing attacks. Over the past 6 months, I've deployed this setup for a number of my clients. All of them feel this solution has practically eliminated their phishing problems. There have been a couple of users that have copy/pasted the red phishing URL into their browser and fallen prey to the attack, but future problems were mitigated by simply deleting the email rather than forwarding it to the end user.

Logging and Reporting

No solution would be complete without some way of monitoring how it is performing. Although MailScanner records everything to the "/var/log/maillog" file, it's nice to have a way to summarize the results. I like to use Logwatch for this function. Logwatch set to a medium level of detail generates a summary of results over the specified time period (usually 24 hours).

For example, you get a nice summary of overall stats similar to the following:

MailScanner Status:

    431 messages Scanned by MailScanner
    5338058 Total Bytes
    48 Spam messages detected by MailScanner
    37 Spam messages deleted by Mailscanner
    6 Viruses found by MailScanner
    1 Banned attachments found by MailScanner
    394 Messages delivered by MailScanner

Virus Report: (Total Seen = 6)
    Exploit.HTML.IFrameBOF-4: 194.38.138.83 : 1 Times(s)
    HTML.Phishing.Auction-42: 205.206.231.27 : 1 Times(s)
    HTML.Phishing.Auction.39: 213.171.218.201 : 1 Times(s)
    HTML.Phishing.Pay-16: 216.127.82.8 : 1 Times(s)
    Trojan.LdPinch.JM1-3: 66.193.188.58 : 2 Times(s)

Found ip-based phishing fraud from 219.235.0.9 in \
  j66DAHC6007906 : 2 Time(s)

Summary

Phishing is a major problem, and it is going to get much worse before it gets better. With the right tools however, you can take preventive measures to help keep your users from falling prey to these attacks. As with most network security solutions, the best defense is a layered one.

Resources

SiteKey by Bank of America -- http://www.bankofamerica.com/privacy/passmark/

Identity Cues by Green Armor Solutions -- http://www.greenarmor.com

FraudEliminator -- http://www.fraudeliminator.com

Clam AntiVirus -- http://www.clamav.net

Spamassassin -- http://spamassassin.apache.org

MailScanner -- http://www.mailscanner.info

Logwatch -- http://www2.logwatch.org:81

Chris Brenton is a private security consultant and a frequent instructor for SANS.