Invasive Browser Sniffing and Countermeasures

1. Invasive Browser Sniffing and Countermeasures • Aditya Sinha • Harshvardhan Kelkar

2. What is this paper about? • Browser Cache/History sniffing • Proposed Solution (URL personalization) • Implementation ,costs and security

3. Browser Caches/Browser History • Why use Browser Caches? • Where do they reside? • Vulnerable to timing based attacks. • What about Browser History?

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

5. How? • Spoofing • Impersonating Websites

6. AUSTRALIA LOTTO LOTTERY INC. • 5th Floor EastCommonwealth Centre55 Currie StreetAdelaide 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.

7. What happens next?? • Social Engineering • Detect online Behaviour • Its all from the contextual information.

8. Potential CounterMeasures • Clearing Browser Cache Manually • Disable all Caching • Limiting Caching on client side • Server side solution. (Prevention of verification by personalization)

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

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

11. What the Authors did? • Client side: Forcing Cache and History misses • Server side: Plug in solution

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

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

14. How these goals are achieved? • Customization technique for URLS.(Extention) • Cache pollution • Hiding vs Obfuscating

15. A Potential attack

16. A formal goal specification

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

18. Server Side Solution • Similar to middleware • The core is a filter • What does the filter do? • Modification/Customization

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

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

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

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

23. Example - Translator • C asks for S • Goes to S(t) • S(t) adds p , queries S(b) and replies

24. 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 !

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

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

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

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

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

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

31. 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 !

32. 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 !

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

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

35. Timing • Not much over head w.r.t time when “translating” - 1000 times loop

36. Cumulative Time

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

38. Cookie

39. Lazy Translation • For static Html pages • Pseudonyms stored at the same place • Administrator can specify before hand • No parsing for translator • Translator very happy

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

41. 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’>

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

43. Sample Translation Next, it updates all on-site references to use the pseudonym. This makes all the URLs unique: <a href=’http://test-run.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 !!

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