Closed Bug 1350072 Opened 7 years ago Closed 7 years ago

BREACH via StorageManager reflecting compressed Storage size

Categories

(Core :: DOM: Core & HTML, defect)

55 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1290481

People

(Reporter: neti1987, Unassigned)

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

XS-BREACH attack: The famous to launch the BREACH attack without eavesdropping capabilities and even where there is no compression on the HTTP response body!

What did you do? (steps to reproduce):
-------------------------------------
Brief background:
The BREACH attack (http://breachattack.com/) is a famous attack that allows eavesdropping attacker to extract (possibly sensitive) data from website by exploiting the compression side-channel; in particular, the attack exploits the compression of HTTP response's body. HTTPS can make it slightly harder, but as encryption does not hide length - it cannot prevent the attack.

Three conditions for launching the BREACH attack:
- Be served from a server that uses HTTP-level compression
- Reflect user-input in HTTP response bodies
- Reflect a secret (such as a CSRF token) in HTTP response bodies
Additionally, the attacker must have eavesdropping capabilities, and he launch the attack during a visit of the victim in a page where the attacker can run a script (cross-site attack that requires also eavesdropping).

XS-BREACH:
This report presents a novel new attack that allows to launch the BREACH attack without eavesdropping capabilities, and even when the response is not attached.

The attack was tested successfully on the latest versions of the Nightly builds, and it does not work in the regular build because one of the required features is not enabled by default in it.

The attack flow:
Precondition: there is a secret (e.g., anti-CSRF token) in HTTP response (e.g., webpage), and there is an input that is reflected in that response as well (but not necessarily with special characters that may lead to other attacks like XSS).

The attacker can launch the BREACH attack by sending requests, caching their responses and then using the navigator.storage.estimate function to get how much space each cached response takes.

Q: Why does it work even if the HTTP response is not compressed?
A: It seems that Firefox applies compression on the responses when they are cached (probably for space efficiency). I launched the attack demo on a php page with and without compression (just commented 'out ob_start("ob_gzhandler");') and it did not change anything!

Q: How can you get the exact size of the eavesdropping
A: Using navigator.storage.estimate (https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate) it is possible to get the used cached space. The attacker only need to subtract between two outputs of this functions before and after caching the response.

Q: How could it be done efficiently?
A: In the BREACH attack, the attacker guesses the response character by character. In XS-BREACH attacks, the attacker can send all the guesses concurrently, cache them, and them to measure their size by duplicating each of them and measuring the cache space before and after the duplication. 
That way, the attacker should not wait for each response, but he loads sets of requests at the same time.

Firefox versions tested: latest Nightly builds (53-55).

A demo of the attack is attached.
In this demo there is a php webpage (index.php) in which there is a 21-digit CSRF token. The page does not use gzip compression in its response (ob_start("ob_gzhandler"); is commented out in index.php). 
The page attackpl.html will run the attack once you click the button in it.
Open the console to see log description.



Actual results:

Each cached HTTP response is compressed and only then cached. Consequently, the attacker succeeds to extract the CSRF token by exploiting the compression side-channel.



Expected results:

HTTP responses must not be cached before they are being cached, as this exposes the websites for compression side channel attacks like XS-BREACH.
Notice, that in other browsers (e.g., Chrome), it is possible also to get the exact size of resources that are cached - but they do not save them cached.
Group: firefox-core-security → core-security
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Group: core-security → network-core-security
I see that the status is still "UNCONFIRMED".

To reproduce this issue (so it can be confirmed):
0. Run XAMP/LAMP/WAMP.
1. Put the attached files in relevant folder (e.g., htdocs or one of its subfolders).
2. Surf to the attack html file via your browser (127.0.0.1/folder-path/attackpl.html).
3. Click on the "Start" button and open the console to see the attack log.
4. The attack will extract the anti-CSRF token from the index.php file via the XS-BREACH attack.

To see that the attack does not require HTTP response compression, comment in/out the relevant line in index.php and launch the attack again.

To launch the attack from different origins, you can change your local DNS configurations such that victim.com will point to 127.0.0.1.
E.g., add to your host file:
127.0.0.1	victim.com

Then, change the baseTargetUrl parameter (line 4 in attackpl.html file) to your file, relatively to victim.com:
baseTargetUrl = "http://victim.com/folder-path/index.php?";

Now you can launch the attack from http://127.0.0.1/folder-path/attackpl.html to http://victim.com/folder-path/index.php, simply by surfing to http://127.0.0.1/folder-path/attackpl.html and clicking on the start button.
(Results will be the same, but this is how you can verify that the attack really works on cross-domains)
andrew is this something the API ought to lie about? Seems that the compression is a feature and the API being honest about it is also a feature.. from a wire-networking pov BREACH has always been something the server really needs to defend against (don't compress stuff with secrets - always a good policy).
Flags: needinfo?(overholt)
Summary: XS-BREACH attack: The famous to launch the BREACH attack without eavesdropping capabilities and even where there is no compression on the HTTP response body! → BREACH via StorageManager reflecting compressed Storage size
Anne knows better than I do here.
Flags: needinfo?(overholt) → needinfo?(annevk)
This is a duplicate of bug 1290481 as far as I can tell.
Flags: needinfo?(annevk)
thanks - looks that way to me too.
Component: Networking: HTTP → DOM
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
The duplicate of this issue is already public. Opening up based on Anne's request.
Group: network-core-security
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: