Transcript Invasive Browser Sniffing and Countermeasures

Invasive Browser Sniffing
and Countermeasures


Aditya Sinha
Harshvardhan Kelkar
1
What is this paper about?



Browser Cache/History sniffing
Proposed Solution (URL personalization)
Implementation ,costs and security
2
Browser Caches/Browser History




Why use Browser Caches?
Where do they reside?
Vulnerable to timing based attacks.
What about Browser History?
3
Threats?



Phishing attacks
Wiki:In computing, phishing is an attempt to
criminally and fraudulently acquire sensitive
information, such as usernames, passwords
and credit card details, by masquerading as a
trustworthy entity in an electronic
communication.
Link Manipulation
4
How?


Spoofing
Impersonating Websites
5


AUSTRALIA LOTTO LOTTERY INC.
5th Floor East
Commonwealth Centre
55 Currie Street
Adelaide SA 5000,
South Australia.


WINNING NOTIFICATION




We are delighted to inform you of the result of the E-mail address ballot lottery draw of the
Australian cash-out lotto bv international programme,which took place on the 26th of MAY
2008.This is a computer generated lottery of Internet users using emailaddresses
for draws.
This lotto draw is fully based on an electronic selection of winners using their e-mail addresses
from different World Wide Web(www)sites.Your e-mail address attached to ticket number:
275-189-657-23-05 with Serial number 8756-05 drew the lucky numbers and bonus ball
number which subsequently won you the lottery in the 2nd category.You have therefore been
approved to claim a total sum of US$500,000.00 (five HUNDRED THOUSAND U.S DOLLARS) in
cash credit file ref:ILP/HW 47509/02.
6
What happens next??



Social Engineering
Detect online Behaviour
Its all from the contextual information.
7
Potential CounterMeasures




Clearing Browser Cache Manually
Disable all Caching
Limiting Caching on client side
Server side solution. (Prevention of
verification by personalization)
8
Client side Vs Server side




Both are complementary.
Address problem from different angles.
Server side solution plugs holes which
may arise in a client side solution.
Eg Caching proxy
9
Ways to conceal the Cache






Hide the references to visited websites.
Pollute the references.
Authors combined both methods.
Internal and entrance URLS.
Eg http://test-run.com
http://test-run.com/logout.jsp
10
What the Authors did?


Client side: Forcing Cache and History
misses
Server side: Plug in solution
11
Implementation Issues





The robots exclusion standard
User Agent values eg.
“Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.0)”
“Mozilla/5.0(compatible;googlebot/2.1)”
Use of Privileges
12
Goals as set by the Authors


Fullest possible use of browser caches and history
1. A service provider SP should be able to prevent
any sniffing of any data related to any of their clients,
for data obtained from SP.
2.The above requirement should hold even if caching
proxies are used.
3.Search engines must retain ability to find data
served by SP.
13
How these goals are achieved?



Customization technique for
URLS.(Extention)
Cache pollution
Hiding vs Obfuscating
14
A Potential attack
15
A formal goal specification
16





We let ‘A’ be an adversary controlling any member of C but C.
‘A’ may post arbitrary requests x and observe the responses.
A goal of ‘A’ is to output a pair (S, x) such that HITC(x) is true.
We say that pi(S) is perfectly privacy-preserving if A will not
attain the goal but with a negligible probability
We say that pi(S) is searchable if and only if E can generate a
valid response x to the query.
17
Server Side Solution




Similar to middleware
The core is a filter
What does the filter do?
Modification/Customization
18
Pseudonyms







Establishing a pseudonym
Entrance at the index page.
Pseudonyms and temporary pseudonyms are selected from a
sufficiently large space, e.g., of 64-128 bits length.
Pseudonyms are generated pseudorandomly each time any
visitor starts browsing at a web site.
Using a Pseudonym
Translators domain comes in play
Querystring like argument appended to URL
19
Pseudonym validity Check




Cookies
Http-referer
Message authentication codes
It is a policy matter to determine what to do
if a pseudonym or temporary pseudonym
cannot be established to be valid.
20
Robot policies





The same policies do not necessarily apply to robots
and to clients representing human users.
one could – use a whitelist approach ie allow certain
robot processes additional privileges. Eg a crawler or
a search engine with access to non-pseudonymized
data.
Alternately use temporary Pseudonyms.
What about other processes?
Privacy Agreements between Search engine and
Server.
21
Pollution Policy




