No-Key Symmetric Injections
Symmetric algorithms are often used for encrypting embedded and mobile firmware images in order to protect code and data confidentiality, AES-CBC being a typical choice.
Firmware files are usually also fully signed, but, in our experience, we met cases where encryption of some regions was the only security measure, relying only on the confidentiality of the key itself.
The lack of integrity protections, that is sometimes regarded as a minor issue in case the encryption key is maintained secret (e.g.: in hardware), may leave open some attack paths that, in some very specific cases, allow an attacker to introduce modification in selectively targeted plaintext regions.
These ideas, even if not necessarily new or applicable in a wide range of cases, are, nonetheless, here presented with the intent of stressing the need for proper integrity protection, even if the encryption key is considered secret.
Scenarios are presented for CBC mode of a generic symmetric encryption algorithm, but they may be applicable also to other modes.
Let’s consider the generic case of a ‘symmetric’-CBC encrypted firmware region, putting aside specific considerations (eg: IV, key size, rekeying..), decryption will occur in the following way:
Fig 1 – CBC decryption
Each plaintext block P(n+1) is a function f(C(n+1),C(n), K), of the encrypted blocks C(n+1) via the block cipher decryption and of C(n) via the XOR operation.
The effect of a bit flipping, occurring in the block C(n), upon the corresponding plaintext can be seen in the following image:
Fig 2 – CBC encryption
Any bit flipped in C(n), will generate a P'(n) (‘garbage block’) completely different from P(n) and a P'(n+1) (‘flip block’) that has only a single bit different from P(n+1), exactly in the same position of the bit flipped in C(n).
It worths noticing also that the ‘locality’ of cyphertext modifications is preserved by the decryption process, only 2 plaintext blocks are changed, while the remaining blocks remains unchanged.
Attacks Discussion
A few ideas will be thrown in the following, proposing some scenarios where an attacker may exploits the possibility to modify the plaintext, without knowing the encryption key but just by manipulating cyphertext blocks.
Some assumptions have to be made that will hold valid throughout the whole discussion. We suppose that the attacker:
- has knowledge of the firmware files inner structures
- does not know the encryption key and is not able to retrieve it
- is able to modify the cyphertext only, and the interested area is not subjected to integrity protection.
Assumption 1 may be often valid for an attacker, at least for some small region inside the firmware. (e.g.: attacker could have had access to the plaintext of previous versions firmware images, or has been able the obtain a plaintext image from memory dumps)
Assumption 2 is the normal starting condition for an attacker
Assumption 3 is needed for this discussion but it may not be verified for well designed security.
Data Attacks
For attacks aimed at data, we use a small binary that has been been adapted from a real firmware, that is here displayed in cleartext
Fig 3 – Example plaintext
and encrypted with key: 0x0123456789abcdef, IV = NULL
Fig 4 – Example cyphertext
For convenience of discussion, the term BLOCKSIZE will refer to the symmetric cypher block size (eg: AES 128 bits).
1) Using garbage block P'(n)
An attacker may carefully choose C'(n) so that the ‘garbage block’ P'(n) is generated in specific location in the firmware.
Content of P'(n) block is not under attacker control, so targeting code segments in the firmware file will likely generated unpredictable behavior at runtime.
Targeting data segments may prove more useful, depending on the data size, its location, and on the code constructs that use that data at runtime.
The effect of this simple attack is visible in this example, where a version number, starting at 0x28, is the attack target.
A single bit changed in the cyphertext, at 0x2b…
Fig 5 – Garbage block insertion: cyphertext
produces the modification of the whole corresponding block, introducing a random value. (Note the effect of the single bit flipping also)
Fig 6 – Garbage block insertion: plaintext
From a practical point of view, garbage blocks may be used for changing data in way that affect code flow, for example, hitting the default case in a switch statement (fictitious example):
switch(garbled_data) { case '0': state = PRODUCTION; break; case '1': state = CUSTOMIZATION; break; . . default: state = FACTORY; break } |
This may happen if developer assumed that garbled_data field contain only values of a specific subset, and has not foreseen the possibility of handling unpredicted values.
In any case attacker has to take into account that injected garbage will be BLOCKSIZE large, so additional data may be affected by the introduced modifications, if falling within a block_size range from the target data.
Modifications introduced by the bit flipped into P'(n) should be also taken into account.
2) Using flip block P'(n+1): data regions
In firmware images, it may be possible to find data regions preceded by empty or unused data chunks, that, if changed, do not affect the normal device operations.
Let’s consider such a TARGET data region, preceded by an UNUSED data region that is at least BLOCKSIZE large.
In the example, the TARGET region starts at 0x40 (selected), that and holds 0x10 bytes of interesting data, that are a MD5 hash.
The TARGET region is preceded by an UNUSED region that is 0x10 bytes long as well (selected in blue), that is not used by any part in the code that deals with this firmware area
Fig 7- Flip block attack: selected regions
In a general situation, depending on the blocks alignment, up to a number of BLOCKSIZE bits in TARGET can be flipped at will by the attacker, where all the modifiable bits are located within a BLOCKSIZE distance from TARGET start.
If the attacker is able to identify a C'(n) that:
- accommodates entirely into UNUSED
- the following block C'(n+1) overlaps the desired bits in TARGET
by flipping the correct bits in C'(n) is able to change the value of the desired bits in the ‘flip block’ P'(n+1) at will, including those present in the TARGET region.
In the example we changed the bits of encrypted blocks corresponding to the UNUSED region (our C'(n))
Fig 8 – Flip block insertion: cypher
so that the bits in the plaintext TARGET are modified as desired.
The hash first half has been modified to hold the 0xFEEDBABE word twice.
Fig 9 – Flip block insertion: clear
The ‘garbage block’ will not affect the normal device operations, because is fully contained in UNUSED region.