In-Depth

Q&A: How to Assess Pharming Threats

Pharming attacks are on the rise. Should your organization be concerned?

• By Mathew Schwartz
• 04/27/2005

With pharming attacks are on the rise, how concerned should your organization be?

The Anti-Phishing Working Group characterizes pharming as “phishing without a lure.” In other words, attackers can change the IP addresses in a domain name server (DNS). So even though a user might enter a legitimate address, the DNS might return a false IP address.

Attackers can exploit this vulnerability to redirect users to sites that contain advertising, install adware, or look so real that users enter their personal information, which the site then captures and relays to attackers. Recently pharmed organizations include Citibank, CNN, and FedEx.

To discuss such attacks and how to mitigate them, Security Strategies spoke to Sanjay Raja, director of product marketing for Top Layer in Westborough, Mass.

What kinds of pharming attacks exist today?

The two main things we’ve seen are redirecting Web traffic to a bogus Web site and man-in-the-middle attacks. Redirecting, or re-proxying, just means [sending] the traffic [to a different IP address]. Then the less-known, or else less-used, I guess, type would be the man-in-the-middle attacks, where someone poisons the cache, then accepts queries in between—say in between the user and an e-commerce site … to be able, for example, to read credit card data.

Which is more common?

The redirects. We’ve seen some people be concerned about the spoofing, but it’s harder to do that. You’d have to initiate a session on one end with the user and a session on the other end with the real site, and handle traffic in between. You still have to talk to the [user’s intended destination site], because it might [return] some personal information the user expects to see. … So you need to have both the Web site and to spoof all the packets going back and forth between the user and the Web site.

So attackers, if they want to use pharming to capture personal information, create a look-alike site?

That’s definitely what happens: someone creates a mock site. And, of course, the quality is getting better. It used to be that even for the e-mail [phishing] attacks, you could tell from the reply-to field that it was a bogus e-mail, but these days, the Web sites attackers are using may look perfect. For example, for a recent Washington Mutual attack, it was hard to tell the difference between the two.

Are spoofing attacks much more difficult to execute than just redirecting people to another site?

Yes … yet at the same time, you can get far more information, because you’re not only getting information from the user—you’re also getting personal information from the e-commerce site. So it’s a little bit different, a little more complex, but at the same time you can do a little more damage.

Have there been many pharming attacks?

The SANS Institute just did a report … about this becoming an increasing problem, especially against Microsoft servers, and the SANS Internet Storm Center reported that there have been three major attacks since early March. Two attacks drove users to adware-installation sites, and another routed users to a place that sold herbal supplements. So those are the most recent ones, just in terms of rerouting users to other sites.

Some of the more high-profile companies affected include Citibank, CNN, FedEx, and OfficeMax, and this was just in the last few months.

How exactly does a pharming attack work?

The way DNS maintains security is by … having transaction IDs and numbers that are supposedly random, for verifying the message when it comes back. But the problem is, people have figured out a way to hone in on a smaller subset of those transaction ID numbers, based on all the requests that get sent out, and … they try to find that exact TCP ID and transaction number through brute force. And [this technique] has been prone to hit that number, based on [repeated attempts]. …

Is bind, which often handles DNS on Linux or Unix machines, the weak point?

Yes, bind is really not that random, so there’s an easy way to identify a smaller subset of probable numbers [which are transaction IDs]. And unfortunately, people haven’t been able to update bind well enough to fix these things. …

So there are a number of exploits where someone can hone in on a small subset of DNS IDs. … All they need is to generate 10,000 responses to get a hit, and generating all of those is [easy]. The problem with DNS is it looks at everything that comes back and just rejects the ones that don’t meet its criteria. In other words, the DNS server gets 10,000 responses and throws away all that don’t match, but if it finds one that has the right ID, it then puts it in its cache. …

Once an attacker poisons a cache, how long until the cache resets?

It’s based … on the number of hits the server is receiving. … It’s usually every 15 to 30 minutes, depending upon the server. … But it relates to site performance, and if a lot of people are turning up on the site, you might crank up your cache time to an hour.

So the cache might refresh in an hour or a half hour, but if I’m constantly sending these attacks, it might not be something that raises a red flag for a reporting application. …

And if I keep sending them every half hour, this flood of 10,000 responses, I could continually change the cache, and some sites might notice or might not. A bank, for example, might notice the dip in the volume of users then logging on. Or it might not affect the entirety of a Web site … it might just affect regional customers.

How do you guard against that?

We place our device in front of the DNS servers, since the most common way of doing this poison attack is just by flooding the DNS server with requests. Top Layer … has the ability to prevent these multiple [transaction ID] responses from coming back to the server, by only allowing legitimate IDs to be returned. … So the chance of the cache getting poisoned gets reduced significantly [and] the random number of bogus responses generated by an attacker becomes nullified. … We have a number of other checks as well to ensure that the response coming back hasn’t been modified, [for example] to cause buffer overflows.

How else can organizations protect against this type of attack?

It’s very difficult to do it, because … even if you have a [security] application on the bind servers, they tend to not restrict any responses and to look at each one. There’s really no way for the host to first look at whether this is a valid response or not. … So really [the best defense] is to limit the number of responses that come back, and do a better mapping of responses.

Now, newer versions of DNS do have better random number generators, but brute force attacks can still work against them.

Do newer versions of bind fix the problem?

Bind versions 9 and above tend to be more resistant against this type of attack. But the way things are going, as shown by attacks in the last few months, it’s just a matter of flooding with more responses. Now people have the ability to flood 100,000 responses through one gigabit-per-second attacks. So the solution is to make sure you have the latest version of bind, but it still doesn’t solve the whole problem.

Related Articles:

Phishing Attacks Skyrocket
http://www.esj.com/Security/article.aspx?EditorialsID=1308