December 12, 2024

Pharming

Internet spoofing attacks have been getting more and more sophisticated. The latest evil trick is “Pharming,” which relies on DNS poisoning (explanation below) to trick users about which site they are viewing. Today I’ll explain what pharming is. I’ll talk about fixes later in the week.

Spoofing attacks, in general, try to get a user to think he is viewing one site (say, Citibank’s home banking site) when he is really viewing a bogus site created by a villain. The villain makes his site look just like Citibank’s site, so that the user will trust the site and enter information, such as his Citibank account number and password, into it. The villain then exploits this information to do harm.

Today most spoofing attacks use “phishing.” The villain sends the victim an email, which is forged to look like it came from the target site. (Forging email is very easy – the source and content of email messages are not verified at all.) The forged email may claim to be a customer service message asking the victim to do something on the legitimate site. The email typically contains a hyperlink purporting to go to the legitimate site but really going to the villain’s fake site. If the victim clicks the hyperlink, he sees the fake site.

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. Another defense is to have your browser tell you the name of the site you are really visiting. (The browser’s Address line tries to do this, so in theory you could just look there, but various technical tricks may make this harder than you think.) Tools like SpoofStick display “You’re on freedom-to-tinker.com” in big letters at the top of your browser window, so that you’re not fooled about which site you’re viewing. The key idea in these defenses is that your browser knows which domain (e.g. “citibank.com” or “freedom-to-tinker.com”) the displayed page is coming from.

“Pharming” tries to fool your computer about where the data is coming from. It does this by attacking DNS (Domain Name Service), the service that interprets names like “freedom-to-tinker.com” for you.

The Internet uses two types of addresses to designate machines. IP addresses are numbers like 128.112.68.1. Every data packet that travels across the Internet is labeled with source and destination IP addresses, which are used to route the packet from the packet’s source to its destination.

DNS addresses are text-strings like www.citibank.com. The Internet’s routing infrastructure doesn’t know anything about DNS addresses. Instead, a DNS address must be translated into an IP address before data can be routed to it. Your browser translated the DNS address “www.freedom-to-tinker.com” into the IP address “216.157.129.231” in the process of fetching this page. To do this, your browser probably consulted one or more servers out on the Internet, to get information about proper translations.

“Pharming” attacks the translation process, to trick your computer somehow into accepting a false translation. If your computer accepts a false translation for “citibank.com,” then when you communicate with “citibank.com” your packets will go to the villain’s IP address, and not to the IP address of Citibank. I’ll omit the details of how a villain might do this, as this post is already pretty long. But here’s the scary part: if a pharming attack is successful, there is no information on your computer to indicate that anything is wrong. As far as your computer (and the software on it) is concerned, everything is working fine, and you really are talking to “citibank.com”. Worse yet, the attack can redirect all of your Citibank-bound traffic – email, online banking, and so on – to the villain’s computer.

What can be done about this problem? That’s a topic for another day.

