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
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?
- dual homed ipv6/ipv4 servers
Can someone still use the princeton attack on a Mozilla client?
Yes, by relying on a multisession attack.
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.
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
The useragent contacts the victim and decides that the www.evil.com/index.html file (from 188.8.131.52) 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.
- (princeton) Web Spoofing: An Internet Con Game
- (princeton) DNS Attack Scenario