Table of Contents
Fetching ...

Injection Attacks Against End-to-End Encrypted Applications

Andrés Fábrega, Carolina Ortega Pérez, Armin Namavari, Ben Nassi, Rachit Agarwal, Thomas Ristenpart

Abstract

We explore an emerging threat model for end-to-end (E2E) encrypted applications: an adversary sends chosen messages to a target client, thereby "injecting" adversarial content into the application state. Such state is subsequently encrypted and synchronized to an adversarially-visible storage. By observing the lengths of the resulting cloud-stored ciphertexts, the attacker backs out confidential information. We investigate this injection threat model in the context of state-of-the-art encrypted messaging applications that support E2E encrypted backups. We show proof-of-concept attacks that can recover information about E2E encrypted messages or attachments sent via WhatsApp, assuming the ability to compromise the target user's Google or Apple account (which gives access to encrypted backups). We also show weaknesses in Signal's encrypted backup design that would allow injection attacks to infer metadata including a target user's number of contacts and conversations, should the adversary somehow obtain access to the user's encrypted Signal backup. While we do not believe our results should be of immediate concern for users of these messaging applications, our results do suggest that more work is needed to build tools that enjoy strong E2E security guarantees.

Injection Attacks Against End-to-End Encrypted Applications

Abstract

We explore an emerging threat model for end-to-end (E2E) encrypted applications: an adversary sends chosen messages to a target client, thereby "injecting" adversarial content into the application state. Such state is subsequently encrypted and synchronized to an adversarially-visible storage. By observing the lengths of the resulting cloud-stored ciphertexts, the attacker backs out confidential information. We investigate this injection threat model in the context of state-of-the-art encrypted messaging applications that support E2E encrypted backups. We show proof-of-concept attacks that can recover information about E2E encrypted messages or attachments sent via WhatsApp, assuming the ability to compromise the target user's Google or Apple account (which gives access to encrypted backups). We also show weaknesses in Signal's encrypted backup design that would allow injection attacks to infer metadata including a target user's number of contacts and conversations, should the adversary somehow obtain access to the user's encrypted Signal backup. While we do not believe our results should be of immediate concern for users of these messaging applications, our results do suggest that more work is needed to build tools that enjoy strong E2E security guarantees.

Paper Structure

This paper contains 46 sections, 2 equations, 4 figures.

Figures (4)

  • Figure 1: Summary of the attacks discovered in this work. Here $n$ is the size of the dictionary $\altmathcal{V}$ (possible attachments or messages) and $q = \lceil \log_{16} n\rceil$.
  • Figure 2: There is one B-tree per database table. Its nodes are stored in individual pages that ultimately form the serialized file. The top-most white area is the header. Next, the blue-lined region contains the cell pointer array. The light pink dotted space is empty, and gets filled bottom-up, as shown by the solid green cells.
  • Figure 3: Experimental success probability (standard deviation of $\pm 2\%$) for the message recovery attack (Section \ref{['sec:compression-attacks']}) in our local simulation. Rows correspond to different values of $|\altmathcal{V}|$, columns to different values of $|v| \in \altmathcal{V}$, and cells the probability of success. The left sub-table corresponds to the brute-force injection strategy, and the right one to the binary injection strategy (note that these are equivalent when $|\altmathcal{V}| = 2$).
  • Figure 4: Experimental success probability (standard deviation of $\pm 2\%$) of our message-recovery attack for different target types---Social Security numbers (SSNs), credit card numbers (CCNs), and common passwords---using our brute-force injection strategy.