Recently there has been a lot of press about AT&T DNS servers being hit with a DNS Cache Poisoning attack.
Some new easier exploits were recently published, and many DNS servers are still vulnerable. And up until the new exploits were published publicly, the majority of DNS servers were vulnerable. This situation is worse once you realize that “safe” DNS servers can be poisoned second hand by transitive trust relationships, allowing one compromised DNS server to effectually poison the caches of other un-compromised DNS servers.
DNS Cache Poisoning has been a serious issue for years. The recent flurry of press regarding the compromised AT&T DNS servers is just the tip of the iceberg. It is only reasonable to assume that over the past several years a large number of DNS server have been serving compromised results at some point, either by direct poisoning or indirect poisoning. It is also reasonable to assume that this will continue for the foreseeable future.
In light of this, please re-read my post on 3rd party Javascript.
If I were a malicious hacker, let’s say working for the Russian Mob, or for myself, here is the easiest way to make some money:
1. Create javascript files designed to mask Google Adwords, Google Analytics, Doubleclick Ads, Overture Ads, and maybe a couple others. These scripts would have their cache related response headers set to be cached on the browser for 1 year. These scripts would call back to the real versions of themselves (so that ads show up, etc…). They would also intercept any form submission events and would look for form fields with names like “creditcard” or “ssn” or “password” or “accountnumber”, etc… If any are found, it would essentially clone the form and send the form data, the site hostname and page, the client’s IP address and cookies, etc… to a server I control.
2. Start cache poisoning as many DNS servers as I could find that are vulnerable to point the REAL domains for those scripts to my malicious copies.
3. Sit back and watch the Credit Card numbers roll in.
The best part is that by getting the browser to cache the script locally, I only have to have a computer hit the poisoned cache once to control it for a whole year. On most IE6 installations it’s also easy to actually install a javascript application on the user’s computer.
Personally I use Google javascripts on my site. However I don’t capture credit card numbers here, so the risk is low. If you run an e-commerce site, please do not underestimate the risks involved here.
Leave a Reply