ECB Malleability

Why is malleability a problem?

Malleability is another problem with ECB mode. A cryptosystem that’s malleable is one that allows for an attacker to take parts of one or more encrypted messages and combine them to forge a new message.

Remember that each block of the plaintext is encrypted completely independently, and each block of ciphertext is decrypted completely independently.

Editing encrypted data is made possible

So let’s say we have an application that maintains a list of admin accounts, followed by the delimiter “Banned user list,” followed by a list of banned users. And for security purposes, let’s suppose that it was decided to encrypt this list on disk using AES-ECB. If the legitimate plaintext was this:

admin1@bigco.com
admin2@bigco.com
intern@bigco.com
Banned user list
notnice@abcd.com
mean@website.com

Suppose this encrypts to this:

00000000: 6e42 96b1 47ae 6963 0e26 7cc8 883e 1074  nB..G.ic.&|..>.t
00000010: 57ee 68e0 48d4 f5d7 a463 9fd7 394a 5a72  W.h.H....c..9JZr
00000020: 2d01 60eb 9e76 919e 46e1 eede b015 f657  -.`..v..F......W
00000030: 7610 6ab4 8c4d 2fad 3390 c051 4fa7 0964  v.j..M/.3..QO..d
00000040: e9c1 300c da3d 9d8f df70 4779 c8f0 e413  ..0..=...pGy....
00000050: d2a8 ac73 14b4 1d8a 86a7 0f77 c38a b4db  ...s.......w....

An attacker can just rearrange the blocks so that the last two blocks are first, followed by the delimiter, and then finally the legitimate admins. It will decrypt this just fine. This will put the banned users in the admin list and ban all the legitimate admins! From this example, we can see that, depending on the structure of the plaintext, many kinds of edits are possible—including repeating, deleting, and reordering blocks—without knowing the key.

This may seem contrived. What about block boundaries? The attack in this example works because the delimiter and the email addresses were aligned on block boundaries. Yes, the specific email addresses were contrived to work in a quick example. But the principle still holds.

In the general case, it may take a bit more effort to rearrange the blocks so that it decrypts correctly. The attacker is aided by the fact that many file formats allow for a fair amount of malleability in the form of things like comments, whitespace, and no-ops, so it’s often possible. But nothing in AES-ECB prevents it.

Encrypted cookies can be used

Let’s consider a second scenario. Consider a naive web application with a complex permissions model. For performance reasons, the developers have decided not to query the database for permissions on every request to this web application. Instead, at login time, and every time permissions change for a given user, the application issues a cookie whose value is an encrypted list of all the permissions that the user is granted. If this value were encrypted with ECB, a malicious user could learn about the structure of the web application and slice together pieces of several cookies they may have been issued over time and construct a new cookie for themselves that grants them administrative privileges.

The previous chapter listed several ways an attacker could learn more about the structure of the cookie’s value. Even without access to the source code, an attacker could start to learn about the structure of the cookie without any access to the source. An attacker could create multiple users and compare their cookies. An attacker could possibly change metadata about their account through the application and observe the change in the cookie.

                                                 Q U I Z