Changes from v1 to v2: message takeover attacks against S/MIME

Changes in the markdown source of the article: ~~removed text~~, added text.

---
title: "message takeover attacks against S/MIME"
type: blog
author: Falko Strenzke
date: 2016-01-19
---

**[Update: see ### Updates

**2016-02-03: [see this new post for details of an improved attack
variant](blogpost__smime_mta_improved_en.html)**
**2022-05-22: Added the link to the [vulnerability regarding Thunderbird
71.0](https://bugzilla.mozilla.org/show_bug.cgi?id=1240290) in the section "practical
attacks"**

## abstract

We point out a newly discovered flaw in the S/MIME specification, which forms the basis for
the secure exchange of emails based on X.509 certificates and is implemented by all major
email clients. Specifically, we show that the claim of S/MIME to reach message integrity
through signatures is not reached. The result is that an attacker may perform what we refer
to as a "message takeover attack". In its simplest form, it leads to the disclosure of the
content of a signed and encrypted message. With the cryptographic layer being broken, the
concrete exploitability depends on the strictness of an S/MIME conforming client's MIME
parsing.

## message takeover attacks at a glance

This section explains the concept of the message takeover attacks against S/MIME very
briefly. For those readers familiar with all the involved technologies this might already be
sufficient information in order to understand the principle, for all others it serves as a
reference to come back to after having read the remainder of this post.

The following figure shows the procedure of the message takeover attack.

The setting is that Alice wants to send a signed and encrypted email with secret content to
Bob using S/MIME. As it is the common standard today, her email client produces the email in
the signed-then-encrypted format. Eve, the attacker, blocks the original email from Alice to
Bob (1). She captures the message, and removes the signature within the encrypted message
which is possible due to the missing integrity protection of the S/MIME encryption (3). Then
she applies an outer signature on the message (4) using her own certificate, which results
in the also valid encrypted-then-signed S/MIME format. She sends this email to Bob (5), who
replies to it with the message history (6), and Eve learns the secret content of the email.

## naive sign & encrypt in S/MIME

S/MIME, building on the CMS standard, relies on what is referred to as "naive sign &
encrypt", meaning that messages are protected by a combination of digital signature and
encryption, based on public-key certificates. Here, S/MIME is especially flexible, in that
it allows any order and any nesting of signature and encryption.

Fifteen years ago, Don Davis has already
[summarized](http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html) a number of
shortcomings in S/MIME and other standards that rely on naive sign & encrypt. One point of
critique was that S/MIME messages that are encrypted-then-signed, are vulnerable to a
trivial form of message takeover attacks. Here, Alice sends an encrypted-then-signed message
to Bob, Eve blocks the message, removes the outer signature, replaces it with her own
signature and forwards it to Bob.

In this way, even in the setting where Bob only accepts signed emails, Eve is capable to
inject messages to him as originating from her which were originally authored, signed, and
encrypted by Alice. This potentially leads to a number of practical attacks, however, here
we only point out that if Bob replies to the message, i.e. to Eve’s email account, with the
message history, possibly in an encrypted email, Eve learns the contents of the message from
Alice to Bob. Bob might also disclose other information based on the believed legitimation
of Eve which he might conclude from her allegedly displayed knowledge in the forged email.

As a consequence, today's email clients usually produce messages only in the
sign-then-encrypt format, probably in the believe that this solves the problem. In the
following we learn that this is not the case. First, however, we look in some more detail
into how S/MIME realizes encryption.

## unauthenticated encryption in S/MIME

The encryption in S/MIME is done using a block cipher, i.e. 3DES or AES, in CBC mode. This
is a bad decision since this scheme does not at all protect the integrity of the ciphertext.
As we see in the following, very targeted manipulations are possible on CBC ciphertexts. At
the time of writing of the early versions of the S/MIME specification, the necessity of
integrity protection of encrypted messages was not known, however, in the meantime, since
about the year 2000, it became known that for the protection against certain active attacks,
encryption schemes need this feature in order to achieve confidentiality of the messages in
real world scenarios. This is for instance achieved by using what is referred to as
authenticated encryption.

However, the S/MIME standard, even in its latest version from 2010, ignores this
development. Instead, it explicitly states "It is important to note that sending enveloped
but not signed messages does not provide for data integrity." As we learn today, this is a
wrong claim. But even without the knowledge of the non-trivial message takeover attacks
against sign-then-encrypt, which are introduced in the following, it is also a mistake to
rely on signatures for the message integrity. The reason is that it unnecessarily reduces
the usability of the scheme, since thereby even an entity that merely wishes to send
integrity protected encrypted messages needs a certificate that is recognized by the
recipient.

## manipulations on CBC ciphertexts

The symmetric encryption that is used by S/MIME capable email clients is generally a block
cipher in CBC-mode, typically triple-DES, thus having a block size of 8 bytes, together with
PKCS#7 padding. The latter means that the final block is filled up with one or more padding
bytes, the value of each of which is the equal to the number of padding bytes. In the
cryptographic layer, the only possibility to achieve an invalid ciphertext would be an
invalid padding in the final block. The CBC-decryption is given by the definition

pi = D(ci ) xor ci-1,

where the pi and ci , i ∈ {1 ,..., n} are the sequences of plaintext
and ciphertext blocks, respectively, D(x) is the block cipher decryption, and c0
is the initialization vector (IV). Accordingly, the following manipulations of
CBC-ciphertexts are possible:

1. Any number of leading blocks can be removed without any effect on the decryption result
of the remaining blocks. The IV of the message is updated to the last removed block.
2. Any part of the message can be freely moved to any position in the ciphertext in
portions of full blocks. At any such seam resulting from the moving of a sequence of
blocks, the first block of the appended sequence will decrypt to some pseudorandom
content, the remaining blocks of the appended sequence will decrypt to their original
plaintext.
3. Bit flips can be introduced in arbitrary blocks in pi by applying the
corresponding bit flips to ci-1 . As a side-effect, the content of
pi-1 will be pseudorandom. Together with partially known plaintext, this
allows an attacker to create a block of fully controlled content. Introducing bit flips
in the first message block p1 does not lead to any pseudorandom plaintext
block.
4. The padding block can be kept intact by keeping the last two blocks of the ciphertext in
that position.

## message takeover attacks against signed-then-encrypted messages

As we have noted above, the trivial message takeover attacks only work against the
encrypt-then-sign message format, and are mitigated today by clients composing messages in
the sign-then-encrypt format. The new result presented here is the possibility of message
takeover attacks against signed-then-encrypted messages. They are carried out as follows. In
the setting where Alice is going to send a signed-then-encrypted email to Bob, Eve, the
attacker, first contacts Alice in order to receive a signed and encrypted email from her. In
this way, Eve learns the exact message format used by Alice. Note that the signature is
usually contained in the MIME message of type "multipart/signed" as an attachment.
Furthermore, Eve knows what email client is used by Bob. She now determines what
manipulations she needs to perform on the ciphertext in order for Bob's email client to not
recognize the signature any more. This could involve modifications such as simply stripping
off the signature attachment, which is usually at the end of the message. Furthermore, she
can block-wise move any part of the message to the beginning. She can render any formatting
tags invalid through bit flips. Some of these modifications demand to know the length of the
individual message parts in the actual attack. Note that in the case that an email contains
only the usual text/plain, text/html and signature parts, with the length of the latter
known, the length of the other two parts might be deducible from the overall length quite
accurately.

Once Eve has determined the necessary modifications, she is ready for the actual attack. She
blocks the signed-then-encrypted message from Alice to Bob and performs the modifications on
the ciphertext as determined in the previous step. She then applies an outer signature to
the ciphertext with her own key and forwards the message to Bob. As described for the
trivial message takeover attacks above, Bob will now presume that Eve authored the message
and potentially reply to it and thus disclose secret information.

It is up to Eve to decide whether she keeps intact the text of the message or whether she
introduces modifications before signing it. To achieve targeted modifications, a certain
amount of known plaintext will be necessary. Note that she might even be interested in
corrupting the message in part, in order to provoke a reply with history from Bob to a
message which does not suggest a reply otherwise.

## practical attacks

We tested the attack as described above against a few clients and found a vulnerable
client which displayed that [Thunderbird
71.0 is vulnerable](https://bugzilla.mozilla.org/show_bug.cgi?id=1240290) to it as it
displays the forged message as validly signed by Eve. Details of the attack and the identity
of the vulnerable client will be disclosed in an upcoming research paper. However, basically
all clients will be susceptible to ciphertext modifications that result in the inner
signature not being recognized any more.

## applicability of the attack and social context

The above concludes the overview of the technical aspects of the attack. What remains is to
understand under which conditions this type of attack is applicable. If Alice and Bob have
not been in contact before, it is easy for Eve to assume the identity of Alice before Bob.
In a realistic scenario Bob could be a journalist or a lawyer, and Alice an informer or a
new client who initially contacts Bob via an email which already contains confidential
information.

However, even if Alice and Bob have been in contact before, the attack is still feasible, as
Eve might for instance not even pretend to be Alice but just claim to be an intimate contact
of her and seemingly proving so by forwarding information to Bob via the message takeover
attack. Furthermore, if trying to assume Alice's identity, Eve might choose an email address
closely resembling that of Alice or pretend that it is a different address of Alice. She can
devise any conceivable social scheme by preceding the taken-over message by messages of her
own, with the taken-over message functioning as the convincing proof of her claims to Bob.

From this variety of attack possibilities we conclude that the general use of S/MIME
conforming clients is insecure. The remaining security assurance of S/MIME is that if Bob
knowns the signer of the message to be trustworthy in the sense of not being malicious (and
does not err in that), then he can be sure that the message was authored by that person and
may reply to it without the risk of disclosing confidential information. In all other cases,
this is not guaranteed.

## mitigation of message takeover attacks

The fundamental flaw leading to the attacks is within the S/MIME standard. The CBC
ciphertext fails to reliably protect the signature and thus the concept of integrity
protection through the signature collapses. The best repair would be to allow for the use of
authenticated encryption, which is already specified in
[CMS](https://tools.ietf.org/html/rfc5083) and would lead to the detection of all
modifications on the ciphertext. The message encrypted in this way should also contain a
field with the sender address, which is verified by the recipient. This would also solve the
usability problem pointed out above, in that integrity protection of encrypted messages
would be independent of the existence of a signature and any type of malicious forwarding
would be prevented. Since such a repair of the specification, not to speak of its widespread
adoption in clients, will unlikely be available any time soon, we look at two other options.
It is quite likely that some clients already implement them unintentionally and achieve
protection at least against straightforward forms of the message takeover attack.

**restricting the S/MIME format**

One option is for the receiving client to consider only messages with inner signatures as
validly signed. This a is valid countermeasure, since the attacker is incapable of producing
signatures of unknown message content (if the content is known to him completely then he can
simply forge the message from scratch). This solution cannot be backward compatible to the
current S/MIME specification as there mere outer signatures are also considered valid.
However, since to our knowledge basically all clients already produce emails in the proposed
format, this incompatibility would probably hardly be relevant.

Note that already the possibility for Eve to only strip off signatures without the
possibility of generating new ones is a drawback. With the countermeasure proposed here,
this cannot be prevented. Accordingly, the countermeasure from the next section should be
implemented in any case.

**mitigation on the application layer: stricter MIME-parsing**

In the previous section we discussed a measure necessary to achieve security on the
cryptographic layer, which is the only sound solution. However, as that measure breaks
compatibility with the current S/MIME specification, here we propose a mitigation on the
application layer which retains compatibility to the S/MIME specification. Furthermore,
these countermeasures also offer protection against attacks where Eve only strips off
signatures and modifies the encrypted message without applying her own signature.

Before we come to the discussion of these measures, we wish to point out why mitigation on
the application layer can never reliably compensate a broken cryptographic layer. First of
all, application processing is generally far too complex to allow for systematic or formal
security analysis, and thus the trust in the effect of such measures can never be as high as
that in a sound cryptographic solution. Furthermore, application processing is subject to
varying requirements, and thus the additional security mechanisms must be feared to be
rather unstable from version to version. Another problem is that such mitigating measures
will hardly find a suitable place in any specification. Since they are out of the scope of
S/MIME, they cannot be included there, and since it is not the task of the MIME processing
to enforce security goals of S/MIME, this is also not the right place.

Now we turn to the measures that should be implemented by clients functioning on the basis
of the broken S/MIME specification when parsing the MIME content of an encrypted email:

1. Parsing should be as strict as possible. Any inconsistencies, like the lack of an inner
signature in a mail that is headed by "Content-Type: multipart/signed", irregular
boundary tags etc., should lead to the display of an invalid signature. The presence of
a signature part ("Content-Type: application/pkcs7-signature") in the message should
always lead to the interpretation of this as the message carrying an inner signature,
even when it is not expected from the previous context, and also here any
inconsistencies in the MIME message should lead to the signature shown as invalid.
**\[Update: With the [new attack variant](blogpost__smime_mta_improved_en.html), this
countermeasure is further complicated.\]**
2. The presence of invalid character codes should also lead to invalid signatures.
3. Furthermore, when the above measures detect an irregular MIME message, also the
encryption result should be indicated as potentially manipulated.
4. It should also be considered not to display the contents of a message with such an
irregular MIME structure at all, in order to prevent the user from disclosing
information by replying to the message, or at least warn him when he attempts to do so.

It should be unnecessary to say that it is not possible to have any guarantee that
implementation of these measures achieves reliable defence against attacks. However, the
most straightforward attacks, i.e. the cutting off of the signature attachment will not
function in that simple form any more.

## how could this happen?

"how could this happen?" – this was already asked by Davis in the view of his summary of
known problems in S/MIME and other specifications relying on naive sign & encrypt fifteen
years ago. Unfortunately, no improvements were made to the S/MIME specification since then.
The main reason seems to be that the issue of "surreptitious forwarding", which is possible
with sign-then-encrypt was considered out of scope of the protection goals (which is a valid
point of view in our opinion), and that the trivial message takeover attacks are only
possible with encrypt-then-sign, and consequently each client can choose the former secure
option when composing messages.

The following is the complete security analysis of the problem of the order of the two
operations offered by the S/MIME specification: ["There are security ramifications to
choosing whether to sign first or to encrypt first. A recipient of a message that is
encrypted and then signed can validate that the encrypted block was unaltered, but cannot
determine any relationship between the signer and the unencrypted contents of the message. A
recipient of a message that is signed-then-encrypted can assume that the signed message
itself has not been altered, but that a careful attacker may have changed the
unauthenticated portion of the encrypted message."](https://tools.ietf.org/html/rfc5751) We
are not even going to try and understand which trade-off is exactly attempted to be conveyed
here. We simply note that effectively both statements about the achieved integrity of the
message are wrong: with encrypt-then-sign, the signature can have been applied after the
manipulation of the original ciphertext, and thus the "encrypted block" can very well have
been altered. With sign-then-encrypt, we could indeed achieve integrity, but this is only in
effect if the receiving client rejects encrypted-then-signed messages, which he is forbidden
to do so by the S/MIME standard, as he is demanded to accept outer signatures as well, and
furthermore rejects unsigned encrypted messages. Consequently, the last option for a
conforming client would be to signal to the user the exact message format, who then has to
decide what trust he places into the message. The latter is certainly an impossibility from
a realistic point of view and only defers the decision of what is an acceptable message
format and what is not.

The S/MIME specification enables a thicket of possibilities for senders to create messages,
demands from the recipient generic processing of any such format, and devotes eight lines of
text to the resulting "ramifications", shown to be wrong and ignoring the question in what
way the receiving clients must commit to a specific message format and how they can remain
compatible to the specification when doing so.

Of course there is still the "escape" for the S/MIME specification to be understood as
implying a different meaning of integrity, namely one which only refers to the integrity of
signed contents and not the contents as they were encrypted. However, in this case, first of
all, this notion could not be differentiated from the notion of authenticity, and second, it
would mean that the possibility of message takeover attacks is knowingly taken into account.

By now it should be needless to elaborate that a specification of a cryptographic message
format does not benefit from such a great freedom in the order and nesting of operations. It
burdens implementers with difficult decisions and, more importantly, it leads to complex
security implications, which are, in the case of the S/MIME specification, not even
rudimentarily addressed and flaws have obviously been overlooked.

## overview of the attack family

The following diagram gives an overview of the different types of attacks that S/MIME
messages are vulnerable to.

The main new insight is the possibility of message takeover attacks. The other attacks were
more or less [long known to be possible with
S/MIME](https://www.schneier.com/cryptography/paperfiles/paper-chotext.pdf). The possibility
of content manipulation of unsigned messages is even explicitly pointed out by the S/MIME
specification. The application of a signature by the attacker to a message which was
previously unsigned, which we refer to as the "apply signature attack", is trivial. The same
applies to what we label "unsigned forwarding attack", i.e. the forwarding of potentially
manipulated encrypted emails with a different sender address. The baseline is that S/MIME
does not attempt to reach any other security goal than confidentiality for merely encrypted
messages. However, as we pointed out, this does impair usability and consequently security
considerably and thus we cover these issues in our overview as well. The new aspect to the
content manipulation and unsigned forwarding attack is that they can also be applied if the
sender signed his email.

The figure shows two entry points of the graph: signed-then-encrypted messages, with the
subsequent process flow indicated by red arrows, and only encrypted messages, with
processing indicated by orange arrows, from Alice (A) to Bob (B). The graph has four
different exit points, i.e. types of forged emails that Eve sends to Bob.

The general processing flow in the attacks is as follows. With the possibility of Eve (E),
the attacker, to remove inner signatures, she gets into the same position as an attacker who
performs the forgery on merely encrypted messages. The next step is the potential
modification of the content. By signing the resulting email, in case the original email was
also signed, the message takeover attack is realized, otherwise the apply signature attack
is realized. If the message remains unsigned, Eve may choose to forward it to Bob in her own
name or retain Alice as the sender. The latter certainly usually only makes sense if she
modified the content, otherwise she would forward an unmodified email (potentially just
stripped off its signature). This results in the unsigned forwarding and content
manipulation attacks, respectively.

The figure also shows the countermeasures and which steps in the attack process they
prevent. The ad-hoc defence of strict MIME parsing may succeed in preventing the effective
removal of inner signatures. The ideal countermeasure is the use of authenticated encryption
(AE), in conjunction with the authenticated sender address in the ciphertext which is
matched to the actual sender address. Without this additional measure, for unsigned
messages, authenticated encryption only prevents those attacks where ciphertexts are
manipulated, but not those where unmodified encrypted messages are forwarded by a malicious
sender hoping for a reply that discloses secret information. Insisting on inner signatures,
i.e. not accepting outer signatures, also prevents those attacks where the attacker applies
his own signature.

## comparison of S/MIME with OpenPGP

It is certainly an interesting question to compare the situation of S/MIME with that of
OpenPGP which also implements naive sign & encrypt. As OpenPGP plugins exist for many email
clients, it is a possible alternative for secure email exchange. However, at least when we
talk about large institutions the interchangeability between both schemes is not given.
While S/MIME builds on public-key infrastructures, OpenPGP relies on direct trust, which
demands a very different trust management scheme that does not scale with the number of
users. But for small-scale users OpenPGP can certainly be an alternative to S/MIME.

The main differences between OpenPGP and S/MIME for our purposes are:

1. OpenPGP implements optional integrity protection of encrypted messages, but it does so
in a faulty way which allows an attacker to downgrade messages to mere encryption
without integrity protection ([SEIP downgrade
attack](http://www.metzdowd.com/pipermail/cryptography/2015-October/026685.html)).
Furthermore, it is reported that also here the signature can be stripped off.
2. OpenPGP does only allow sign-then-encrypt.

From this we understand that message takeover attacks are not possible against OpenPGP,
since the attacker is not able to sign the encrypted messages. Accordingly, contrary to
S/MIME, OpenPGP offers the advantage that when receiving a signed and encrypted email one
may always be certain that the signer authored the message, and can make no mistake when
replying with history.

## conclusion

The message takeover attacks bring users of S/MIME into a problematic situation. These
attacks easily lead to information disclosure and are applicable in the strongest
conceivable setting, i.e. when the sender produces the signed-then-encrypted format and the
recipient only accepts signed and encrypted emails. This is the only setting in which S/MIME
was so far believed to achieve reasonable security goals. How many users were aware of this
restriction is another question pointing us to the impaired usability of S/MIME which
deserves repair since a long time. The detailed look at S/MIME reveals it to be a sort of
dinosaur, which survived despite its lack of support for modern state-of-the-art
cryptography and took on a major role in our communication security architecture.

It is now up to vendors of email clients to come up with effective countermeasures for users
to be able put sufficient trust into S/MIME protected emails. As has been discussed above,
this is not a simple task. However, giving up S/MIME compliance in part and refusing outer
signatures is at least a reliable means to repair trust in the strongest setting where the
recipient insists on signatures and the sender applies them.

Furthermore, these results also potentially threaten other schemes built on naive sign &
encrypt, like PKCS#7 and CMS. Since these are generic formats they must be assumed to be
used in a large number of proprietary applications. The direct threat of information
disclosure like in an email client through the reply-with-history feature will usually not
be applicable to systems which process messages in an automated way, but they may very well
be affected in other ways.

Blog

Changes from v1 to v2: message takeover attacks against S/MIME

Versions