A group of academic researchers have developed practical attacks targeting two widely used end-to-end encryption schemes for email, which could lead to man-in-the-middle decryption attacks and exfiltration of private keys.
The researchers were able to conduct a key replacement attack, in which they were able to deploy a new key to the recipients, as well as a man-in-the-middle attack where they tricked the email clients into acting as an oracle for decryption or signing by exploiting their functionality to auto-save drafts, according to the Mailto: Me Your Secrets. On Bugs and Features in Email End-to-End Encryption paper from the virtual IEEE Conference on Communications and Network Security. The authors are Jens Müller, Marcus Brinkmann, and Joerg Schwenk from Ruhr University Bochum in Germany, and Damian Poddebniak and Sebastian Schinzel from Münster University of Applied Sciences in Germany. They were also able to exfiltrate the private key, based on proprietary mailto parameters implemented by various email clients.
“While our attacks do not target the underlying cryptographic primitives, they raise concerns about the practical security of OpenPGP and S/MIME email applications."
The attacks outlined in the paper aren’t exploiting cryptographic weaknesses in OpenPGP or S/MIME, but in the way specific email client software handle certificates and key exchange mechanisms. The fact that these attacks are possible are concerning because it means attackers can potentially target vulnerable email clients to read encrypted messages and steal private keys used to protect these messages.
"We show practical attacks against both encryption schemes [OpenPGP and S/MIME] in the context of email," the researchers wrote.
Attack Types
Researchers were able to show how an adversary could automatically install certificates contained in S/MIME communications. For example, the researchers identified a design flaw in a client’s key update mechanism which could be abused to replace the public keys used in encrypted S/MIME communications. The researchers were able to silently replace the encryption key for six S/MIME-supporting email clients.
A man-in-the-middle attack would involve an internet or email provider, or a compromised SMTP or IMAP server.
Email clients could also be tricked into into decrypting ciphertext messages or signing arbitrary messages and then sending them to an IMAP server controlled by the attacker. For three OpenPGP-capable clients, the researchers exfiltrated the plaintext to an IMAP server controlled by an attacker, or misused the clients as “signing oracles.”
The researchers tested 20 popular email clients, supporting either S/MIME or OpenPGP, from a list of more than 50 clients across major platforms (Windows, Linux, macOS, Android, and iOS), as well as web-based applications. As the table (Table 2 from the paper) shows, researchers were able to replace the keys in the Windows versions of Microsoft Outlook. "For Microsoft Outlook, we could verify the existence of this dangerous feature since at least Outlook 2007," the researchers wrote.
“An evaluation shows that 8 out of 20 tested email clients are vulnerable to at least one attack,” the researchers found. More specifically, five out of 18 OpenPGP-capable email clients and six out of 18 S/MIME-capable clients were vulnerable to at least one attack.
mailto: Parameters
The researchers were also able to abuse the mailto: URI method, which allows third-party applications to open a separate email client to compose a message, to secretly attach local files to email messages and sent to an attacker’s address. The mailto method is often used on websites, where clicking on a link can launch the locally installed email client with the recipient field (To) pre-populated with the email address the message is going to. It is possible to pre-populate other fields, such as a subject line and even the body of the message.
The issue lies in how email clients implemented RFC6068, the technical standard describing mailto. The researchers found that several standard parameters the mailto URI passes to the email client could be abused to trick the email client into decrypting ciphertext messages, or signing messages and sending them to attackers, the researchers said. One example of this is how the mailto method uses the attach or attachment parameters to open up an email window with a file already attached. If the user does not notice that the email window has the file attached, the user could inadvertently send sensitive information such as encryption (PGP) keys, SSH private keys, configuration files, and other sensitive information.
Researcher Müller posted a video on Twitter illustrating how mailto parameters could be abused. The researchers were able to perform this attack on four of the tested clients.
The researchers were able to attach files by knowing the exact file paths for the desired files, using wildcard characters to attach multiple files in a given location, or using URLs pointing to internal network shares. They were also able to use IMAP links to steal email messages from a user's IMAP email inbox.
The vulnerabilities have been reported to the affected vendors back in February. The list includes IBM/HCL Notes (CVE-2020-4089), GNOME Evolution (CVE-2020-11879), and KDE KMail (CVE-2020-11880). The details for CVE-2020-12618, and CVE-2020-12619 have not been made public. Thunderbird versions 52 and 60 for Debian/Kali Linux were affected as they had problems with the mailto parameter allowing local files (such as an SSH private key) to be attached to outgoing messages. Recent versions of Thunderbird are not vulnerable, as the issue with the mailto?attach= parameter was fixed in Thunderbird last year.
“While our attacks do not target the underlying cryptographic primitives, they raise concerns about the practical security of OpenPGP and S/MIME email applications,” the researchers wrote.
Researchers evaluated email clients supporting OpenPGP and S/MIME and found that eight were vulnerable to at least one attack. (Source: Mailto: Me Your Secrets. On Bugs and Features in Email End-to-End Encryption. Table 2 of the paper)