Unexpected secrets and reflections

The Rupture class of compression side-channel attacks attempts to steal secrets exchanged over an HTTPS channel, particularly focusing on secrets contained in HTTPS responses. In these attacks, the attacker also controls a portion of the plaintext known as the reflection. This post describes what sort of secrets can be the goal of these attacks, some of them obvious, while others unexpected. The reflections that the adversary is controlling can also sometimes be unexpected.

The number one target of web attacks are authentication / session cookies. These are carried in the HTTPS request and are a high-value target, as stealing them allows the attacker to login as the user. CRIME, a compression side-channel attack that is no longer applicable targeted cookies.

The most obvious high-value secrets in HTTPS responses are CSRF tokens. These tokens are present in all typical HTTPS responses that contain HTML forms, as they are required to prevent CSRF attacks. The CSRF attack is a very powerful attack, which allows an adversary to trick the target web server into thinking that the victim user submitted a form, while they didn't really submit one. If the CSRF token is stolen by an adversary, it makes it possible to fake form submissions as the user and therefore it can be used to make the user "like" Facebook posts, "retweet" Twitter tweets, send Gmail emails, change their LinkedIn bio, logout of Reddit, post a Facebook status or comment, and so on. An example of a CSRF token on Gmail is shown below:

A CSRF token, a typical secret
The CSRF token, a typical secret

Therefore, if an adversary manages to steal a CSRF token, they are able to fully impersonate the user when it comes to performing actions, except those requiring special input (such as changing your password requiring entering your old password). CSRF tokens were targeted by the original BREACH attack.

However, there are other secrets contained in HTTPS responses that are of interest. HTTPS today is used in mission-critical applications, such as finance (e-banking or stock trading). Therefore, other high-value secrets contained in HTTPS responses can be monetary amounts; if stolen they could allow an adversary to perform insider trading, for example.

Other examples of important secrets returned in HTTPS responses are the bodies of email messages in Gmail, the chat messages received or sent to a friend on Facebook, the family-only status updates on Facebook, or the contents of documents and spreadsheets in Google Docs. The list of online friends on Facebook or on Google Hangouts can be an important secret too, as they contain all the important contacts of the victim. In practice any piece of information which is only accessible when logged in is potentially a secret.

Now that we've covered a list of possible secrets, let's talk about reflections.

In the CRIME attack, part of the "reflection" controlled by the adversary was the URL being visited. Because the exact same URL was being sent as part of the HTTPS request, the attacker had control over a portion of the plaintext that would be encrypted. However, this can no longer be used in BREACH where the HTTPS response is targeted.

In the BREACH attack, the reflection used originally was a reflected URL parameter. The typical choice for this is a search parameter. A search parameter is a part of the URL, and therefore is adversary-controlled. The search parameter is reflected in the HTML in a plaintext that looks like "You searched for X".

A search query, a typical reflection
The search query string, a typical reflection

However, it is worth noting that the adversary can often control other parts of the plaintext which are not direct URL reflections. While we call them "reflections" in our terminology, they are not strictly reflected directly. There can sometimes exist unexpected reflections.

An adversary-controlled reflection can be a Gmail email body in the victim's inbox. This can be achieved by the adversary sending an email to the victim, with no action required by the victim. Similarly, a chat message received by the victim can be adversary-controlled, and therefore can constitute a reflection. A tweet, a Facebook status update, or a friend's name in the list of online friends can all be adversary-controlled, potentially. All the adversary needs to do is add the victim as a friend and wait to be accepted, then change their name or send them a chat message.

As you can see, the same portion of the plaintext can sometimes function as both a secret and a reflection, depending on who controls it. This simple fact makes it impossible to provide generic defence mechanisms in which reflections and secrets are seperated into different responses, as it cannot be known whether a particular piece of information is a reflection or a secret. The key ingredient in such defence is understanding whether a particular portion of the plaintext is adversary-controlled or not, and for many pieces of information such as email bodies, that remains unknown to the application.