DNS: Spoofing and Pinning.

There are many ways to describe DNS; old, established, stable, .... Like most things, DNS isn't perfect and has very limited trust mechanisms. Today there are many ways to attack it. Attacks range from denials of service (DOS), to man in the middle (MIM), to spoofing.

Recently Unicode entries were allowed into DNS which may mean a site that looks like 'google.com' could exist but actually point to something else. Perhaps the oo's in gооgle would be Cyrillic instead of Latin. Such attacks while a concern to people involved in user agent development are beyond the scope of this document.

What concerns me is something called the Princeton attack, and perhaps some variations which I envisioned. The Princeton attack is a DNS based attack on JavaScript's domain based security scheme. It's generally accepted that the Princeton attack can't be prevented by a useragent and should really be solved by firewalls, but that didn't mean that Sun and Netscape didn't try to implement a fix for it. Nor does it mean that useragents shouldn't try to protect their users from the attack.

I'm not going to completely describe the attacks or the variants, but instead I'll focus on some of the problems encountered in Netscape's DNS Pinning solution.

First, what is DNS Pinning?

DNS Pinning involves storing the DNS host lookup result for the lifetime of the browser session.

When does a DNS Pin expire?

When you quit your browser, or when you go offline if the online/offline code isn't broken (it has been recently).

What does this break?

Can someone still use the princeton attack on a Mozilla client?

Yes, by relying on a multisession attack. Scenario: user visits innocuous.example.com which uses some ad service ads.example.com. www.evil.com is registered with ads.example.com to provide <iframe> ads. www.evil.com (66.66.66.66) sends the attack vector (an html file and possibly some javascript) with a timestamp or some other data. The html file / javascript tries to load an image from www.evil.com. If it succeeds then it shows the image and does nothing else. The user quits mozilla, and data for evil.com remains in the cache. The user runs mozilla and loads another-site.example.com which uses ads.example.com. ads.example.com sends a url for evil.com. the useragent contacts dns.evil.com and asks for the ip address for www.evil.com. For some reason dns.evil.com decides to switch to attack mode and returns the victim addresses instead of 66.66.66.66. The useragent contacts the victim and decides that the www.evil.com/index.html file (from 66.66.66.66) in its cache is new enough to use, so it uses it. www.evil.com/index.html checks whatever it needs to decide that www.evil.com is now tied to a victim (in this example it tries to load an image). As it's pinned to a victim, it relies on same origin to do whatever attack it feels like doing, just as if DNS pinning wasn't around.

References: