@inproceedings{MuellerBrinkmannPoddebniaketal.2019,
  author    = {M{\"u}ller, Jens and Brinkmann, Marcus and Poddebniak, Damian and B{\"o}ck, Hanno and Schinzel, Sebastian and Smomrosvsky, Juraj and Schwenk, J{\"o}rg},
  title     = {"Johnny, you are fired!" - Spoofing OpenPGP and S/MIME Signatures in Emails},
  series = {28th Usenix Security Symposium, Santa Clara, CA, USA},
  booktitle = {28th Usenix Security Symposium, Santa Clara, CA, USA},
  year      = {2019},
  abstract  = {OpenPGP and S/MIME are the two major standards to en-crypt and digitally sign emails. Digital signatures are sup-posed to guarantee authenticity and integrity of messages. Inthis work we show practical forgery attacks against variousimplementations of OpenPGP and S/MIME email signatureverification in five attack classes: (1) We analyze edge casesin S/MIME's container format. (2) We exploit in-band sig-naling in the GnuPG API, the most widely used OpenPGPimplementation. (3) We apply MIME wrapping attacks thatabuse the email clients' handling of partially signed mes-sages. (4) We analyze weaknesses in the binding of signedmessages to the sender identity. (5) We systematically testemail clients for UI redressing attacks.Our attacks allow the spoofing of digital signatures for ar-bitrary messages in 14 out of 20 tested OpenPGP-capableemail clients and 15 out of 22 email clients supportingS/MIME signatures. While the attacks do not target the un-derlying cryptographic primitives of digital signatures, theyraise concerns about the actual security of OpenPGP andS/MIME email applications. Finally, we propose mitigationstrategies to counter these attacks.},
  language  = {de}
}
@inproceedings{PoddebniakIsingBoecketal.2021,
  author    = {Poddebniak, Damian and Ising, Fabian and B{\"o}ck, Hanno and Schinzel, Sebastian},
  title     = {Why TLS is better without STARTTLS: A Security Analysis of STARTTLS in the Email Context},
  series = {Proceedings of the 30th USENIX Security Symposium, August 11-13, 2021},
  volume    = {2021},
  booktitle = {Proceedings of the 30th USENIX Security Symposium, August 11-13, 2021},
  isbn      = {978-1-939133-24-3},
  year      = {2021},
  abstract  = {TLS is one of today's most widely used and best-analyzed encryption technologies. However, for historical reasons, TLS for email protocols is often not used directly but negotiated via STARTTLS. This additional negotiation adds complexity and was prone to security vulnerabilities such as naive STARTTLS stripping or command injection attacks in the past. We perform the first structured analysis of STARTTLS in SMTP, POP3, and IMAP and introduce EAST, a semi-automatic testing toolkit with more than 100 test cases covering a wide range of variants of STARTTLS stripping, command and response injections, tampering attacks, and UI spoofing attacks for email protocols. Our analysis focuses on the confidentiality and integrity of email submission (email client to SMTP server) and email retrieval (email client to POP3 or IMAP server). While some of our findings are also relevant for email transport (from one SMTP server to another), the security implications in email submission and retrieval are more critical because these connections involve not only individual email messages but also user credentials that allow access to a user's email archive. We used EAST to analyze 28 email clients and 23 servers. In total, we reported over 40 STARTTLS issues, some of which allow mailbox spoofing, credential stealing, and even the hosting of HTTPS with a cross-protocol attack on IMAP. We conducted an Internet-wide scan for the particularly dangerous command injection attack and found that 320.000 email servers (2\% of all email servers) are affected. Surprisingly, several clients were vulnerable to STARTTLS stripping attacks. In total, only 3 out of 28 clients did not show any STARTTLS-specific security issues. Even though the command injection attack received multiple CVEs in the past, EAST detected eight new instances of this problem. In total, only 7 out of 23 tested servers were never affected by this issue. We conclude that STARTTLS is error-prone to implement, under-specified in the standards, and should be avoided.},
  language  = {en}
}