Don't Let Your Users Buy the 'Pharm' Learn How to Spot Phishing and Pharming Schemes Lyne Bourque
"The best defense against phishing is to distrust email messages, especially ones that ask you to enter sensitive information into a website, and to distrust hyperlinks in email messages" - Edward W. Felten, March 14, 2005 (Freedom to Tinker)
Phishing has become one of our more recent beefs. Whoever thought that adding HTML and other scripting languages to email was a good idea was very wrong, in our not-so-humble opinion. But they're here and here to stay.
As administrators, we have to deal with the fallout that results from users wanting to click on that next deal or to visit the banking site that has just informed them of an account violation. You may wonder what compels people to do this? How clueless can they be?
Well, apparently we are encouraging them to respond by employing practices that allow this to continue. For example, one university's financial aid office Web site I visited recently asked users to supply their name and SSN via email when students would request updates on their loans. A rather shocking practice if you ask me.
Thanks to media exposure, many of us know about phishing. But what do we know of its ugly twin, pharming? Well, I decided to do some research into ways to deal with pharming. Phishing is somewhat easier than pharming to deal with: just look at the full email headers and determine if the source is legitimate. That is, is it coming from where it claims to come from?
Generally, you want to find this kind of line:
Received: from 201.1.131.49 (HELO 201-1-131-49.dsl.telesp.net.br) (201.1.131.49)
I received an email today from Charter One Bank claiming that my account needed to be updated since due to security updates. Now, excluding the fact that I'm in Toronto, don't have an account with Charter One, and that the REAL Charter One Bank is in the U.S., I had my doubts it had managed to get branches in Brazil (see the .br domain in the header above) to handle my account. This kind of inconsistency should trigger warning bells.
Furthermore, the "link" to perform the account update resolves to an address in China. Charter One, I'm sure, is growing. But I doubt it's grown that fast or far. The point is that phishing can be relatively easy to detect these days. Many of our first line defenses deal with this. Email administrators can also use filters to block those questionable accounts. Many corporate spamming appliances and/or applications are now integrating phishing filters.
One thing about phishing remains true: it has been somewhat effective at causing distrust in email. The quote I used above certainly highlights this. But with new defenses, that trust can be earned once again. Or so we thought...
Enter Pharming
Now, pharming comes in many forms, but basically, as a broad definition, pharming is when the Full Qualified Domain Name (FQDN) is referenced to a fraudulent or spoofed location via DNS or a hosts file. This particular activity could well erode whatever remaining trust a user may have in the internet and the many services it makes possible. There are three common ways to go about "pharming."
The first is a keystroke reader. This is actually used quite often by malware, such as spyware, to gather information. Attackers, wanting to get SSNs/SINs, PINs, etc., use email to transport the keylogger, install it as a tool required by the "bank" and then patiently sit and wait. I haven't seen widespread use of this method largely because many anti-virus utilities pick up these kinds of tools. Additionally, people have become somewhat email savvy and many won't just install everything that comes into their inboxes. There are still those, however, that seem to live up to the adage by David Hannum (not P.T. Barnum), "There's a sucker born every minute."
The more common form of pharming has been, historically, referred to as DNS (Domain Name Service) cache poisoning. DNS servers provide the resolution of FQDNs (e.g., http://www.enterpriseitplanet.com) to the IP address (63.236.73.136).
A lot of this information is provided to the DNS server from other DNS servers. And, it is, for all intents and purposes, built on a system of trust. Meanwhile, the internet is all about speed. Everything I request must be here now or I won't be happy (so it seems online).
So, DNS requests, which are rather voluminous these days, are often cached. Particularly the more commonly used FQDNs, such as www.google.com, www.antionline.com, www.winplanet.com, etc., would be found in the DNS cache. The DNS server will keep the cache for a set period of time and deletes those caches once the set time (TTL) expires. While this can speed up requests, it can cause slowdowns when FQDNs change their IP address. The update of the new IP isn't necessarily done to the cache server.
What this means for the attacker is that he can "poison" the DNS cache with false information. Certain products are open to DNS cache poisoning, including NT4, Windows 2000, and Symantec Gateway. All of these have known fixes.
By the way, this isn't a new attack. This has been around for a long while. Over eight years ago, many of the BIND servers were affected by this kind of attack and have since been rebuilt to withstand it.
