In a previous post we have introduced the message takeover attacks against S/MIME. As it turns out, there exists a variant of this attack which reduces the restrictions and enhances the attacker's capabilities, compared to the original report. In particular

• basically all email clients must be assumed to be affected,
• there is not necessarily the need for Eve (the attacker) to block the original message from Alice to Bob,
• there is no necessity for Eve to attempt to pretend to be Alice in any way before Bob,
• a successful attack leads to full disclosure of the taken-over message, even the attachments,
• the required behaviour of Bob for Eve to be successful is merely that Bob replies with history to a completely unintelligible message that is signed by Eve and encrypted,
• Eve can also choose to forward the taken-over message to Alice instead of Bob for decryption.

The message takeover attack as described in the original post is an active attack in the scenario where Alice sends an email to Bob that is encrypted and signed using the S/MIME standard. The S/MIME standard allows both the encrypted-then-signed and signed-then-encrypted format. Email clients usually prepare emails in the latter format but also accept the former, if they did not accept it they would not be entirely S/MIME-compliant. The attack exploits that the encryption in S/MIME does not protect the integrity of the plaintext at all. The attacker can perform certain transformations on the CBC-ciphertext, which lead to targeted modifications of the plaintext (see the original post for the details). The goal for the attacker is to change the plaintext in such a way that the signature, which is part of the plaintext email as an attachment, is not recognized any more by the recipient's email client. The attacker then signs the email himself with an outer signature, resulting in the encrypted-then-signed format. (The application of the signature by the attacker is actually an optional step in a practical attack.) The idea of S/MIME (and other messaging formats) is that the signature protects the integrity of the message, but actually it is the other way around: the signature needs to be protected by an encryption scheme which protects the data integrity.

Eve, the attacker, sends the forged email to the original receiver, Bob, with the goal that Bob replies to her with a message including the quotation of the maliciously forwarded email, thus revealing to her its contents.

The question is now how Eve achieves that Bob replies to the email. If it was originally sent to him by Alice, then he will likely get suspicious if he receives the same message from Eve. Even if Eve managed to block the original message, she would still have to assume Alice's identity in conversations with Bob, but depending on the nature of the references to Alice's identity within the original message, and the level of familiarity between Alice and Bob, this can already become an impossible task. Eve might try and resort to complex social engineering in order to achieve her goal despite this problem. However, there exists a variant of the attack which provides the technical basis for rather simple schemes, in which Bob receives a completely unintelligible email without any apparent hint to the original message but that still contains all information from that email.

This is achieved in a rather straightforward manner. Plaintext emails today are composed by clients in the MIME format. This format tells the receiving email client where to find the different sections, the plaintext and HTML message parts as well as the attachments. It is shown in the following figure. Please ignore the red lines for now.

When an email client receives an intact MIME message, it will display either the text/plain or text/html part of the message, according to the configuration, recognize the attachments embedded into the MIME, and specifically interpret the application/pkcs7-signature attachment as an S/MIME signature. However, removal or modification of only the first MIME header causes the client not to interpret the message in the MIME format, but to simply display the plain contents including all formatting tags and the attachment (base-64 encoded when binary) in the message window.

The attacker in the message takeover attacks can make us of this behaviour to achieve four goals at once:

• cause the recipient's client not to detect the original S/MIME signature from Alice,
• remove all visible traces of the original message,
• have the attachments from the original email in Bob's "reply-with-history" message, which is normally not the case,
• have an unintelligible email being displayed to Bob, which Eve claims to result from some error, for instance during the encryption or decryption, and thus has troubleshooting as a convincing argument for the request of the received message.

She reaches this simply by removing a sufficient number of CBC blocks from the beginning of the ciphertext contained in the S/MIME email. This results in the plaintext being "beheaded", the red lines in the above figure indicate the removed parts. To be safe, she will tend to overestimate the length of the text parts, and thus will likely also remove the start of the first attachment. However, the properties of the CBC mode allow her to place the cut-out ciphertext again somewhere in the middle of the lengthy message, where it is decrypted correctly but Bob will not spot it, so that she does not loose any information from the original message when Bob replies. In the following we point out how it is possible to even further obscure the original message parts for Bob.

Bob will for instance first receive a signed email from Eve in which she announces a further encrypted (and signed) email, which allegedly contains sensitive documents he needs to review. The second email, that he receives from Eve, shown to him as signed and encrypted, might be displayed to him like this:

