  |
|
||||
|
Don't Let Your Users Buy the PharmBy Lyne BourqueMay 17, 2005
Phishing has become one of my more recent beefs. Whoever thought that adding HTML and other scripting languages to email was a good idea was very wrong, in my not-so humble opinion. But, it is 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 continue. For example, one university's financial aid office website I visited recently asked users to supply name and SSN via email when students are requesting updates on their loans. A rather shocking practice if you ask me. Thanks to media exposure, many of us know of phishing. But what do we know of its ugly twin, pharming? Well, I decided I wanted to do some research into ways to deal with pharming. Phishing is somewhat easier 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:
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 bank is in the US, I had my doubts it had managed to get branches in Brazil 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 gone 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 is true: 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 hosts file. This particular activity will 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've haven't 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.enterpriseitplanet.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. Page 2: Hosts Files and An Administrators Guide to Blocking Pharming Schemes
|
|
|
|
|||||||
|
||||||||
|
||||||||||||||||||||||||||||||
Managing the Modern Network
Business Service Management: Generate Revenue Through IT 
Evaluating Software as a Service for Your Business
Storage Networking: Configuration and Planning
Is Your Disaster Recovery Plan Good Enough? 
Email
Print
Digg This
Add to del.icio.us
