Browser Based Protocols – Towards a Better Integration of TLS

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