Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Side-Channels on the Web: Attacks and Defenses

1,355 views

Published on

In this presentation we explore various side-channel attacks in the Web that can be used to leak information on cross-origin responses. These so-called XS-Leaks issues may allow an adversary to extract sensitive information from an unwitting visitor, ranging from personal information this victim shared with social media networks to CSRF tokens, which may lead to full account takeover.
Finally, we discuss the various defenses that can be used to harden web applications against the different types of attacks.

Published in: Internet
  • Be the first to comment

Side-Channels on the Web: Attacks and Defenses

  1. 1. Side-Channels on the Web: Attacks and Defenses Tom Van Goethem @tomvangoethem
  2. 2. https://cute-kittens.com
  3. 3. https://cute-kittens.com https://super-doggos.org
  4. 4. https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net
  5. 5. https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net BUNNIES ATTACK! ATTACK!!ATTACK!!
  6. 6. What can the bunnies (attackers) do?
  7. 7. 7 Attacker model • Cross-origin attack (evil-bunnies.net vs. cute-kittens.com) • Subject to Same-Origin-Policy • Can't extract information directly • Attacker infers information based on state of victim at target site • Logged in or not? • Search query has results? • Launch cross-site requests; can't access response directly • Attack needs to exploit side-channel leaks
  8. 8. https://evil-bunnies.net https://cute-kittens.com (1) visit malicious site
  9. 9. https://evil-bunnies.net https://cute-kittens.com (1) visit malicious site (2) return malicious JS
  10. 10. https://evil-bunnies.net https://cute-kittens.com (1) visit malicious site (2) return malicious JS (3) probe affected resources
  11. 11. https://evil-bunnies.net https://cute-kittens.com (1) visit malicious site (2) return malicious JS (3) probe affected resources (4) return user-specific response
  12. 12. https://evil-bunnies.net https://cute-kittens.com (1) visit malicious site (2) return malicious JS (3) probe affected resources (4) return user-specific response (5) use side-channel to infer information about response
  13. 13. 13 Response size may leak information about user state ~183kB
  14. 14. 14 Response size may leak information about user state ~19kB ~183kB
  15. 15. 15 Nethanel Gelernter and Amir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2015.
  16. 16. 16 Nethanel Gelernter and Amir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2015.
  17. 17. 17
  18. 18. 18 XS-Leaks • Server generates response based on user's state • Attacker tries to differentiate between two responses • Examples • Logged in (=> large response) vs. not logged in (=> small response) • User has access to resource (=> 200) vs. no access (=> 404) • Was used to uniquely identify users by giving them access to attacker-controlled resources [1] • Search query has results (=> response with iframe) vs. no results (=> no iframe) [1] Cristian-Alexandru Staicu and Michael Pradel. " Leaky Images: Targeted Privacy Attacks in the Web". Proceedings of the 28th USENIX Security Symposium, 2019.
  19. 19. time https://cute-kittens.com state_0 state_n
  20. 20. time https://cute-kittens.com state_0 state_nstate_1 state_1: browser initiated connection to target site 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site
  21. 21. time https://cute-kittens.com state_0 state_nstate_1 state_2 state_1: browser initiated connection to target site state_2: headers of response are received 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site Promise returned by fetch() resolved => measure time to generate response + delay/jitter (Tstate_2 - Tstate_1)
  22. 22. time https://cute-kittens.com state_0 state_nstate_1 state_2 state_3 state_1: browser initiated connection to target site state_2: headers of response are received state_3: complete response body received 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site Promise returned by fetch() resolved => measure time to generate response + delay/jitter (Tstate_2 - Tstate_1) Time returned by Resource Timing API (performance.getEntries()) => measure time to download response (Tstate_3 - Tstate_2)
  23. 23. time https://cute-kittens.com state_0 state_nstate_1 state_2 state_3 state_1: browser initiated connection to target site state_2: headers of response are received state_3: complete response body received state_4 state_4: browser cached response 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site Promise returned by fetch() resolved => measure time to generate response + delay/jitter (Tstate_2 - Tstate_1) Time returned by Resource Timing API (performance.getEntries()) => measure time to download response (Tstate_3 - Tstate_2) Resource added to HTTP cache; can be requested w/o connection => infer which resources were cached
  24. 24. 24 HEIST HTTP Encrypted Information can be Stolen through TCP Windows
  25. 25. 25 HEIST • Determine exact response size (compressed) • 1 TCP window = 10 TCP packets = 14480 bytes of data • 2nd TCP window can only start after ACK (→ additional round-trip needed) • Response fits in 1 TCP window → 1 RTT, otherwise 2+ RTTs • Use side-channel to detect when first byte is received fetch() promise resolves • Use side-channel to detect when full response is received Resource Timing API • Timing difference < 5ms? Then 1 TCP window, otherwise 2 TCP windows 12
  26. 26. Response (14480 bytes)
  27. 27. 1st TCP window
  28. 28. 1st TCP window fetch() resolves PerformanceEntry Timing difference
  29. 29. Response (14481 bytes)
  30. 30. 1st TCP window ACK … 2nd TCP window
  31. 31. 1st TCP window ACK … 2nd TCP window fetch() resolves Timing difference (much bigger) PerformanceEntry
  32. 32. 32 • Important prerequisite: reflection of request in response Needed to align on TCP window size • Needs some “window-tuning” for larger responses • Exact size is known after compression Allows for BREACH-like attack Extract secret information such as CSRF token • More information: see whitepaper https://tom.vg/papers/heist_blackhat2016.pdf HEIST
  33. 33. time https://messenger.com/t/<fb_id> state_0 state_n state_1 state_2 state_3 state_1: browser parsed response HTML win.frames.length == 3 state_2: JavaScript replaces iframe ONLY IF user has had contact with <facebook_id> win.frames.length == 2 state_3: iframe has been replaced win.frames.length == 3 const win = window.opener; win.location = `https://messenger.com/t/${facebookID}`; Credits: Ron Masas - http://ronmasas.com/posts/facebook-messenger-vulnerability/
  34. 34. 34 Browser state changes • As soon as a resource is requested, the browser will transition between different “states” • These state changes can be permanent or temporary • Permanent: frame is added to included web page • Temporary: load event is fired • Time and order when state changes occur can be important
  35. 35. 35 Detecting browser state changes • Two different responses can result in two different state change patterns • Strict requirement for performing practical XS-Leak attack • Attacker includes target endpoint as a resource • E.g. iframe (if no X-Frame-Options + needs rendering) • E.g. window.open (in case of XFO + needs rendering) • E.g. <img>.src (in case no rendering required) • Attacker observes properties/events/… associated with the included resource • E.g. frames.length • May need more advanced resource operations • E.g. first load resource X, then load resource Y
  36. 36. 38 XS-Leaks overview • Response size • Timing network connections • Browser-based timing attack (<video>, Cache API, AppCache) • Storage API (fixed , reintroduced for small disk devices, fixed again) • HEIST (TCP level) • Response status • Application Cache (error when resource redirects) • history.length (+1 in case resource redirected) • Resource Timing (difference between start and fetchStart property) • CSP (policy set by attacker, violation in case of redirect to other domain)
  37. 37. 39 XS-Leaks overview (2) • Cache status • AppCache (Cache-control: no-store resources cause error) • Timing (cached resources load much faster) • Resource content and operations • frames.length (for iframe or new opened window) • postMessage() to parent page (may contain sensitive content) • Event loop (spy on pattern of other processes) • Navigate to id (triggers blur event on attacker page) • More techniques likely to be discovered • Check out https://github.com/xsleaks/xsleaks/
  38. 38. 40 Defenses
  39. 39. 41 XS-Leaks defenses • Two main approaches 1. Prevent differences in responses 2. Prevent attacker from observing state-changes • Often a combination of both approaches • (1) is purely a server-side effort • (2) is often controlled by response headers that instruct browser • Using SameSite cookies can be very effective • Defends against all attacks except for those based on window.open
  40. 40. 42 XS-Leaks defenses • Different attack techniques may require different defenses • iframe attacks: set X-Frame-Options or CSP's frame-ancestors • Some defenses are built-in by default • Cross-Origin Read Blocking (CORB) – prevents potentially sensitive response (HTML, JSON, XML) to be in the same renderer as the including document Was originally implemented as a defense against Spectre • Soon: SameSite cookies • Soon: cache partitioning – entries in HTTP cache are bound to top document location (prevents attacker from detecting if a certain resource was cached)
  41. 41. 43 XS-Leaks defenses • Browser may give information on the nature of the request • Sec-Fetch Metadata: detect illegimate requests • Block such requests or return other content • Certain mechanisms require opt-in from the server • Cross-Origin Opener Policy (COOP) – drops reference to opened window, so attacks using window.open no longer work • Cross-Origin Resource Policy (CORP) – same-site | same-origin | cross- site; similar to CORB: block no-cors cross-origin/cross-site requests Sec-Fetch-Dest: image Sec-Fetch-Mode: no-cors Sec-Fetch-Site: cross-site
  42. 42. 44 XS-Leaks defenses overviews • What can I do (as a web developer)? • Use SameSite attribute on cookies • Prevent framing (X-Frame-Options/CSP frame-ancestors) • Send Cross-Origin-Opener-Policy: same-origin (should be adopted by several browsers soon) • What can I do (as a user)? • Avoid the evil bunnies? • Separate contexts (e.g. incognito; containers extension in Firefox)
  43. 43. 45 Conclusion
  44. 44. 46 Conclusion • Responses often depend on the state of the user • XS-Leaks can be used to extract side-channel information on response • Can be used to differentiate two responses • Leaks information on the state of the user (# search results, identity, …) • When browser loads a resource, it undergoes a series of state changes • Pattern of state changes leaks the information • Defenses: SameSite cookies, XFO, new mechanisms coming soon
  45. 45. Questions? @tomvangoethem

×