Comments

  1. Well that’s weird. Making that post made the Sikhism post disappear! (And the spam advertising clothing that was above that.)

  2. What, precisely, is the relevance of a brief precis of Sikhism to DNS server authentication? Pray tell?

  3. One more problem with checking if the DNS address of a site changed, in two words: Load Balancing.
    (Some sites balance the load between servers by varying the DNS responses.)

  4. Sean Ellis says

    If my bank sent me an email telling me to use an IP address instead of the usual name I’d more than likely dismiss it as a phishing attempt…

    This is true. However, I was envisaging this information being enclosed within the same tamper-evident envelope as your new customer ID, PIN, initial password, etc.

    I guess it’s still open to attack, though, if you’re determined enough. Redirecting a known IP address would require access to routers rather than DNS servers, and there are known exploits for routers.

  5. The banks could even bypass DNS altogether and publish the URL of their secure site as an IP address. Imagine http://192.193.226.190/us/index.htm instead of http://www.citibank.com/us/index.htm. The user only has to bookmark this once, so it’s not a big inconvenience for him. Certainly no more of an inconvenience than having to remember a 12-digit customer number, 5 digit PIN, password and his grandmother’s blood group, just to log in.

    Except, of course, that 192.193.226.190 looks suspicious. If my bank sent me an email telling me to use an IP address instead of the usual name I’d more than likely dismiss it as a phishing attempt, or attempt to verify it (DNS poisoning notwithstanding!). As we’ve been telling users to check the URL carefully they’d probably get annoyed if we started telling them that a set of cryptic and ostensibly meaningless numbers is more secure, especially if they need to start double-checking first (which itself is vulnerable to the very attack it’s intended to prevent)…

  6. Sean Ellis says

    How about a DNS consistency check in the browser?

    Keep a log of all DNS queries and their results. If the result for a given query differs from last time, then alert the user. Perhaps only do this for secure sites, nominated by the user.

    The main problem with this that I can see is that sites get moved from machine to machine frequently. This should be easily addressable by someone like the big banks.

    The banks could even bypass DNS altogether and publish the URL of their secure site as an IP address. Imagine http://192.193.226.190/us/index.htm instead of http://www.citibank.com/us/index.htm. The user only has to bookmark this once, so it’s not a big inconvenience for him. Certainly no more of an inconvenience than having to remember a 12-digit customer number, 5 digit PIN, password and his grandmother’s blood group, just to log in.

  7. Bored Huge Krill says

    “Thus, the observant and clueful user can protect themselves against this of behaviour. All we then need are more observant and clueful users.”

    Bummer.

    That’s the one thing we’re not likely to see – at least – not in a large enough proportion to make attacks such as this unworkable.

    All of this class of attacks (such as phishing) need to be successful is a tiny proportion of non-savvy users. To defeat such attacks would require infinitessimally close to 100% of users to be “observant and clueful”, if that is what we rely on. That isn’t going to happen anytime soon.

    We can only conclude that designers of software and network infrastructure need to do better to ensure that users don’t need to be technically savvy in order not to be ripped off…

  8. Cypherpunk says

    I don’t see Joe Stewart’s page as describing a real attack on SSL. What he does say doesn’t make sense, his Man in the Middle attack:

    “In this scenario, an attacker tries to intercept secure communication between two parties. For example, Xavier wants to make an online purchase at Yuri’s website. The attacker poisons the cache at Xavier’s ISP, pointing traffic to Yuri’s site to Zamfir’s system. Zamfir accepts the incoming SSL connection, decrypts it, reads all the traffic, and makes the same request via SSL to Yuri’s site.”

    That won’t work because if Zamfir offers Yuri’s SSL certificate, he won’t be able to decrypt the data because he doesn’t know the private key. But if he offers a cert of his own, it won’t have http://www.yuri.com in the name field, only Yuri can get that cert. The user’s browser will pop up a big obnoxious warning saying that the cert name doesn’t match the web site name.

    He gives better advice when he says, “Always confirm SSL certificates when making secure online transactions.” SSL provides good protection against this class of attacks.

  9. Anonymous says

    tx dan’s link to the white paper now I see how the attack works. hungerburg

  10. most residential users will have their access providers dns servers configured, while most business users will have one on the lan. these are hopefully properly guarded servers. I do not see how dns spoofing can easily be done by an outsider: did I miss something? will I have to wait for the sequel?

  11. Where did this name “pharming” come from? I understand phishing as hacker-spelling of “fishing” for suckers. But “pharming” already has a meaning, it refers to manufacturing pharmaceutical products via genetic engineering of farm crops and animals. It’s a very logical and clever coinage in that context. I don’t see that DNS poisoning has any attributes that would lead to the word “pharming”.

    In Ed’s defense, he didn’t invent the term; it’s quickly become the synonym of choice for DNS poisoning (which itself used to be known as domain spoofing). I can see slightly different meanings for all three terms, but to answer your objection, this isn’t the first time a “logical and clever coinage” has been repurposed for computer use; spamming, spoofing, and poisoning are all metaphorical repurposings in their own right. Besides, I think the metaphor works here as well — by “pharming” you’re bringing people onto a property you control, without having to “phish” for them.

    As for SSL, Joe Stewart’s Security Focus white paper on DNS poisoning notes the vulnerability of SSL, via this method of redirection, to a man-in-the-middle attack. A combination of two theoretical (thus far) and extremely difficult exploits, to be sure, but if one puts the resources into the first the other would surely be a plausible target as well.

    We’ve known for years that DNS and the root name servers are a big vulnerability. They were set up in an era of trust that flowed downstream. As with any security process, one finds that securing one area — locking one back door — simply makes the criminals move on to the next back door. Since phishing is being made more difficult, the next generation of attacks are going to be more sophisticated.

  12. SSL Certificates are certainly one weakness in spoofing attacks. Firefox in particular has several extensions for this, one of which displays the url associated with the SSL Certificate on the status-bar. If this URL doesn’t match the location bar (at least in domain), something suspicious is happening.

    Thus, the observant and clueful user can protect themselves against this of behaviour. All we then need are more observant and clueful users.

  13. Cypherpunk says

    Where did this name “pharming” come from? I understand phishing as hacker-spelling of “fishing” for suckers. But “pharming” already has a meaning, it refers to manufacturing pharmaceutical products via genetic engineering of farm crops and animals. It’s a very logical and clever coinage in that context. I don’t see that DNS poisoning has any attributes that would lead to the word “pharming”.

    Also, there is in fact information on your computer that something is wrong. The site won’t be able to present an SSL certificate for citibank.com. This will keep your browser from displaying the lock icon that indicates that it’s talking to a secured site. Any site with significant financial implications should show that icon, so its absence is a clue that something is wrong.

  14. I know D. J. Bernstein promised to produce some DNS spoofing software as “guerilla promotion” for his new secure DNS protocol.