Transcript Dynamic Pharming Attacks and Locked Same

Dynamic Pharming Attacks and
Locked Same-Origin Policies For
Web Browsers
Chris Karlof, J.D. Tygar, David Wagner,
Umesh Shankar
Overview
• Motivation
• Background Information
– Attacks and Vulnerabilities
• Details
• Accomplishments
• Conclusion/Summary
Phishing
Pharming
Domain Name System
• Prior HOSTS.TXT file from SRI
Domain Name System
Vulnerabilities
• DNS Cache poisoning
• DNS Response forgery
Brief Aside
• Secure Sockets Layer (SSL)
• Uses X.509 certificate
Meh, idgaf
Same Origin Policy
• SOP – access control over web objects, one from
A can’t access another from B
• Determining origin of A and B
– Originating Host
– Port
– Protocol
•
•
•
•
http://www.foo.com/index.html
http://www.foo.com/other.html
https://www.foo.com/secure.html
http://www.xyz.com/index.html
Static vs. Dynamic
• Static - Consistently bogus query results
• Dynamic - Only sometimes bogus!
Dynamic Pharming
• Suppose A controls DNS queries for
www.vanguard.com
• Suppose users authenticate to www.vanguard.com
using client side SSL
• Suppose user’s machine is initialized with certificates
and vanguard knows pkeys
• 1) A initializes DNS entry to A’s IP address 6.6.6.6, sets
TTL = 0
• 2)V visits https://www.vanguard.com/index.html to
authenticate
• 3)Browser attempts SSL connection, requires A to
present X.509 certificate
Meh, idgaf
Dynamic Pharming
• 4)If user blindly goes ahead… this Trojan
document is returned
Dynamic Pharming
Dynamic Pharming
• 5) A will then update the DNS entry for
www.vanguard.com to the legitimate server
1.2.3.4
• 6) Browser then loads legitimate
https://www.vanguard.com/index.html
document into the iframe
• 7) Since over SSL legitimate server requests
client authentication, which it does
• 8) Javascript in iframe has free access (bad)
Dynamic Pharming
• Does not care about authentication system
• Exploits browser enforcement of SOP
• Since even the URL matches meticulous users
may still fall prey
Solutions?
• DNS pinning
– Browser caches result of DNS query fixed period
– Reject connections from victim forces DNS entry
refresh
– Round robin DNS
• Anti-Framing
Root of the problem
• Human stupidity – too difficult to address
• Browser SOP
– If based on domain name -> fail
– Try a locked same-origin policy
Locked Same-Origin Policy
• Locked web objects are only allowed to access
other web objects originating from the same
domain
• Doesn’t distinguish between spoofed domain
names and real ones (ignoring certificate
warnings)
• Simply augment SOP by tagging each web object
with a validity bit
– Allow access iff legacy SOP allows it
– Validity bits match
Problems?
• Server A for xyz.com has a valid cert
• Server B for xyz.com does not
– Why might this occur in practice
• Very low chance .05% in their study
Conclusions
• Due to DNS vulnerabilities pharming is a real
concern
• The legacy SOP not currently equipped to
adequately protect against pharming
• Locked same origin policy can “break the web”
but rarely, and using the validity bit offers
protection
– Still susceptible however, how?