1 / 42

Browser Based Protocols – Towards a Better Integration of TLS

Browser Based Protocols – Towards a Better Integration of TLS. Sebastian Gajek, Jörg Schwenk Horst Görtz Institute Ruhr-University Bochum Dagstuhl 2009. Overview. Why Phishing Works DNS Attacks Successful and secure: MIT‘s Kerberos Browser-based Cryptographic Protocols

lance
Download Presentation

Browser Based Protocols – Towards a Better Integration of TLS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Browser Based Protocols – Towards a Better Integration of TLS Sebastian Gajek, Jörg Schwenk Horst Görtz Institute Ruhr-University Bochum Dagstuhl 2009

  2. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  3. Why Phishing Works

  4. Attacks on Homebanking DNS server bank.com SSL Tunnel Data transport to bank‘s server

  5. Attacks on Homebanking www.attacker.org DNS Cache Poisoning Fake web page through fake URL Trojan Horse modifies local network configuration SSL tunnel bank.com DNS server Data transport to bank‘s server

  6. Attacks on Homebanking www.attacker.org Target account of the financial agent, amount Trojan Horse as Browser Helper Object TAN DNS server bank.com Keylogger SSL Tunnel Data transport to bank‘s server

  7. Why Phishing Works Padlock indicating server-authenticated SSL connection is missing, but nobody cares!

  8. Why SSL fails Users don‘t understand DNS • Why is service.bank.com good, but bankservice.com bad? Users don‘t understand SSL • Which certificates are good, which bad? What does all this stuff mean? First empirical studies: • Dhamija/Tygar/Hurst „Why Phishing Works“ Improved Protocol: Passmark solution employed by Yahoo and Bank of America

  9. Improved Online Banking: Passmark Sitekey • User stores personal passphrase and picture at BoA’s server • http-cookie identifies user against BoA • User enters password only if he recognizes his own picture • MITM attack described June 26, 2006 • MITM attack in the wild October 30, 2007 Problem: http cookie policy of browser relies heavily on (insecure) DNS

  10. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  11. DNS Cache Poisoning: Dan Kaminski (Black Hat 2008) DNS server for victim.org Attacker DNS resolver Query: aaa.victim.org Forward Query: aaa.victim.org Answer: aaa.victim.org AR: www.victim.org Query: aab.victim.org Forward Query: aab.victim.org Answer: aab.victim.org AR: www.victim.org Birthday Paradox: Attack may succed within 10 sec.

  12. DNS Cache Poisoning: Dan Kaminski (Black Hat 2008) • Birthday Paradox attack was already known in 2002 (Joe Stewart: DNS Cache Poisoning – The Next Generation). This could however be easily patched. • Additional Ressource Records: A DNS server is allowed to send data not related to the DNS Query. This was used for attacks, and thus additional RRs were restricted to the same domain (in-Bailwick). • Dan Kaminski: Clever combination of both attacks to circumvent security restrictions. • Many different queries for the same domain • Faked answers containing false data in additional RRs for www.victim.org (in-Bailwick) • Successful after approximately 320 queries • Countermeasure: Source port randomization

  13. DNS Cache Poisoning: Dan Kaminski (Black Hat 2008) Summary: DNS is insecure! • Even with Source port randomization, an attacker is successful after only 56.000 attempts. • This can be achieved within 10 hours.

  14. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  15. Successful and secure: MIT‘s Kerberos

  16. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  17. Browser-based Cryptographic protocols Browser Internet Webserver

  18. Browser-based Cryptographic protocols DNS Flash Real AJAX engine Javascript Rendering Internet PDF Application Server Database Webserver Malware PKI

  19. Browser-based Cryptographic protocols: Buzzwords • Web 2.0 • Social networks like StudiVZ, Youtube, Flickr, … • New applications like Google Maps, … • A lot of Javascript code + XMLHttpRequest: AJAX • SaaS (Software as a Service) • Classical desktop applications now offered through browser • E.g. MS Word → Adobe Buzzword • Browser now has the role of an operating system • SOA (Service Oriented Architecture) • New paradigm for server applications • Browser as the central client component

  20. Browser-based Cryptographic protocols: SSL

  21. Browser-based Cryptographic protocols: SOP (Same Origin Policy) Document1 Document2 Script1 Script3: Send/ Request data Cookies Form Script1: GetCookie Script2: Modify Account Name Account Amount Schwenk 443232 66,43 Origin: banking.bank.com:443 Origin: attacker.org:443 Access Denied SOP

  22. Browser-based Cryptographic protocols: SOP and SSL • No direct interaction between SSL and SOP • Human user is forced to make security decisions

  23. Browser-based Cryptographic protocols: Classical Attacks on SOP • XSS (Cross Site Scripting) • Inject attacker script code into web page delivered by victim server → SOP will grant access to all web objects from victim • Non-persistent: e.g. script coded in query string of URL, returned as part of the dynamically generated web page • Persistent: e.g. iFrame injection through vulnerabilities of content management system • Pharming (DNS based attacks) • Attacker somehow “steals” Domain name of the victim • All data for victim.com is now sent to the attacker • DNSSEC only partly solves the problem

  24. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  25. What‘s the Problem?

  26. KDC 1 2 3 Client Server MIT Kerberos • Client  KDC: IDC, IDS, nonce • KDC  Client: E(Kc ; Kc,s,n) , E(Ks ; Tc,s) • Client  Server: E(Kc,s ; Ac) , E(Ks ; Tc,s)

  27. KDC 1 2 3 Client Server MS Passport SSL1 SSL2 • Client  KDC: E(SSL1 ; IDC, IDS, nonce) • KDC  Client: E(SSL1 ; Tc,s) • Client  Server: E(SSL2 ; Tc,s)

  28. MS Passport: Generic Weaknesses

  29. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  30. MS Cardspace ClientBrowser Identity Selector Relying Party Identity Provider HTTP/GET to protected page 1a HTTP/redirect to login page 1b HTTPS/GET to login page 2a HTTPS login page 2c Policy 2b Click GetBrowserToken(RP Policy) 3 HTML information card tag Select Identity 4 WS-MEX GetMetadata Request 5 Identity needs credentials WS-MEX GetMetadata Response 6 WS-Trust RST Request (user credentials) 7 WS-Trust RSTR Response (security token) 8 Returnsecuritytoken Our Attack: Access Security Token through dynamic Pharming Token 9 HTTPS/POSTwithsecurity token 10 HTTP/redirect with session cookie 11 Quelle: Microsoft

  31. SAML Artifact Profile Quelle: Microsoft

  32. Summary: There is no secure browser based SSO protocol! Generic Weaknesses: • Storage of security tokens within the browser’s DOM • this doesn’t make sense at all, first step out of this dilemma: Microsoft’s http-only cookies • Security heavily relies on the (non-existent) security of the DNS • Rollout of DNSSEC would not completely solve the problem, since attacks on routing protocols are still possible (-> Youtube vs. Pakistan) • No integration of higher layer protocols (including SOP) with TLS: The two most important browser security features do not talk to each other! • This is where our research starts.

  33. Overview • Why Phishing Works • DNS Attacks • Successful and secure: MIT‘s Kerberos • Browser-based Cryptographic Protocols • Why Passport Failed: XSS and beyond • MS Cardspace and other SSO Protocols • Securing SSO Protocols

  34. Securing SSO Protocols: Solution 1

  35. Securing SSO Protocols: Solution 1 Token c can still be stolen via XSS or DNS/PKI spoofing ... but it is now bound to the browser!

  36. Securing SSO Protocols: Solution 1 Description: • Authentication is done via TLS, ID is the client’s public key (no PKI!) • Authorization is done via the IP, client ID is cryptographically bound to the token PROs • Easy to implement, no PKI required • No changes to browsers required • Secure against XSS, Pharming, attacks on routing protocols, … • Partial resistance to attacks by local malware can be achieved through the use of smart cards (PKCS#11) CONs • Browser can be identified through unique ID

  37. Securing SSO Protocols: Solution 2

  38. Securing SSO Protocols: Solution 2 Description: • After successful completion of the TLS handshake, the browser learns the public key of the server • Decisions to grant or to deny access in the Strong Locked SOP are based on this ID PROs • Browser remains anonymous • Easy to implement: plugin/browser extension with separate token database • Secure against XSS, Pharming, attacks on routing protocols, … CONs • Browser must be modified • Partial solution: for SSO only

  39. Securing SSO Protocols: Solution 3

  40. Securing SSO Protocols: Solution 3 Description: • Cryptographic session ID dk (e.g. hash of master secret) of the TLS connection between browser and RP is communicated to higher layer protocols • Browser includes dk in his authentication request • IP cryptographically binds this value to the issued token PROs • Browser remains anonymous • Secure against XSS, Pharming, attacks on routing protocols, … CONs • Browser must be modified • Partial solution: for SSO only • Difficult to implement: feature must be added to all TLS implementations

  41. Publications • Sebastian Gajek, Mark Manulis, Ahmad-Reza Sadeghi, Jörg Schwenk: Provably Secure Browser-Based User-Aware Mutual Authentication over TLS. ASIACCS'08 • Detlef Hühnlein, Bud Brugger, Jörg Schwenk: TLS Federation - a Secure and Relying-Party-Friendly Approach for Federated Identity Management. CAST Biosig 2008 • Sebastian Gajek, Lijun Liao, Jörg Schwenk: Stronger TLS Bindings for SAML Assertions and SAML Artifacts. ACM SWS'08 • Sebastian Gajek, Tibor Jager, Mark Manulis, and Jörg Schwenk. A browser-based kerberos authentication scheme. ESORICS'08 • Sebastian Gajek, Mark Manulis, and Jörg Schwenk. Enforcing user-aware browser-based mutual authentication with strong locked same origin policy. ACISP'08 • Sebastian Gajek. A universally composable framework for the analysis of browser-based protocols. ProvSec'08, volume 5324 of LNCS, pages 313-328. Springer, 2008. • Sebastian Gajek, Mark Manulis, Olivier Pereira, Ahmad-Reza Sadeghi, and Jörg Schwenk. Universally composable analysis of tls. ProvSec'08, volume 5324 of LNCS, pages 283-298. Springer, 2008.

  42. Questions? joerg.schwenk@rub.de sebastian.gajek@rub.de www.hgi.rub.de www.nds.rub.de

More Related