OpenPGP signature spoofing using HTML

Beyond just encrypting messages, and thus providing secrecy, the OpenPGP standard also enables digitally signing messages to authenticate the sender. Email applications and plugins usually verify these signatures automatically and will show whether an email contains a valid signature. However, with a surprisingly simple attack, it's often possible to fool users by faking — or spoofing — the indication of a valid signature using HTML email.

For example, until version 2.0.7, the Enigmail plugin for Mozilla Thunderbird displayed a correct and fully trusted signature as a green bar above the actual mail content. The problem: when HTML mails are enabled this part of the user interface can be fully controlled by the mail sender. Below is an image of real signed message in Enigmail:

The signature below has been faked:

Thus an attacker can simply fake a signature by crafting an HTML mail that will display the green bar. This can, for example, be done by using a screen shot of a valid signature and embedding it as an image. The attack isn't perfect: in addition to the green bar, Enigmail shows an icon of a sealed letter in the header part of the mail. That part can't be faked. However the green bar is the much more visible indicator. It's plausible to assume that many users would fall for such a fake.

After learning about this attack, the Enigmail developers changed the behavior in version 2.0.8, which was released in August. Enigmail now displays the security indicator above the mail headers and thus outside of an attacker's control.

Perfect fakes

An even better fake can be achieved in the KDE application KMail. Signed mail in KMail is framed with a green bar above and below the mail. This can easily be recreated with an HTML table. If the message is viewed in a separate window, the fake is indistinguishable from a proper signature. Only a look into the message overview can uncover the fake: an icon indicates a signed mail.

Similar attacks are possible in other mail clients, too. In GNOME's Evolution, a green bar is displayed below the mail, but a faked signature has some minor display issues due to a border drawn around the mail content. A plugin for the web-mail client, Roundcube, is similarly vulnerable. In many cases, signatures using S/MIME are also vulnerable.

The examples mentioned all rely on HTML mail to fake signature indicators. HTML mail is often seen as a security risk, which was particularly highlighted by the EFAIL attack that was published by a research team earlier this year. EFAIL relied largely on HTML mail as a way to exfiltrate decrypted message content. Security-conscious users often disable the display of HTML mail, but all of the mail clients mentioned have the automatic display of HTML messages enabled by default.

In the GPGTools plugin for Apple Mail, this kind of attack was not possible using the same technique. The indication of a valid signature is displayed as a pseudo-header. A correctly signed mail contains a header indicating "Security: Signed" below the "To:" field. Since the mail headers are clearly separate from the mail content it's not possible to use HTML mail to achieve anything here. However, it turns out that it's possible to inject additional lines into the "Subject:" header that look like an additional mail header. This can be achieved in two ways: either by encoding a newline character in the subject line or by sending multiple subject headers within one mail.

Despite being able to inject additional fake mail headers, the attacker can't inject headers below the "To:" line. Thus, the order of the headers is not correct in a fake created with this trick. The pseudo-header also contains an icon: a check mark in a circle. While some similar characters exist in the Unicode standard, this exact icon cannot be replicated by an attacker.

Despite the shortcomings of this attack, the developers of GPGTools released an update that avoids this attack vector. Apple has not yet commented on the issue that, at its core, is a bug in Apple Mail, which should not allow multi-line subjects.

Text fakes

The text-mode client Mutt naturally isn't vulnerable to HTML-based attacks. Yet the most prominent indication of a signed message in Mutt is simply the output of the GPG verification command within the mail. One can easily send this output as part of the mail body. However, at the bottom of the screen, there is a message confirming the signature that cannot be faked. Here we see a real signature verification in Mutt:

And here is an example of a faked signature verification:

When asked about this in email, a Mutt developer confirmed that the developers are aware of the issue and that several mitigations exist. Notably, enabling colors for signed messages makes this attack almost useless, as an attacker can't change colors of a mail in Mutt's standard settings.

It's worth mentioning that all these attacks require the attacker to know details about the victim's system, in particular, the mail client they use. However this information often isn't secret. Many mail clients routinely include the "X-Mailer:" header that specifies which mail client and version was used.

User-interface attacks

The attacks on signatures are a case of user-interface (UI) attacks. These don't just affect mail clients, they can happen anywhere that an attacker can potentially influence the look of some UI element.

In the past it was possible to fake a browser's URL-entry bar in a popup. This is prevented in modern browsers; all browser windows — including popups — always contain a real URL bar. Yet similar attacks remain possible on mobile browsers [PDF]. Other attacks of that kind are still possible. One is the picture-in-picture attack, where a web page may simply draw a new window that looks just like a whole browser within the page. Such a trick was recently used in an attempt to phish Steam user accounts.

UI attacks are nothing new, but they haven't been properly investigated in the email space until recently. The first defense is obvious: the security indicators need to be moved out of the attacker-controlled space. For users, disabling HTML mail display and promptly applying security updates to mail-handling programs — good security practices in any case — are the best ways to avoid these fakes.

[I presented this attack in a lightning talk at the SEC-T conference [YouTube] and was interviewed afterward [YouTube] for a podcast.]