Thursday, March 24, 2005

Pharming Attacks - Just for your Information!

Alarm over pharming attacks: identity theft made even easier

By Robert Vamosi
Senior editor, CNET Reviews
February 18, 2005

Hopefully, we've all become wise to phishing attacks, so named because they cast the bait (via e-mail) and if you bite, they can lure your personal information out of you. These scams are now fairly recognizable and usually arrive as a note from a bank asking you to go to its site (link provided, of course) to reenter your most personal information. The fact that a bank wouldn't really need your mother's maiden name might tip you off. Most likely, though, you spot the misspellings in this bogus e-mail, or you're otherwise savvy to the identity theft scam and immediately trash these messages unread.

So what if I told you phishing is just kid stuff compared to what's coming next?

The danger here is that you no longer have to click an e-mail link to hand over your personal information to identity thieves.

In January, I started hearing about these new "pharming" attacks, a supposed successor to the now familiar e-mail phishing attacks. Gerhard Eschelbeck, CTO of Qualys, a vulnerability management company, told me recently that pharming is simply a new name for a relatively old concept: domain spoofing. Rather than spamming you with e-mail requests, pharmers work quietly in the background, "poisoning" your local DNS server by redirecting your Web request somewhere else. As far as your browser's concerned, you're connected to the right site. The danger here is that you no longer have to click an e-mail link to hand over your personal information to identity thieves.

The DNS system
To understand pharming, you need a little background on DNS. Throughout the Internet, a series of domain name servers (DNS) quietly resolve the familiar addresses you type into specific Internet addresses. These servers are basically large directories of common names such as Amazon, Google, and Microsoft, and IP-specific addresses that you never see. For example, if you type www.cnet.com, this request goes to your nearest DNS server, which then locates the registered Internet address for the Web server at CNET Networks. It's much more convenient than always remembering 222.123.0.0 or something similar.

However, this translation is also a weak link in the Internet's infrastructure. With every Internet request first bouncing off a DNS server somewhere on the planet, criminal hackers realized (some time ago) that rather than flooding a specific domain and effectively hiding it from the rest of the world (in what's known as a denial-of-service attack), they can either change the DNS record or take down the DNS system all together.

DNS poisoning
In October of 2002, criminal hackers (crackers) attempted just that: they directed a denial-of-service attack at the 13 high-level, or root, DNS servers located throughout the world
. Although 10 of the 13 failed and went offline, the Internet itself didn't fail. Why? Because the subservers that most people actually access when they type in a URL all have 24-hour cache backups of popular addresses. In other words, there are enough redundancies to keep everything running.

Just watching the address bar on your Internet browser won't inform you of any hijacks; to you, the URL and possibly even the spoofed financial site will look just fine.

But DNS poisoning is a whole different kettle of fish (so to speak), and much more subtle than what I just described. When a cracker poisons a DNS server, he or she changes the specific record for a domain, sending you to a Web site very different from the one you intended to access--without your knowledge. Usually, the cracker does this by posing as an official who has the authority to change the destination of a domain name. DNS poisoning is also possible via software vulnerability, however. A white paper by Joe Stewart from the security company Lurhq and published on SecurityFocus offers more about DNS poisoning, including its history.

Consider Panix, Amazon, and Google
In January of 2005, someone fraudulently changed the DNS address for the domain panix.com
, a New York State Internet service provider. Ownership of the company was changed from New York to Australia. Requests to reach the panix.com server were redirected to the United Kingdom, and e-mail was redirected to Canada. State and federal authorities are currently investing this case.

Prior to that, in September 2004, a teenager in Germany
managed to hijack the domain for eBay.de. I could go on. Other attacks have targeted Amazon.com and Google.com. There were no immediate reports of identity theft resulting from these specific events.

Solutions
Unfortunately, just watching the address bar on your Internet browser won't inform you of any hijacks; to you, the URL and possibly even the spoofed financial site will look just fine. In order to remove pharming as a threat, servers would have to add another layer of authentication: they would need to prove to you that they are who they say they are and establish a trusted link between you and them. That would require the site to obtain a certificate from a certificate authority, such as VeriSign
. According to Eschelbeck, most Internet browsers already have the ability to check for the presence of server certificates right now: the problem is on the server side.

