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

Browser Based Protocols – Towards a Better Integration of TLS

Sebastian Gajek, Jörg SchwenkHorst Görtz InstituteRuhr-University Bochum

Dagstuhl 2009

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

Why Phishing Works

Attacks on Homebanking

Data transport to bank‘s server

SSL Tunnel

DNS server bank.com



SSL tunnelDNS server

www.attacker.org

bank.com

Trojan Horse modifies local

network configuration

Fake web page

through fake URL

DNS Cache Poisoning



Trojan Horse as Browser Helper

Object

SSL Tunnel

KeyloggerDNS server

www.attacker.org

bank.com

TAN

Target account of the financial agent,

amount

Why Phishing Works

Padlock indicating server-authenticated SSL connection is missing, but nobody cares!

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

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

Overview


2. DNS Attacks






DNS Cache Poisoning: Dan Kaminski (Black Hat 2008)

DNS server forvictim.orgAttacker

Birthday Paradox: Attack may succed within 10 sec.

DNS resolver

Query: aaa.victim.orgForward Query: aaa.victim.org

Answer: aaa.victim.orgAR: www.victim.org

Query: aab.victim.orgForward Query: aab.victim.org

Answer: aab.victim.orgAR: www.victim.org

• 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


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.


Overview


2. DNS Attacks






Successful and secure: MIT‘s Kerberos

Overview


2. DNS Attacks






Browser-based Cryptographic protocols

Browser Internet

Webserver

Browser-based Cryptographic protocols

Internet

Webserver

AJA

X e

ngin

e

Ren

derin

g

Java

scrip

t

Fla

sh

Rea

l

PD

F

Mal

war

e

ApplicationServer

Database

DNS

PKI

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

Browser-based Cryptographic protocols: SSL

Browser-based Cryptographic protocols: SOP (Same Origin Policy)

Document1

Cookies Form

Name Account Amount

Schwenk 443232 66,43

Script1

Document2

Script1:GetCookie

Script2:ModifyAccount

Script3:Send/Requestdata

SOP

Origin: banking.bank.com:443 Origin: attacker.org:443

Access Denied

Browser-based Cryptographic protocols: SOP and SSL

• No direct interaction between SSL and SOP

• Human user is forced to make security decisions

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

Overview


2. DNS Attacks






What‘s the Problem?

MIT Kerberos

1. Client KDC: IDC, IDS, nonce

2. KDC Client: E(Kc ; Kc,s,n) , E(Ks ; Tc,s)

3. Client Server: E(Kc,s ; Ac) , E(Ks ; Tc,s)

KDC

Client Server

1 2

3

MS Passport

1. Client KDC: E(SSL1 ; IDC, IDS, nonce)

2. KDC Client: E(SSL1 ; Tc,s)

3. Client Server: E(SSL2 ; Tc,s)

KDC

Client Server

1 2

3

SSL1

SSL2

MS Passport: Generic Weaknesses

Browser Relying Party Identity Provider

Request Data

Redirect: Authorization req.

SSL Handshake with(out) Server Authentication

Send-Data(c)

Data

Access Ticket c byDNS/PKI spoofing

Redirect + Send-Data(c = Enc (ticket))KS


Access Ticket c byCross Site Scripting

Overview


2. DNS Attacks






MS Cardspace

IdentitySelector

RelyingParty

ClientBrowser

GetBrowserToken(RP Policy)

WS-Trust RST Request (user credentials)

WS-Trust RSTR Response (security token)

Select Identity

Return security token

Identity needs credentials

IdentityProvider

TokenToken

HTTP/GET to protected page

PolicyPolicyPolicyPolicy

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

34

11HTTP/redirect with session cookie

Click2c

Quelle: Microsoft

Our Attack: Access Security Token through dynamic Pharming

SAML Artifact Profile

Quelle: Microsoft

Browser Server SAML Server

Request Data

Redirect:SAML Token req.


SAML Artifact

Data

Access SAML Artifact byDNS/PKI spoofing

Redirect + Send SAML Artifact

SSL Handshake

Access SAML Artifact byCross Site Scripting

Authenticate and Request SAML TokenGenerate andstore SAML token

SAML Artifact

SAML Token

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.

Overview


2. DNS Attacks






Securing SSO Protocols: Solution 1


Request Data


SSL Handshake with Client Authentication Key PKC

Send-Data(c)

Data

Dec (c) = KS PK ?C

Redirect + Send-Data(c = Enc (PK ))KS C




Request Data



Send-Data(c)

Data

Dec (c) = KS PK ?C

Redirect + Send-Data(c = Enc (PK ))KS C

SSL Handshake with Client Authentication Key PKC Token c can still be

stolen via XSS or DNS/PKI spoofing ... but it is now bound

to the browser!


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



Request Data

Redirect + ID .RP

SSL Handshake with Server Authentication (pk )K

Req + Cookie(c )S

Data

Redirect + Send-Data(pk : c = Enc (ticket))S S KS

SSL Handshake (pk )S

TLSSOP

Req + Data(c ,ID )K RP

pkK

pkS

http

Start

Ready

Req

TCP

Start TCP HandshakeReady

Start TCP HandshakeReady

Verify(c )K

pk :cS S

Start Start TCP HandshakeReady

Req

Ready

Verify(c )S


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 IDPROs• 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



Request Data

Redirect + Send-Data(RP)

SSL Handshake

Send-Data(c)

Data

Send-Data(RP, dk)

SSL SSL

dk dk

Redirect + Send-Data(c=E (token,dk))k

SSL Handshake dk dk

SSL Handshake

SSL

Dec (c) = (token, dk*)dk = dk* ?

KS


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 tokenPROs• 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

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.

Questions?

[email protected]

[email protected]

www.hgi.rub.de

www.nds.rub.de

Documents

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