Have a look at our new Paper
"Content-Type: multipart/oracle - Tapping into Format Oracles in Email End-to-End Encryption" to be presented at USENIX '23. This is joint work with @duesee , Tobias Kappert, @SaatChris , and @seecurity .
Full paper (pre-print): https://www.usenix.org/system/files/sec23summer_217-ising-prepub.pdf
We found two vulnerable implementations:
1. Apple’s Mail on current versions of iOS is vulnerable to what we call an empty line oracle — they expect an empty line between the mail's headers and the body. This is exploitable by an attacker that can sniff (TLS encrypted) IMAP traffic while sending mails to the victim and Mail decrypting them in the background, no user interaction required.
2. Google Workspaces (Google’s hosted S/MIME solution) is vulnerable to a classic Vaudenay padding oracle attack on CBC padding. The oracle is an error message via SMTP. This error message ironically was introduced to prevent the EFAIL attacks.
Some backstory/details:
The idea of this paper dates back to our first research on S/MIME and OpenPGP in 2018 (EFAIL). We had the vague idea to do a Bleichenbacher Million Message Attack or Vaudenay Padding Oracle Attack on encrypted emails. However, at the time, we had no real idea on how to get the oracle response.
Since we didn’t want to rely on the user interacting with potentially thousands of email, we took a closer look at the protocols used for sending and receiving emails (IMAP and SMTP). Turns out that especially IMAP interacts a lot more with the internal structure of emails, leading to distinguishable traffic patterns revealing how much or which parts of an email were downloaded.
Fabian Ising