A client C can arrive at a web site through four means: typing in
the URL, following a bookmark, following a link from a search
engine, and by following a link from an external site.
When is C’s Cache polluted?
How to choose the pollutants?
If S cannot guarantee that all of the sites in its pollutants list
will provide the same list, it must randomize which pollutants it
provides.
22
Example - Translator

C asks for S

Goes to S(t)

S(t) adds p , queries S(b) and replies
Translation Off Site References

Translator – Proxy for the page

Off site References ?

Knowledge from off site references
Two ways to handle it :

Forward to the client

Forward using the same redirection URL
Dont over-use the translator

A translator working on all sites is an open proxy server !
Redirection

Redirection – is it always necessary ?

Collaborate or Separate sites ?
Collaborate

Use the same translator

More work

Policy to see if needed
Separate

Shows up as internal page
Translation Policies

Off site Redirection Policy – Should redirection
take place through the translator ?
=> Is it safe or unsafe ?

Data Replacement Policy – Should data redirection
take place through the translator ? Same Question
.
=> Flash , Movies , Jpegs
Client Robot Distinction


If we are using artificially intelligent robots to access sites ?
HA ! I wish .
Client Robots means really dumb client applications eg vlc
player , Google Bot , Wget .

Does redirection work in the same way ?

History not affected

Cache affected
Special Cases 1

Akamai – Distributed Content Delivery System
Two ways to handle this


ISP provides the feature to translate to all customers (web
sites) for Akamai
Translator for the web site being accessed
Special Case 2

A =======> B

Redirection between A and B through A's translator .
I don't want to !
Two ways :

Shared – if B “adopts” A's pseudonym

Transfer – if B “accepts and replaces” A's pseudonym
Cache Pollution Reciprocity


Why create your own mess when you can get Site Admin's
to create mess for you !
A group of site Admin's could “agree” to pollute all the
cache's of all the clients with the same set of URL's
Security

Internal Pages
Pseudonym
1. Temporary – So not alive always
2. Shared – Trusted Party
If client is dumb to give it to third party , well then client's
screwed !
If trusted party is not really trustworthy , well everyone's
screwed !
Else pseudonym authenticated !
Security

Entrance Page
Dump Garbage – We are assured of “mess” from Site Admin's

Searchability
Search Indexing done by “robots”
Already excluded , oblivious to pseudonyms .

Smart clients
Clients can change pseudonyms but WHY !
Translator

Written in Java

Pseudonym's calculated using java.security.SecureRandom

Using 64 bit random number

Exclude “robot” or “wget”

Parsing in header of HTTP request and response
Algorithm

Get Request from Client

Is pseud present ?
=> If not generate and reply
=> If present , authenticate and reply with same pseud

If not text//html forward data through redirection policy
Timing

Not much over head w.r.t time when
“translating” - 1000 times loop
Cumulative Time
Considerations

Client Agent Type Forwarding
Blind Server knows only the translator agent

Cookies
Client sends cookie only to the server it got it from . If
translator on different domain then it ends up changing
cookies all the time . Not really something we want to do .
Cookie
Lazy Translation

For static Html pages

Pseudonyms stored at the same place

Administrator can specify before hand

No parsing for translator

Translator very happy
Sample Translation
<a href=’http://www.google.com/’>Go to google</a>
<a href=’http://10.0.0.1/login.jsp’>Log in</a>
<img src=’/images/welcome.gif’>
Sample Translation
The translator replaces any occurrences of the SB ’s address
with its own.
<a href=’http://www.google.com/’>Go to google</a>
<a href=’http://test-run.com /login.jsp’>Log in</a>
<img src=’/images/welcome.gif’>
Sample Translation
Then, based on ST ’s off-site redirection policy, it changes any
off-site (external) URLs to redirect through itself:
<a href=’http://test-run.com/redir? www.google.com’> Go to
google</a>
<a href=’http://test-run.com/login.jsp’>Log in</a>
<img src=’/images/welcome.gif’>
Sample Translation
Next, it updates all on-site references to use the pseudonym.
This makes all the URLs unique:
<a href=’http://testrun.com/redir?www.google.com?38fa029f234fadc3 ’> Go to
google</a>
<a href=’http://test-run.com/login.jsp?38fa029f234fadc3
’>Log in</a>
<img src=’/images/welcome.gif?38fa029f234fadc3 ’>
VOILA !!
Special Thanks



This is a completely stolen piece of work !
We didn’t do anything except make the
presentation !
All the work done by - Markus Jakobsson ,
Sid StammA