James Alderman, Cyber Security Consultant, Thales Cyber & Consulting
e -Fail is an attack exploiting vulnerabilities in some implementations of the PGP and S/MIME e-mail encryption protocols. In the worst case, e-Fail leaks the full plaintext content of e-mails. At a high level, the attack exploits the facts that implementations of OpenPGP and S/MIME (1) do not provide adequate integrity and authentication checking of e-mails, and (2) render HTML content within e-mails by default to display the full e-mail to the user. What this amounts to is that encrypted messages can be manipulated by an attacker to embed HTML content of their choice within the e-mail body. By embedding content that must be retrieved from a network location (e.g. by requesting an image from a remote server), the attacker creates a backdoor channel to that network location through which the contents of the e-mail can be leaked. This report gives our preliminary impressions of the e-Fail exploit, an overview of how it works and how it may affect your systems.
Despite its ubiquity, e-mail is principally a non-secured communication medium; whilst e-mail service providers may choose to apply encryption whilst transmitting e-mails, there is typically no end-to-end encryption from sender to recipient. In particular, sending an e-mail from your device to your e-mail provider, and downloading e-mails from the provider to your device, may not be protected from eavesdroppers or interfering attackers; and end-users have little protection from corrupt or malicious service providers. What this amounts to is that there is little assurance in practice that a received e- mail has not been read by a third party, or even that the e-mail came from the claimed sender and hasn’t been modified. Clearly this can be a major issue if e-mails contain sensitive information or if recipients act on incorrect information contained within a fraudulent e-mail. One particularly critical scenario is if the password reset link embedded within an e-mail can be acted on by an attacker before a legitimate user.
PGP (Pretty Good Privacy) is a suite of protocol, standardised as OpenPGP, designed to add security (e.g. encryption and authentication) to e-mails. It has been recommended for use by human rights organisations and journalists. Recently, PGP has expanded to include protection mechanisms for devices (e.g. full disk encryption for laptops), but the focus here is only on its use with e-mails.
S/MIME (Secure/Multipurpose Internet Mail Extensions) is an alternative approach to e-mail security often used in corporate environments. Whereas PGP often requires additional software, S/MIME is built in to many e-mail clients by default. S/MIME is more widely used than PGP which may mean that e-Fail has more impact for S/MIME.
e-Fail first relies on the ability of an attacker to observe e-mails protected using OpenPGP or S/MIME; traffic between e-mail servers is often encrypted using TLS, so the best avenues of attack are likely to be to intercept traffic between user devices and e-mail servers (e.g. acting as a man-in-the-middle pretending to be a valid e-mail server) or to compromise either the e-mail server or a user device.
Once an attacker has intercepted a protected e-mail, he then manipulates the encrypted message to change its contents. This appears to take advantage of inadequate integrity and authentication checks performed by e-mail clients, as well as the fact that e-mail structures and headers are well-defined and predictable based on simple guesses of the client device and software configuration. The changes to the message can be hidden within an HTML e-mail by rendering them within an invisible frame (in particular, due to the way in which the encryption chains successive encryptions of blocks, a modification to one segment of a message is likely to have knock-on effects in other areas; these unwanted modifications can be suppressed by hiding subsequent message contents).
One neat aspect of the e-Fail attack is that it can also affect old e-mails – this can either be by intercepting the e-mail as it is being re-downloaded by the e-mail server to a client or, more ingeniously, by manipulating the FROM and SUBJECT lines of the e-mail to appear to be a legitimate reply (by pre-pending “RE:” before the original subject and changing the FROM field to be one of the original recipients) which copies in the old message contents – the e-Fail attack can then be launched on this new ‘reply’ to reveal the contents of the original message.
It appears that many e-mail clients will attempt to render any HTML content within e-mails to present the full e-mail view to the user, and will also accept e-mails where content is fragmented – it will attempt to deal with each fragment and to piece them together to maintain usability for the user. What this means is that some parts of an e-mail can be encrypted and others not, and the client software will attempt to decrypt the relevant fragments and then piece them together with the unencrypted parts. (This is insecure but intentional behaviour by certain e-mail clients to accommodate systems in which decryption and e-mail rendering is performed by independent components.)
At this point, the attack becomes quite simple: modify or reply to an e-mail and embed an HTML image tag for retrieving images from an attacker controlled URL (without the closing quotation marks) before the ciphertext message that you wish to reveal, and add the closing quotation marks for the image tag to the end of that ciphertext. Now, the e-mail client will detect the presence of encrypted fragments and decrypt the original e-mail message, and then piece together the fragments resulting in a valid HTML image tag, where the URL now contains the plaintext e-mail message to be leaked. The e-mail client will attempt to render the HTML to display the e-mail to the user, during which it will attempt to retrieve the image from the specified URL. By monitoring the requests to the attacker’s website, the attacker can see which image was requested and therefore learn the leaked plaintext (which appears as the image name).
The e-Fail paper continues to develop generic backchannel techniques which would work on any e- mail client regardless of implementation, but relies on an attacker that can mount a man-in-the-middle attack, on specific weaknesses in the encryption schemes used, and on a set of assumptions regarding the e-mail contents which the authors claim are “unlikely, but not impossible” in practice. Essentially, they either rely on the original e-mail containing a HTML image tag that can be exploited by re-ordering ciphertext sections to leak certain sections of the e-mail, or they rely on knowing a certain amount of the underlying e-mail content already, which they can change bit-by-bit into exploitable content (e.g. changing known content into an HTML image tag). The latter method is likely to cause follow on errors elsewhere in the e-mail due to the way in which segments of the message are chained together in the encryption process; as discussed above, the subsequent changes can be suppressed by commenting them out or rendering them invisibly within a frame. Interestingly, the authors suggest that encryption schemes with a smaller block size are actually more difficult to exploit in this case since there is less room to embed the exploit tags and suppress subsequent errors.
The e-Fail authors provide interesting experimental data on how easy it is to exploit e-Fail (e.g. by crafting password reset e-mails) and how many e-mail clients are susceptible to the attacks. Essentially, most of the most popular e-mail clients are vulnerable to some degree but carrying out the attacks in practice may be difficult. The authors suggest that they expect that, in 40% of cases, an e- mail plaintext may be leaked using a single attack attempt, but many e-mail clients require either a man-in-the-middle or user interaction in order to carry out the exploit. 23 out of the tested 35 e-mail clients were exploitable; 3 were vulnerable to the simple image-based attack described above.
The OpenPGP standard does provide an integrity checking method (Message Modification Codes) which permit e-mail clients to detect and drop e-mails that have been maliciously modified; if available in your e-mail clients, this option should be enabled at both sender and receiver. Unfortunately, the S/MIME standard does not currently include such provisions.
The short term mitigation advice, until patches can be issued, is to avoid decrypting S/MIME or PGP emails within e-mail clients; instead, e-mails should be decrypted in a separate application which cannot open the back-door to leak the plaintext. One way to do this is simply to temporarily delete the PGP decryption keys from your e-mail client (but retain them in a backup so that they can be restored once the e-Fail vulnerability is patched).
If this is not feasible, HTML rendering of incoming emails should be disabled with e-mail clients, which should prevent the leakage channels discussed in the e-Fail paper being established; however, there may be other methods to exploit these vulnerabilities outside of HTML (e.g. checking certificate validity) which will not be mitigated by disabling HTML rendering.
Alternatively, outgoing network requests from e-mail clients could be temporarily disabled e.g. via firewall configuration (although this will affect rendering of innocent e-mails as well).
The full impact and implication of e-Fail will, no doubt, become clearer in the coming days as more details and mitigation patches are released. As always, we recommend monitoring the situation and applying authorised patches as soon as practically possible. It does appear that the initial rumours and reports were somewhat dramatic and the practical impact may be less due to the difficulty of actively exploiting e-Fail with specific e-mail clients.
Since e-Fail relies on observing protected e-mails, it may be prudent to evaluate the security of your e-mail and end-point infrastructure – as mentioned, the most likely methods to obtain such e-mails are to act as a man-in-the-middle to intercept traffic between clients and e-mail servers, or to compromise either a user device or the e-mail servers. Thus, ensuring that e-mail traffic uses an authenticated and confidential channel, and hardening both devices and servers, may help mitigation. One important aspect to keep in mind however is that, as an e-mail sender, the security of your outgoing messages relies on the security of all recipients – if any one recipient has not mitigated this vulnerability then the e-mail could be leaked.
The possibility to modify e-mail messages also has wider implications than exploiting e-Fail; for instance, it may be possible for attackers to maliciously modify attachments unless additional authentication mechanisms are applied.
For more detailed information, see the e-Fail website which also contains the paper with the full details.