Side-Channels on the Web: Attacks and Defenses

Side-Channels on the Web:
Attacks and Defenses
Tom Van Goethem
@tomvangoethem

https://cute-kittens.com https://super-doggos.org

https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net

https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net
BUNNIES ATTACK!
ATTACK!!ATTACK!!

What can the bunnies (attackers) do?

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

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

(4) return user-specific response
(5) use side-channel to infer
information about response

13
Response size may leak information about user state
~183kB

14
Response size may leak information about user state
~19kB
~183kB

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
Nethanel Gelernter and Amir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and
Communications Security (CCS). ACM, 2015.

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.

time
state_0 state_n

time
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

time
state_0 state_nstate_1 state_2
state_2: headers of response are received
Promise returned by fetch() resolved
=> measure time to generate response + delay/jitter (Tstate_2 - Tstate_1)

time
state_0 state_nstate_1 state_2 state_3
state_3: complete response body received
Time returned by Resource Timing API (performance.getEntries())
=> measure time to download response (Tstate_3 - Tstate_2)

time
state_0 state_nstate_1 state_2 state_3
state_3: complete response body received
state_4
state_4: browser cached response
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
HEIST
HTTP
Encrypted
Information can be
Stolen through
TCP Windows

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

1st TCP window
fetch() resolves PerformanceEntry
Timing difference

1st TCP window
ACK
…
2nd TCP window

1st TCP window
ACK
…
2nd TCP window
fetch() resolves
Timing difference (much bigger)
PerformanceEntry

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

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>
state_3: iframe has been replaced
const win = window.opener;
win.location = `https://messenger.com/t/${facebookID}`;
Credits: Ron Masas - http://ronmasas.com/posts/facebook-messenger-vulnerability/

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

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)

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/

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

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)

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

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)

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

Side-Channels on the Web: Attacks and Defenses

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Side-Channels on the Web: Attacks and Defenses

Semelhante a Side-Channels on the Web: Attacks and Defenses (20)

Último

Último (20)

Side-Channels on the Web: Attacks and Defenses