Composition Kills: A Case Study of Email Sender Authentication
USENIX Security Symposium, pp. 2183-2199, 2020.
EI
Weibo:
Abstract:
Component-based software design is a primary engineering approach for
building modern software systems. This programming paradigm, however, creates
security concerns due to the potential for inconsistent interpretations of
...More
Code:
Data:
Introduction
- Component-based software design [1] has been widely adopted as a way to manage complexity and improve reusability.
- The DMARC component parses this header to extract the SPF/DKIM authentication results and check whether the tested value align with the domain in the From header.
- Attackers can mislead the presentation to the user of email sender validity by using a mail server that (1) accepts multiple From headers, (2) with a different preference than the user’s email client.
Highlights
- Component-based software design [1] has been widely adopted as a way to manage complexity and improve reusability
- Modern software systems are commonly built using components made by different developers who work independently
- It is difficult to make components built by different developers fully consistent: 1) specifications allow for latitude in interpreting details; 2) it is easy to overlook the possibility of deliberate ambiguities in attacker-provided inputs; 3) specifications themselves evolve over time, with some components keeping outdated functionality for compatibility; 4) components can differ in which subset of a suite of complex features they implement; 5) components can vary in how they tolerate non-compliant inputs; and 6) functional equivalencechecking between complex components is intractable
- We present three classes of practical attacks against email authentication systems and identify a wide variety of inconsistencies between different components across email servers and clients
- We show that these inconsistencies can enable an attacker to bypass email authentication to impersonate any site, and even forge DomainKeys Identified Mail (DKIM)-signed emails with a legitimate domain’s signature
- All 10 email providers and 19 mail user agent (MUA) in our experimental testing proved vulnerable to multiple of the 18 attacks that we developed
Results
- Mail.ru (Server)’s DMARC component recognizes the folding-space-succeeded From header and authenticates attack.com, but Outlook (Windows) takes it as an unknown header and presents admin@legitimate.com as the validated From header.
- If the mail server forwards the From header as-is, different interpretations of multiple email addresses can directly lead to authentication bypasses.
- As shown in Figure 8c, Fastmail.com (Server) does not recognize the route portion, and treats attack.com as a real address to use for DMARC verification; while 10 MUAs, including Fastmail.com (Web), ignore the route portion, and only show admin@legitimate.com.
- Mail.ru (Server) and Zoho.com (Server) DMARC component believes that “<” has higher priority, and authenticate attack.com; but Outlook (Windows) and 8 other MUAs have a different preference, and only display legitimate.com.
- When an attacker sends a From header with Base64-encoded email address, e.g., “From: base64encode(admin@legitimate.com)”, the DMARC module of Yahoo.com (Server) authenticates the encoded domain, but its web interface shows the decoded address.
- An attacker can craft ambiguous emails by adding a new header (e.g., Subject) to the signed mail, if two parties in the email process chain parse and interpret the extra header differently; for example, if the DKIM component uses the original Subject header while the mail client uses the crafted Subject header.
- If the Content-Type header is not protected by the DKIM signature, the attacker can further change the email MIME structure by redefining it so that mail clients only display the attacker’s malicious content.
- As discover.com uses “l=” tag in its signature, and the Gmail server takes the last instance of duplicate headers for DKIM verification, the crafted email passes Gmail’s DKIM validation.
Conclusion
- The problem (A17) arises when an email provider does not perform sufficient checks on the From header, enabling an attacker to send a signed message with another user’s address.
- The root cause of UI-mismatch attacks is inconsistencies between email providers and MUAs. One possible mitigation solution7 is for mail servers to provide authentication information to email clients directly, so that email clients can avoid re-parsing and re-verifying complex messages.
- All 10 email providers and 19 MUAs in the experimental testing proved vulnerable to multiple of the 18 attacks that the authors developed
Summary
- Component-based software design [1] has been widely adopted as a way to manage complexity and improve reusability.
- The DMARC component parses this header to extract the SPF/DKIM authentication results and check whether the tested value align with the domain in the From header.
- Attackers can mislead the presentation to the user of email sender validity by using a mail server that (1) accepts multiple From headers, (2) with a different preference than the user’s email client.
- Mail.ru (Server)’s DMARC component recognizes the folding-space-succeeded From header and authenticates attack.com, but Outlook (Windows) takes it as an unknown header and presents admin@legitimate.com as the validated From header.
- If the mail server forwards the From header as-is, different interpretations of multiple email addresses can directly lead to authentication bypasses.
- As shown in Figure 8c, Fastmail.com (Server) does not recognize the route portion, and treats attack.com as a real address to use for DMARC verification; while 10 MUAs, including Fastmail.com (Web), ignore the route portion, and only show admin@legitimate.com.
- Mail.ru (Server) and Zoho.com (Server) DMARC component believes that “<” has higher priority, and authenticate attack.com; but Outlook (Windows) and 8 other MUAs have a different preference, and only display legitimate.com.
- When an attacker sends a From header with Base64-encoded email address, e.g., “From: base64encode(admin@legitimate.com)”, the DMARC module of Yahoo.com (Server) authenticates the encoded domain, but its web interface shows the decoded address.
- An attacker can craft ambiguous emails by adding a new header (e.g., Subject) to the signed mail, if two parties in the email process chain parse and interpret the extra header differently; for example, if the DKIM component uses the original Subject header while the mail client uses the crafted Subject header.
- If the Content-Type header is not protected by the DKIM signature, the attacker can further change the email MIME structure by redefining it so that mail clients only display the attacker’s malicious content.
- As discover.com uses “l=” tag in its signature, and the Gmail server takes the last instance of duplicate headers for DKIM verification, the crafted email passes Gmail’s DKIM validation.
- The problem (A17) arises when an email provider does not perform sufficient checks on the From header, enabling an attacker to send a signed message with another user’s address.
- The root cause of UI-mismatch attacks is inconsistencies between email providers and MUAs. One possible mitigation solution7 is for mail servers to provide authentication information to email clients directly, so that email clients can avoid re-parsing and re-verifying complex messages.
- All 10 email providers and 19 MUAs in the experimental testing proved vulnerable to multiple of the 18 attacks that the authors developed
Tables
- Table1: Email providers vulnerable to Intra-server attacks
- Table2: Vulnerability of the tested email providers and MUAs to UI-mismatch attacks
Related work
- Prior work discusses malformed email messages bypassing DMARC and DKIM [4, 14, 15]. Mailsploit encoded special characters such as newlines in From headers using an encoding approach given in RFC 1342 [14]. The author found that many email clients failed to properly sanitize such characters after decoding, leading to email-spoofing and code-injection attacks. This attack is similar but not the same as our A10 attack that uses encoding: his attacks encode control characters in From headers to exploit parsing errors in email clients, while our attacks encode spoofed email addresses to exploit inconsistencies between email servers and clients.
Replay attacks are a known problem noted in the DKIM specification [4], which in § 8 warns DKIM users of attacks involving extra header fields and the “l=” tag. But many developers overlook these warnings, and Ullrich presented multiple concrete attacks to exploit such weaknesses [15]. Based on the previous work, we introduce a new threat model to enhance the replay attacks. The previous replay attacks can’t spoof the email body in DKIM-signed messages unless the target sites are misconfigured with the l= tag. Our attacks provide a new way to achieve this by combining replay attackers and malicious users of legitimate email providers.
Funding
- This work was supported in part by the National Science Foundation via grant CNS-1237265, and by a gift from Google
Reference
- G. T. Heineman and W. T. Councill, “ComponentBased Software Engineering: Putting the Pieces Together,” Addison-Wesley, p. 5, 2001.
- J. Klensin, “Simple Mail Transfer Protocol,” Internet Requests for Comments, RFC Editor, RFC 5321, October 2008, http://www.rfc-editor.org/rfc/rfc5321.txt.
- S. Kitterman, “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1,” Internet Requests for Comments, RFC Editor, RFC 7208, April 2014, http://www.rfc-editor.org/rfc/rfc7208.txt.
- D. Crocker, T. Hansen, and M. Kucherawy, “DomainKeys Identified Mail (DKIM) Signatures,” Internet Requests for Comments, RFC Editor, STD 76, September 2011, http://www.rfc-editor.org/rfc/rfc6376.txt.
- M. Kucherawy and E. Zwicky, “Domain-based Message Authentication, Reporting, and Conformance (DMARC),” Internet Requests for Comments, RFC Editor, RFC 7489, March 2015, http://www.rfc-editor.org/rfc/rfc7489.txt.
- S. Blank, P. Goldstein, T. Loder, and T. Zink, “Brand Indicators for Message Identification (BIMI),” Working Draft, IETF Secretariat, Internet-Draft draft-blank-ietfbimi-00, February 2019, http://www.ietf.org/internetdrafts/draft-blank-ietf-bimi-00.txt.
- K. Andersen, B. Long, S. Blank, and M. Kucherawy, “The Authenticated Received Chain (ARC) Protocol,” Internet Requests for Comments, RFC Editor, RFC 8617, July 2019, http://www.rfc-editor.org/rfc/rfc8617.txt.
- Mozilla, “The public suffix list,” https://publicsuffix.org/, 2019, [accessed Oct-2019].
- M. Handley, V. Paxson, and C. Kreibich, “Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics,” in USENIX Security, 2001.
- P. W. Resnick, “Internet Message Format,” Internet Requests for Comments, RFC Editor, RFC 5322, October 2008, http://www.rfc-editor.org/rfc/rfc5322.txt.
- R. Dhamija, J. D. Tygar, and M. Hearst, “Why Phishing Works,” in Proceedings of the SIGCHI conference on Human Factors in computing systems. ACM, 2006, pp. 581–590.
- C. Thompson, M. Shelton, E. Stark, M. Walker, E. Schechter, and A. P. Felt, “The Web’s Identity Crisis: Understanding the Effectiveness of Website Identity Indicators,” in 28th USENIX Security Symposium, 2019, pp. 1715–1732.
- A. P. Felt, R. W. Reeder, A. Ainslie, H. Harris, M. Walker, C. Thompson, M. E. Acer, E. Morant, and S. Consolvo, “Rethinking connection security indicators,” in Twelfth Symposium on Usable Privacy and Security (SOUPS 2016), 2016, pp. 1–14.
- S. Haddouche, “Mailsploit,” https:// www.mailsploit.com/index, 2017, [accessed Oct-
- S. Ullrich, “Breaking DKIM—on Purpose and by Chance,” https://noxxi.de/research/breaking-dkim-onpurpose-and-by-chance.html, 2018, [accessed Oct2019].
- E. Alderson, “Tchap: The super (not) secure app of the French government,” https://medium.com/@fs0c131y/tchap-the-super-notsecure-app-of-the-french-government-84b31517d144, 2019, [accessed Feb-2020].
- N. Davison, “Exploiting email address parsing with AWS SES,” https://nathandavison.com/blog/exploitingemail-address-parsing-with-aws-ses, 2020, [accessed Feb-2020].
- Z. Durumeric, D. Adrian, A. Mirian, J. Kasten, E. Bursztein, N. Lidzborski, K. Thomas, V. Eranti, M. Bailey, and J. A. Halderman, “Neither snow nor rain nor MITM...: An empirical analysis of email delivery security,” in Proceedings of the 2015 Internet Measurement Conference. ACM, 2015, pp. 27–39.
- I. D. Foster, J. Larson, M. Masich, A. C. Snoeren, S. Savage, and K. Levchenko, “Security by any other name: On the effectiveness of provider based email security,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, 2015, pp. 450–464.
- H. Hu and G. Wang, “End-to-end Measurements of Email Spoofing Attacks,” in Proc. USENIX Security Symposium, 2018, pp. 1095–1112.
- U. D. of Homeland Security, “Binding Operational Directive 18-01: Enhance Email and Web Security,” https://cyber.dhs.gov/bod/18-01/, 2017, [accessed Oct2019].
- G. Ho, A. Sharma, M. Javed, V. Paxson, and D. Wagner, “Detecting Credential Spearphishing in Enterprise Settings,” in Proc. USENIX Security Symposium, 2017, pp. 469–485.
- G. Ho, A. Cidon, L. Gavish, M. Schweighauser, V. Paxson, S. Savage, G. M. Voelker, and D. Wagner, “Detecting and Characterizing Lateral Phishing at Scale,” in Proc. USENIX Security Symposium, 2019, pp. 1273– 1290.
- A. Cidon, L. Gavish, I. Bleier, N. Korshun, M. Schweighauser, and A. Tsitkin, “High Precision Detection of Business Email Compromise,” in Proc. USENIX Security Symposium, 2019, pp. 1291–1307.
- D. Poddebniak, C. Dresen, J. Müller, F. Ising, S. Schinzel, S. Friedberger, J. Somorovsky, and J. Schwenk, “Efail: Breaking S/MIME and OpenPGP email encryption using exfiltration channels,” in Proc. USENIX Security Symposium, 2018, pp. 549–566.
- J. Müller, M. Brinkmann, D. Poddebniak, H. Böck, S. Schinzel, J. Somorovsky, and J. Schwenk, ““Johnny, you are fired!”–Spoofing OpenPGP and S/MIME Signatures in Emails,” in Proc. USENIX Security Symposium, 2019.
- S. Bratus, M. E. Locasto, M. L. Patterson, L. Sassaman, and A. Shubina, “Exploit programming: From buffer overflows to weird machines and theory of computation,” USENIX; login, vol. 36, no. 6, 2011.
- L. Sassaman, M. L. Patterson, S. Bratus, and M. E. Locasto, “Security applications of formal language theory,” IEEE Systems Journal, vol. 7, no. 3, pp. 489–500, 2013.
- T. H. Ptacek and T. N. Newsham, “Insertion, Evasion, and Denial of service: Eluding Network Intrusion Detection,” DTIC Document, Tech. Rep., 1998.
- R. F. Puppy, “A Look at Whisker’s Anti-IDS Tactics,” Online, 12 1999.
- M. Vutukuru, H. Balakrishnan, and V. Paxson, “Efficient and Robust TCP Stream Normalization,” in Security and Privacy, 2008. SP 2008. IEEE Symposium on. IEEE, 2008, pp. 96–110.
- E. Korhonen, “Advanced Evasion Techniques— Measuring the Threat Detection Capabilities of Up-to-Date Network Security Devices,” Master’s Thesis, 08 2012.
- O.-P. Niemi and A. Levomäki, “Evading Deep Inspection for Fun and Shell,” Black Hat USA, 2013.
- J. Chen, J. Jiang, H. Duan, N. Weaver, T. Wan, and V. Paxson, “Host of Troubles: Multiple Host Ambiguities in HTTP implementations,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016, pp. 1516–1527.
- R. Wang, S. Chen, X. Wang, and S. Qadeer, “How to Shop for Free Online–Security Analysis of Cashier-asa-Service Based Web Stores,” in 2011 IEEE Symposium on Security and Privacy. IEEE, 2011, pp. 465–480.
- C. Linhart, A. Klein, R. Heled, and S. Orrin, “HTTP Request Smuggling,” Computer Security Journal, vol. 22, no. 1, p. 13, 2006.
- S. Ullrich, “HTTP Evader—Automate Firewall Evasion Tests,” http://noxxi.de/research/http-evader.html, [accessed Apr-2019].
- I. Ristic, “Protocol-level Evasion of Web Application Firewalls,” Black Hat USA, 2012.
- J. Chen, X. Zheng, H.-X. Duan, J. Liang, J. Jiang, K. Li, T. Wan, and V. Paxson, “Forwarding-Loop Attacks in Content Delivery Networks,” in NDSS, 2016.
- S. Jana and V. Shmatikov, “Abusing File Processing in Malware Detectors for Fun and Profit,” in Proceedings of the 2012 IEEE Symposium on Security and Privacy. IEEE Computer Society, 2012, pp. 80–94.
- J. Oberheide, M. Bailey, and F. Jahanian, “PolyPack: an Automated Online Packing Service for Optimal Antivirus Evasion,” in Proceedings of the 3rd USENIX Conference on Offensive Technologies. USENIX Association, 2009, pp. 9–9.
- S. Porst, “How to Really Obfuscate your PDF Malware,” RECON, July, 2010.
- D. Kaminsky, M. L. Patterson, and L. Sassaman, “PKI Layer Cake: New Collision Attacks Against the Global X. 509 Infrastructure,” in International Conference on Financial Cryptography and Data Security. Springer, 2010, pp. 289–303.
- Z. Su and G. Wassermann, “The Essence of Command Injection Attacks in Web Applications,” in ACM SIGPLAN Notices, vol.
- 41. ACM, 2006, pp. 372–382.
- [45] P. Hooimeijer, B. Livshits, D. Molnar, P. Saxena, and M. Veanes, “Fast and Precise Sanitizer Analysis with BEK,” in USENIX Security Symposium, vol. 58, 2011.
- [46] D. Brumley, J. Caballero, Z. Liang, J. Newsome, and D. Song, “Towards Automatic Discovery of Deviations in Binary Implementations with Applications to Error Detection and Fingerprint Generation,” in USENIX Security Symposium, 2007, p. 15.
- [47] X. Yang, Y. Chen, E. Eide, and J. Regehr, “Finding and Understanding Bugs in C Compilers,” in ACM SIGPLAN Notices, vol.
- 46. ACM, 2011, pp. 283–294.
- [48] Y. Chen, T. Su, C. Sun, Z. Su, and J. Zhao, “Coveragedirected Differential Testing of JVM Implementations,” in ACM SIGPLAN Notices, vol.
- ACM, 2016, pp. 85–99.
- [49] Y. Chen and Z. Su, “Guided Differential Testing of Certificate Validation in SSL/TLS Implementations,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. ACM, 2015, pp. 793–804.
- [50] T. Petsios, A. Tang, S. Stolfo, A. D. Keromytis, and S. Jana, “NEZHA: Efficient Domain-independent Differential Testing,” in 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017, pp. 615–632.
- [51] C. Brubaker, S. Jana, B. Ray, S. Khurshid, and V. Shmatikov, “Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations,” in 2014 IEEE Symposium on Security and Privacy. IEEE, 2014, pp. 114–129.
Full Text
Tags
Comments