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 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

3. Why Phishing Works

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

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

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

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 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

11. DNS Cache Poisoning: Dan Kaminski (Black Hat 2008) DNS server for victim.org Attacker Birthday Paradox: Attack may succed within 10 sec. 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

12. 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 DNS Cache Poisoning: Dan Kaminski (Black Hat 2008)

13. 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. DNS Cache Poisoning: Dan Kaminski (Black Hat 2008)

14. Overview 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

15. Successful and secure: MIT‘s Kerberos 1.Client  KDC: ID C, ID S, nonce 2.KDC  Client: E(K c ; K c,s,n), E(K s ; T c,s ) 3.Client  Server: E(K c,s ; A c ), E(K s ; T c,s ) KDC ClientServer 12 3

16. Successful and secure: MIT‘s Kerberos

17. Overview 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

18. Browser-based Cryptographic protocols At least one of the protocol participants is implemented by a browser –limited cryptographic functionality (mainly SSL/TLS) –weak security policies (e.g. same origin policy) –zero footprint: no personalization allowed Example: MS Passport as the BBCP version of Kerberos –authentication decoupled from key agreement –no cryptographic trust relationship between client (browser) and Passport server –ticket cookie not bound to a specific browser; anyone in possession of the cookie can successfully authenticate himself

19. Browser-based Cryptographic protocols Browser Internet Webserver

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

21. 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

22. Browser-based Cryptographic protocols: SSL

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

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

25. 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

26. Overview 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

27. What‘s the Problem?

28. MIT Kerberos 1.Client  KDC: ID C, ID S, nonce 2.KDC  Client: E(K c ; K c,s,n), E(K s ; T c,s ) 3.Client  Server: E(K c,s ; A c ), E(K s ; T c,s ) KDC ClientServer 12 3

29. MS Passport 1.Client  KDC: E(SSL1 ; ID C, ID S, nonce) 2.KDC  Client: E(SSL1 ; T c,s ) 3.Client  Server: E(SSL2 ; T c,s ) KDC ClientServer 12 3 SSL1 SSL2

30. MS Passport: Generic Weaknesses

31. Overview 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

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

33. SAML Artifact Profile Quelle: Microsoft

34. 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.

35. Overview 1.Why Phishing Works 2.DNS Attacks 3.Successful and secure: MIT‘s Kerberos 4.Browser-based Cryptographic Protocols 5.Why Passport Failed: XSS and beyond 6.MS Cardspace and other SSO Protocols 7.Securing SSO Protocols

36. Securing SSO Protocols: Solution 1

37. Token c can still be stolen via XSS or DNS/PKI spoofing... but it is now bound to the browser!

38. 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

39. Securing SSO Protocols: Solution 2

40. 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

41. Securing SSO Protocols: Solution 3

42. 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

43. 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.

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