A few sites already offer certificates. When you visit these sites, you see a dialog box asking you if you want to trust the certificate; if the name on the certificate doesn't match the site you're attempting to reach, you know that something is amiss, and hopefully you leave. Perhaps your target site (your bank's URL) has been hijacked. If the certificate is OK, you then save the certificate so that when you next return, your browser will know it's reached the right address. You would then log in to the site. There's a slight trade-off in convenience, but the security's worth the added steps.

CNET TalkBack

Pharming Attacks

March 15, 2005

Dear CNET members,

By now, hopefully everyone is aware of phishing scams--cleverly designed e-mail and Web sites used to gain access to your financial logins and passwords. We've pretty much reached the level of sniffing those out from a mile away. But this fairly new heinous tactic, called pharming, is absolutely frightening. For example, you type in citibank.com in to your Internet browser. The address bar displays as you would expect--citibank.com and you proceed to log on to access your bank account information. No sweat, eh? Well, little did you know that behind the scenes, citibank.com's DNS (domain name servers) just got hijacked--displaying the completely legitimate URL address that you are accustomed to, but directing you to a spoofed site that looks and feels just like your financial institution, so you have absolutely no idea you willingly gave up your personal account info to the hijackers. Is this scary or what? Are you concerned? Are there any preventative measures out there that we can take, or are we just out of luck on this one? Find out more about this all-too-important topic in senior editor Robert Vamosi's article, "Alarm over pharming attacks: identity theft made even easier." And if you have concerns to share or preventative tips to offer, or if you've even been scammed before by this tactic, share your experience with us so that we can all learn how to tackle this issue together. Be safe and be aware out there! TalkBack here.

Cheers!
Lee Koo
Manager, CNET community

TalkBack 27 of 106: IP-specific addresses

Post by: johnnybluenote on 02/23/05

First, let me say you can bookmark IP-specific address. For those that don't know, you type http:// in the address bar followed by the IP number of the site you want to go to. Once there, you can bookmark it. I have a number of my very important sites bookmarked by IP # - e.g., my bank, credit card company, etc.
Here are some popular IP addresses:
Microsoft - 207.46.245.92
E-bay - 66.135.208.89
Google 64.233.187.104
Amazon 207.171.175.35
PayPal - 216.113.188.66
CitiBank - 192.193.210.24

Also, here is a DNS tool for converting addresses from the www. form to the IP number:
http://www.ndo.com/servlets/dominfo

Regarding IP address, please note that if a site is addressed by a server company rather than on its own server, you may not be able to reach the address just by putting in the IP number. For instance, if you convert my company's web address (www.keystonecomputerconcepts.com) to an IP # (38.113.20.12) and then try to go directly to the site using the IP number, you get an error page. That's because we are hosted by a server hosting service.

Hope this helps anyone who needs more information.

TalkBack 61 of 105: SSL certificate verification defeats pharming

Post by: libove on 03/01/05

Phishing relies on users clicking on links which look like they will go to a particular web site but actually go elsewhere. Pharming hijacks DNS entries so that even the phishing-aware user who explicitly types in the web site they want (e.g. http://www.suntrust.com) will end up at a different web site anyway.

SSL certificate verification does defeat pharming, unless something else has already happened at the user's web browser to also defeat SSL certificate verification, of course. This can be as simple as a virus / worm / script exploit turning off the security options I'll describe at the end of this message, or as complex as a virus / worm / trojan / adware program actually changing the web browser to function differently. This is why security is a total process involving not just the right software (e.g. anti-virus, personal firewall) but also the knowledge of the user to configure and check things regularly, and to browse sensibly (don't download / install anything that you aren't certain is trustworthy, never click "yes" to toolbars, helpers, or anything else that pops up unexpectedly, etc).

Here's how SSL certificate verification works against pharming:

Scenario 1:
You type in e.g. http://www.suntrust.com
Someone has hijacked the suntrust.com domain, so that the IP address your computer gets for www.suntrust.com is really sending you to www.pharmer.com.
You look for the SSL "lock" in your web browser status bar, and you don't see it, so you stop.

Scenario 2:
You type in the web site address https://www.suntrust.com which has been hijacked, and since you explicitly use https:// it forces the browser to only go to an SSL enabled version of the web site.
Your browser goes to the hijacked destination https://www.pharmer.com.
The web server at www.pharmer.com sends its SSL certificate - a wholly valid certificate issued by a trusted CA .. but NOT issued to www.suntrust.com because SSL certificate issuers are quite good at ensuring that they do not issue certificates to any company other than the legitimate holder.
Your web browser, properly configured, pops up a warning saying that the certificate does not match the name of the web site, because the name of the web site is www.suntrust.com, but the SSL certificate is for something else (maybe www.suntrust2.com), so, being highly observant, you stop.


There are many possible variations on this theme, but those are the key ones from which most of the others stem.

To put more detail to it, we must rely, and historically we can rely, on the SSL certificate issuers e.g. Verisign (http://www.verisign.com), Thawte (http://www.thawte.com) to validate that the requestor of an SSL certificate for a web server legitimately has the right to have that certificate. So even though typing www.suntrust.com does not get you to the legitimate Sun Trust Bank web site, the fact that the real Sun Trust Bank web site is the only place which can have a www.suntrust.com SSL certificate protects you.

To make sure that your web browser properly validates SSL certificates, set the following options in Internet Explorer 6 (users of other browsers will find comparable settings somewhere in their browser configurations):

Tools -> Internet Options
Advanced tab
Under the Security section, make sure these options are checked:
* Check for publisher's certificate revocation
* Check for server certificate revocation
* Use SSL 3.0
* Warn about invalid site certificates

Make sure that the option "Use SSL 2.0" is not checked, because there are problems with the SSL 2.0 protocol which can make it possible for a pharmer to defeat SSL certificate verification.

I hope this is helpful.
-Jay Libove, CISSP

No comments: