The widespread demand for online privacy, also fueled by widely-publicized demonstrations of session hijacking attacks against popular websites (see Firesheep), has spearheaded the increasing deployment of HTTPS. However, many websites still avoid ubiquitous encryption due to performance or compatibility issues. The prevailing approach in these cases is to force critical functionality and sensitive data access over encrypted connections, while allowing more innocuous functionality to be accessed over HTTP. In practice, this approach is prone to flaws that can expose sensitive information or functionality to third parties. In this work, we conduct an in-depth assessment of a diverse set of major websites and explore what functionality and information is exposed to attackers that have hijacked a user's HTTP cookies. We identify a recurring pattern across websites with partially deployed HTTPS; service personalization inadvertently results in the exposure of private information. The separation of functionality across multiple cookies with different scopes and inter-dependencies further complicates matters, as imprecise access control renders restricted account functionality accessible to non-session cookies. Our cookie hijacking study reveals a number of severe flaws; attackers can obtain the user's home and work address and visited websites from Google, Bing and Baidu expose the user's complete search history, and Yahoo allows attackers to extract the contact list and send emails from the user's account. Furthermore, e-commerce vendors such as Amazon and Ebay expose the user's purchase history (partial and full respectively), and almost every website exposes the user's name and email address. Ad networks like Doubleclick can also reveal pages the user has visited. To fully evaluate the practicality and extent of cookie hijacking, we explore multiple aspects of the online ecosystem, including mobile apps, browser security mechanisms, extensions and search bars. To estimate the extent of the threat, we run IRB-approved measurements on a subset of our university's public wireless network for 30 days, and detect over 282K accounts exposing the cookies required for our hijacking attacks. We also explore how users can protect themselves and find that, while mechanisms such as the EFF's HTTPS Everywhere extension can reduce the attack surface, HTTP cookies are still regularly exposed. The privacy implications of these attacks become even more alarming when considering how they can be used to deanonymize Tor users. Our measurements suggest that a significant portion of Tor users may currently be vulnerable to cookie hijacking. (Source: Black Hat USA 2016, Las Vegas)

1. HTTP Cookie Hijacking
in the Wild: Security
and Privacy Implications
Suphannee Sivakorn*, Jason Polakis*,
Angelos D. Keromytis
*Joint primary authors

2. Who we are
Suphannee Sivakorn
PhD Student @ Columbia University
Jason Polakis
Assistant Professor @ University of Illinois at Chicago

3. Current State of Affairs
q Public discussion about need for encryption
- Crypto Wars, part 2
q Getting crypto right is difficult
- DROWN, FREAK, POODLE, Logjam, …
q SSL/TLS is fundamental for securing our communications
q Talk about encryption?
Ø More about lack of encryption
Ø “Web Services and our Quest for Finding Ubiquitous Encryption”
…sad tale without a happy ending … or partially happy?

4. Chapters

5. HTTP Threats Still Around
User tracking using third party cookies
(Englehardt et al., WWW 2015)
Cookie injection attacks via HTTP response
(Zheng et al., Usenix Security 2015)

6. HTTP Cookie Hijacking
Web Service
HTTP Cookie
HTTP

7. HTTP Cookie Hijacking – Known Threat

8. Migrating to HTTPS
~40% of top sites(140k) on the internet support HTTPS
– SSL Pulse, 2016

9. Oh, you thought it was encrypted?
Browser
Web Server
www.google.com

10. Oh, you thought it was encrypted?
Browser
Web Server
http://www.google.com
GET / HTTP/1.1
301/302 redirection https://
✓ HTTPS

11. Oh, you thought it was encrypted?
Browser
Web ServerGET / HTTP/1.1
301/302 redirection https://
HTTPS communication
https://www.google.com
✓ HTTPS

12. Oh, you thought it was encrypted?
Browser
Web Server
HTTPS communication
https://www.google.com
HTTP Cookie
✓ HTTPS
GET / HTTP/1.1
301/302 redirection https://

13. Cookie Hijacking in the Wild
• Sites support HTTPS, but usually not ubiquitous
• Services offer personalization over HTTP
• Complicated cookie inter-operability à Flawed access control
• Studied 25 major services from different categories
• 15 have partial deployment of HTTPS
• All 15 expose sensitive information and/or account functionality

14. Threat Model

15. What can we access using the stolen cookies?

16. Stealing Cookies
• Access to the targeted network
• Open Wi-Fi Network, Wiretapping, Middle box, Proxy, Tor exit node
• Network traffic sniffing programs
• e.g. TCPdump, Wireshark, TShark, Kismet, KisMac
• TCP Reassembly (if necessary)

17. Stealing Cookies
• Extracting Cookies
• Cookies in HTTP headers:
• HTTP Request: Host, Cookie
• HTTP Response: Set-cookie
GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
Cookie: SID=XXXXX; HSID=YYYYY; APISID=ZZZZZ
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0)
Gecko/20100101 Firefox/47.0
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Set-cookie: SID=XXXXX; Expires=Mon, 01 Jan 1970 00:00:01 GMT;
Path=/; Domain=.google.com;

18. Accessing data using stolen cookies
• Send HTTP or HTTPS Requests with the stolen cookies
• curl
• Web Driver, PhantomJS (Render Javascript, Images)
• Find XPaths of elements or texts contain user information
• Differences size/elements/texts when loading page
with cookie and without cookie
curl –H “User-Agent:”
--cookie “name=value; name=value” http://example.com

19. Search engines
• User information
email, profile picture, first/last name
Google Bing YahooBaidu