H/2wBDAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR
CAA1ASwDASIAAhEBAxEB/8QAHwABAAIDAAMBAQEAAAAAAAAAAAgJBgcKAgQFAQML/8QAPRAA
AQQCAQICBwcDAwIHAQAABQMEBgcCCAEACRmXFRpVV1jW1xESExQWltRUlNMKITEXMiInNlF2
kbXR/8QAGwEBAAIDAQEAAAAAAAAAAAAAAAYHAQUICQT/xAA7EQAAAgUJBgQFAgcAAAAAAAAA
AQIDBAUGBxdRVVZhlJWxERITGNTVFBbS0yFXcZbWFfAIMTIzZWah/9oADAMBAAIRAxEAPwDp
DU/09Ha4UzzU5pubcc555Z88f9Z7Qy+znLLnLn/xKSXNTL/fn/uzzzz5/wCcsssueeefD1eb
tce5ybectm/MfXMbyTJZc85ZEH2WWXPPPPPLtxzzzzzz9vPPPPKnPPPPPPP28889fnpIj/Xv
f7pf/J12zycJ/MRD7TO7/ZPr/wAp+FKTxFZ082Lto6c/V5u1x7nJt5y2b8x9PV5u1x7nJt5y
2b8x9cxnpIj/AF73+6X/AMnT0kR/r3v90v8A5Os8nCfzEQ+0z/JPr+z+CeIrOnmxdtHTn6vN
2uPc5NvOWzfmPp6vN2uPc5NvOWzfmPrmM9JEf697/dL/AOTp6SI/173+6X/ydOThP5iIfaZ/
kn1/Z/BPEVnTzYu2jpz9Xm7XHucm3nLZvzH09Xm7XHucm3nLZvzH1zGekiP9e9/ul/8AJ09J
Ef697/dL/wCTpycJ/MRD7TP8k+v7P4J4is6ebF20dOfq83a49zk285bN+Y+nq83a49zk285b
N+Y+uYz0kR/r3v8AdL/5Or7exM6dOJrsZwu5XWx4i9dc8YqrKKccZelpXxxlxxnlzxxzxxzl
x9v/ADxxzz9nP+/PHUMlB/hmTgSD31Fhxoi9CdCtkWGwFDpsRtHingyMOzxX6418Lh+K4u3w
6ze4e5sR399Hcw/KWT9fDG6icpsvi0lqPH/UePw+EoWr9vC8Cq3t7hbv9xHZvbdp7N05Derz
drj3OTbzls35j6erzdrj3OTbzls35j6jPuttLuXtT3MkO1tqBcfOrkbgcRYSm7brFikCszc4
EoUCn71cIr+cZE0hwULK4kEChY0UipYrLSRVQ9KG0fQQzG5LCNVe7rrjujp+Af7j2ht7qJ+r
ZYXs2RGGomJE4umpFCjMgFtZmWkUkkEwjz1vkPcwVy5lkjaNJOg9zZAIscwDvDfLAtIbz9Xm
7XHucm3nLZvzH09Xm7XHucm3nLZvzH1Dvup3H3DNVO4Hqw9192MeTqLbZTjGN1fq1IAoeLVz
HT8PYVXCco7LpRi/yfSeOzqYTZWUlSH4sUJiGyzoS2I/agxLITB100k7qVdbUQe6ru7jrW4a
xKxiRq3LVSUaLBo23lBiOlWQqPVtB82ysJwAxySOA5xjOUG0APrpCMh7yILMiJBs5APP1ebt
ce5ybectm/MfT1ebtce5ybectm/MfUCtXJrvrWHdCunT7azuHy3ILB6Gsaxa+ksmr+HJQ62Q

If he replies, he discloses the contents of a signed and encrypted email which was sent to him by Alice.

The conditions for this attack to work are only that the recipient's client accepts the encrypt-then-sign format as mandated by the S/MIME specification and displays non-MIME messages – both is what one would normally presume. Experiments showed that at least two major email clients enable this type of attack.

If the attacker is concerned with with further hiding the original plaintext in the message displayed to Bob, he can resort to the ideas given by Katz and Schneier. Note that they basically already describe the possibility of such attacks, with the only exception that they assumed signed messages to be safe.

Furthermore, Eve can also send the email to Alice using the same scheme, since an outgoing email is usually also encrypted under the sender's key.

The only reliable countermeasure at this point seems to be to use a client which does not accept the encrypt-then-sign format together with a strict policy of rejecting unsigned encrypted emails. The latter was already necessary before the revelation of these new attacks, but now becomes even more important, since even with the first countermeasure in place, an attacker could still downgrade signed emails from Alice to unsigned ones and perform the attack.