@incollection{PoddebniakSomorovskySchinzeletal.2018, author = {Poddebniak, Damian and Somorovsky, Juraj and Schinzel, Sebastian and Lochter, Manfred and R{\"o}sler, Paul}, title = {Attacking Deterministic Signature Schemes using Fault Attacks}, series = {3rd IEEE European Symposium on Security and Privacy}, booktitle = {3rd IEEE European Symposium on Security and Privacy}, year = {2018}, language = {mul} } @incollection{PoddebniakDresenMuelleretal.2018, author = {Poddebniak, Damian and Dresen, Christian and M{\"u}ller, Jens and Ising, Fabian and Schinzel, Sebastian and Friedberg, Simon and Somorovsky, Juraj and Schwenk, J{\"o}rg}, title = {Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels}, series = {USENIX Security 2018}, booktitle = {USENIX Security 2018}, edition = {27th}, address = {Baltimore, MD, USA}, isbn = {978-1-931971-46-1}, year = {2018}, language = {en} } @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{MuellerBrinkmannPoddebniaketal.2019, author = {M{\"u}ller, Jens and Brinkmann, Marcus and Poddebniak, Damian and Schinzel, Sebastian and Schwenk, J{\"o}rg}, title = {What's up John­ny? - Co­vert Con­tent At­tacks on Email End-to-End En­cryp­ti­on}, series = {17th In­ter­na­tio­nal Con­fe­rence on Ap­p­lied Cryp­to­gra­phy and Net­work Se­cu­ri­ty (ACNS 2019)}, booktitle = {17th In­ter­na­tio­nal Con­fe­rence on Ap­p­lied Cryp­to­gra­phy and Net­work Se­cu­ri­ty (ACNS 2019)}, pages = {1 -- 18}, year = {2019}, abstract = {We show practical attacks against OpenPGP and S/MIMEencryption and digital signatures in the context of email. Instead of tar-geting the underlying cryptographic primitives, our attacks abuse legiti-mate features of the MIME standard and HTML, as supported by emailclients, to deceive the user regarding the actual message content. Wedemonstrate how the attacker can unknowingly abuse the user as a de-cryption oracle by replying to an unsuspicious looking email. Using thistechnique, the plaintext of hundreds of encrypted emails can be leakedat once. Furthermore, we show how users could be tricked into signingarbitrary text by replying to emails containing CSS conditional rules.An evaluation shows that "out of" OpenPGP-capable email clients,as well as "out of" clients supporting S/MIME, are vulnerable to atleast one attack. We provide different countermeasures and discuss theiradvantages and disadvantages.}, language = {de} } @inproceedings{DresenIsingPoddebniaketal.2020, author = {Dresen, Christian and Ising, Fabian and Poddebniak, Damian and Kappert, Tobias and Holz, Thorsten and Schinzel, Sebastian}, title = {CORSICA: Cross-Origin Web Service Identification}, series = {The 15th ACM ASIA Conference on Computer and Communications Security}, booktitle = {The 15th ACM ASIA Conference on Computer and Communications Security}, editor = {Zhou, Jianying}, year = {2020}, abstract = {Vulnerabilities in private networks are difficult to detect for attackers outside of the network. While there are known methods for port scanning internal hosts that work by luring unwitting internal users to an external web page that hosts malicious JavaScript code, no such method for detailed and precise service identification is known. The reason is that the Same Origin Policy (SOP) prevents access to HTTP responses of other origins by default. We perform a structured analysis of loopholes in the SOP that can be used to identify web applications across network boundaries. For this, we analyze HTML5, CSS, and JavaScript features of standard-compliant web browsers that may leak sensitive information about cross-origin content. The results reveal several novel techniques, including leaking JavaScript function names or styles of cross-origin requests that are available in all common browsers. We implement and test these techniques in a tool called CORSICA. It can successfully identify 31 of 42 (74\%) of web services running on different IoT devices as well as the version numbers of the four most widely used content management systems WordPress, Drupal, Joomla, and TYPO3. CORSICA can also determine the patch level on average down to three versions (WordPress), six versions (Drupal), two versions (Joomla), and four versions (TYPO3) with only ten requests on average. Furthermore, CORSICA is able to identify 48 WordPress plugins containing 65 vulnerabilities. Finally, we analyze mitigation strategies and show that the proposed but not yet implemented strategies Cross-Origin Resource Policy (CORP)} and Sec-Metadata would prevent our identification techniques.}, language = {en} } @inproceedings{MuellerBrinkmannPoddebniaketal.2020, author = {M{\"u}ller, Jens and Brinkmann, Marcus and Poddebniak, Damian and Schinzel, Sebastian and Schwenk, J{\"o}rg}, title = {Mailto: Me Your Secrets. On Bugs and Features in Email End-to-End Encryption}, series = {2020 IEEE Conference on Communications and Network Security (CNS)}, booktitle = {2020 IEEE Conference on Communications and Network Security (CNS)}, doi = {10.1109/CNS48642.2020.9162218}, pages = {1 -- 9}, year = {2020}, abstract = {OpenPGP and S/MIME are the two major standards for email end-to-end encryption. We show practical attacks against both encryption schemes in the context of email. First, we present a design flaw in the key update mechanism, allowing a third party to deploy a new key to the communication partners. Second, we show how email clients can be tricked into acting as an oracle for decryption or signing by exploiting their functionality to auto-save drafts. Third, we demonstrate how to exfiltrate the private key, based on proprietary mailto parameters implemented by various email clients. An evaluation shows that 8 out of 20 tested email clients are vulnerable to at least one attack. While our attacks do not target the underlying cryptographic primitives, they raise concerns about the practical security of OpenPGP and S/MIME email applications. Finally, we propose countermeasures and discuss their advantages and disadvantages.}, 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} } @article{BrinkmannDresenMergetetal.2021, author = {Brinkmann, Marcus and Dresen, Christian and Merget, Robert and Poddebniak, Damian and M{\"u}ller, Jens and Somorovsky, Juraj and Schwenk, J{\"o}rg and Schinzel, Sebastian}, title = {ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication}, series = {30th USENIX Security Symposium}, journal = {30th USENIX Security Symposium}, year = {2021}, language = {en} } @inproceedings{MayerPoddebniakFischeretal.2022, author = {Mayer, Peter and Poddebniak, Damian and Fischer, Konstantin and Brinkmann, Marcus and Somorovsky, Juraj and Schinzel, Sebastian and Volkamer, Melanie}, title = {"I don't know why I check this...'' - Investigating Expert Users' Strategies to Detect Email Signature Spoofing Attacks}, series = {Eighteenth Symposium on Usable Privacy and Security (SOUPS 2022)}, booktitle = {Eighteenth Symposium on Usable Privacy and Security (SOUPS 2022)}, publisher = {USENIX Association}, address = {Boston, MA}, isbn = {978-1-939133-30-4}, pages = {77 -- 96}, year = {2022}, abstract = {OpenPGP is one of the two major standards for end-to-end email security. Several studies showed that serious usability issues exist with tools implementing this standard. However, a widespread assumption is that expert users can handle these tools and detect signature spoofing attacks. We present a user study investigating expert users' strategies to detect signature spoofing attacks in Thunderbird. We observed 25 expert users while they classified eight emails as either having a legitimate signature or not. Studying expert users explicitly gives us an upper bound of attack detection rates of all users dealing with PGP signatures. 52\% of participants fell for at least one out of four signature spoofing attacks. Overall, participants did not have an established strategy for evaluating email signature legitimacy. We observed our participants apply 23 different types of checks when inspecting signed emails, but only 8 of these checks tended to be useful in identifying the spoofed or invalid signatures. In performing their checks, participants were frequently startled, confused, or annoyed with the user interface, which they found supported them little. All these results paint a clear picture: Even expert users struggle to verify email signatures, usability issues in email security are not limited to novice users, and developers may need proper guidance on implementing email signature GUIs correctly.}, language = {en} } @inproceedings{IsingPoddebniakKappertetal.2023, author = {Ising, Fabian and Poddebniak, Damian and Kappert, Tobias and Saatjohann, Christoph and Schinzel, Sebastian}, title = {Content-Type: multipart/oracle -- Tapping into Format Oracles in Email End-to-End Encryption}, series = {32nd USENIX Security Symposium}, booktitle = {32nd USENIX Security Symposium}, publisher = {USENIX Association}, year = {2023}, abstract = {S/MIME and OpenPGP use cryptographic constructions repeatedly shown to be vulnerable to format oracle attacks in protocols like TLS, SSH, or IKE. However, format oracle attacks in the End-to-End Encryption (E2EE) email setting are considered impractical as victims would need to open many attacker-modified emails and communicate the decryption result to the attacker. But is this really the case? In this paper, we survey how an attacker may remotely learn the decryption state in email E2EE. We analyze the interplay of MIME and IMAP and describe side-channels emerging from network patterns that leak the decryption status in Mail User Agents (MUAs). Concretely, we introduce specific MIME trees that produce decryption-dependent net work patterns when opened in a victim's email client. We survey 19 OpenPGP- and S/MIME-enabled email clients and four cryptographic libraries and uncover a side-channel leaking the decryption status of S/MIME messages in one client. Further, we discuss why the exploitation in the other clients is impractical and show that it is due to missing feature support and implementation quirks. These unintended defenses create an unfortunate conflict between usability and security. We present more rigid countermeasures for MUA developers and the standards to prevent exploitation.}, language = {en} }