20. Search engines
• User information
email, profile picture, first/lastname
• Search/visited history
Google Bing YahooBaidu

21. Search engines
• User information
email, profile picture, first/lastname
• Search/visited history
• Saved locations
Google BingBaidu

22. Yahoo
• Many services
• Yahoo answers
• Email notification
title and snippet
• Extract contact list
• Send email as user

23. E-commerce
• All support HTTPS
• HTTPS pages only for login, account and checkout pages
• User information: username, email
• Items in cart, wish list, recent view items, purchased items
Amazon Ebay Walmart Target

24. E-commerce
• All support HTTPS
• HTTPS pages only for login, account and checkout pages
• User information: username, email
• Items in cart, wish list, recent view items, purchased items
• Ebay reveals shipping address
Amazon Ebay Walmart Target

25. E-commerce
• All support HTTPS
• HTTPS pages only for login, account and checkout pages
• User information: username, email
• Items in cart, wish list, recent view items, purchased items
• Ebay reveals full shipping address
• Facilitate spam and phishing
• Send recommendations to any email with custom message
Amazon Ebay Walmart Target

26. Ad Networks
• Ads presented to user based on user’s profile
• Ads reveal browsing history and/or sensitive user data
shown to attackervisited by user

27. Cookie Hijacking Cheat Sheet

28. Collateral Exposure – Extensions & Mobile Apps
Collateral cookie exposure is common.
Android apps a little more secure.

29. Attack Evaluation
ØDo users behave differently when on public WiFi?
ØAny mechanisms deployed that prevent hijacking?
• Monitored ~15% of Columbia’s public WiFi for 30 days
(IRB approval)
• Collected HTTP and HTTPS traffic
• URL / SNI
• Cookie name
• Hash of cookie value (differentiate users per website)

30. Large-scale Cookie Exposure
In total, 282K vulnerable accounts
67k
9k
23k
1.6k
124k

31. “Government agencies can collect HTTP
traffic without notice to users or admins.”
– Edward Snowden

32. Attack Implications – Tor Network
• Used by privacy-conscious users, whistleblowers, activists
• Tor Bundle is user-friendly
• HTTPS Everywhere pre-installed
• Monitored fresh Tor exit node for 30 days (IRB approval)
• Did not collect cookies, only aggregate statistics

33. Attack Implications – Tor Network
connections
~75% of connections over HTTPa practical deanonymization attack

34. Countermeasures
•
HTTPS Strict Transport Security (HSTS)
HSTS Preload
HTTPS Everywhere
Server-controlled mechanisms
Client-controlled mechanisms

35. HSTS
• Server instructs browser to only communicate over HTTPS
• HTTP response header sent over HTTPS
• HSTS Preload protects initial connection to server
• Eliminates HTTP à HTTPS redirection
Strict-Transport-Security: max-age=10886400; includeSubdomains; preload

36. HSTS: Issues
✘ Preload requires HTTPS on all subdomains
Legacy URL and functionality
✘ HSTS partial adoption
Main google and regional pages (google.*) still not protected by HSTS
✘ Early state of adoption and misconfigurations
[Kranch and Bonneau, NDSS 2015]
✘ Attacks
[J. Selvi, BlackHat EU ‘14], [Bhargavan et al., Security and Privacy ’14]
google.com/account
google.com/mail
account.google.com
mail.google.com
Protected Not protected

37. HTTPS Everywhere
• Browser extension from EFF and Tor
• Pre-installed in Tor browser
• Ruleset collections (community effort)
• Regular expressions rewrite “http://” to “https://”
http://example.com/foo à https://example.com/foo
<ruleset name=“Example”>
<target host=“example.com” />
<rule from=“^http:” to “https:” />
</ruleset>

38. HTTPS Everywhere: Issues
✘ Rulesets do not offer complete coverage (also contain human errors)
✘ Not functional in some HTTPS pages/requests (exclusion rule)
Amazon:HTTPS breaks adding products to basket
✘ Complicated for large websites
✘ Opt-in option to reject all HTTP connections
<exclusion pattern="^http://(?:www.)?amazon.com/gp/twister/(?:ajaxv2|dynamic-update/)" />
http://rcm-images.amazon.com/images/foo.gif
https://images-na.ssl-images-amazon.com/images/foo.gif

39. HTTPS Everywhere: Effectiveness
• Extract URLs of HTTP requests
from WiFi dataset
• Test URLs against HTTPS
Everywhere rulesets
• Over 70% accounts remain
exposed

40. Disclosure
• Sent detailed reports to all audited web services
“Enabling HSTS … is something that we are
actively working on as we speak.”
“The related tokens predate the existence of the
HttpOnly setting and have several legacy
applications that do not support this setting. On
newer applications we're working on new session
management tokens that are marked as "Secure"
and "HttpOnly".”
“We have looked in the behavior of
XXXXXXX cookie hijacking you
reported and can confirm that this is
expected from the XXXXXXX Service
stack. We do not rely on the
‘XXXXXXX’ cookie for authentication
purposes and as such authentication
would be required before visiting
sensitive areas of an account.”
“In this case, we found the issue to be
invalid as it is an accepted business risk.”

41. Sound Bytes
ØCookie hijacking remains a significant (yet overlooked?) threat.
ØServices sacrifice security for usability and support of outdated
clients or legacy codebase.
ØExisting defenses are insufficient. They reduce the attack surface,
but a single HTTP request is all you need!

42. Questions
Feel free to contact us:
polakis@cs.columbia.edu
suphannee@cs.columbia.edu