FakeBehalf: Imperceptible Email Spoofing Attacks against the Delegation Mechanism in Email Systems

FakeBehalf: Imperceptible Email Spoofing Attacks against the Delegation Mechanism in Email Systems

Speakers: Jinrui Ma, Bo Luo, Xuanbo Huang, David S.L. Wei, Yan Zhuang

Conference: USENIX Security '24

YouTube: https://www.youtube.com/watch?v=8wb4shJf4ns

Overview

In an era where email remains a primary communication vector for both personal and professional interactions, the security of email systems is paramount. This talk, "FakeBehalf: Imperceptible Email Spoofing Attacks against the Delegation Mechanism in Email Systems," unveils a critical and widespread vulnerability rooted in the often-overlooked email delegation mechanism. Presented by Jinrui Ma and a collaborative team from the University of Science and Technology of China, the University of Kansas, and Fordham University, the research meticulously details how attackers can craft seemingly legitimate spoofed emails that bypass conventional authentication protocols, making detection exceptionally challenging for both automated systems and human users.

The core problem identified is that existing email security extensions, such as SPF, DKIM, and DMARC, were not designed to validate the Sender header field, which is explicitly designated for delegation. This oversight creates a significant attack surface, allowing adversaries to impersonate trusted entities with high fidelity. The implications are profound, as these "imperceptible" spoofing attacks can facilitate sophisticated phishing campaigns, business email compromise (BEC) attempts, and other forms of social engineering, eroding trust in email as a secure communication channel. The research highlights the urgent need for a reevaluation of email security protocols to encompass the full spectrum of email headers and their intended functionalities.

Background

▶ Watch: Introduction: Email security extensions & delegation (0:00)

Email transmission fundamentally relies on the Simple Mail Transfer Protocol (SMTP), a foundational protocol that, in its original form, lacked any robust authentication mechanisms for senders. This inherent design flaw meant that any user on the internet could technically impersonate another to send emails. To counter this, the cybersecurity community developed a suite of security extensions: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).

SPF works by validating the sending IP address against a list of authorized senders published in the domain's DNS records, primarily focusing on the MAIL FROM address in the email's envelope. DKIM ensures email integrity and sender authenticity by attaching a digital signature to the email, verifying that the message content hasn't been tampered with in transit and that it originates from an authorized domain. DMARC builds upon both SPF and DKIM, providing a framework for domain owners to publish policies that instruct receiving mail servers on how to handle emails that fail SPF or DKIM checks, particularly by verifying the consistency between the From header field (the visible sender) and the authenticated domain from SPF or DKIM.

Despite their collective strength, a critical blind spot persists: these security extensions were explicitly not designed for the delegation mechanisms prevalent in modern email systems. Email delegation is a widely used feature where an email author authorizes another individual or entity (a "delegate") to send emails on their behalf. To distinguish between the real author and the delegate, RFC 5322 (which defines the Internet Message Format) specifies two distinct header fields: the From field, which indicates the real author of the email, and the Sender field, which identifies the email delegate. For instance, in many email clients, the Sender field might be displayed in a less prominent way, often in gray text, indicating its secondary role. The fundamental flaw, as highlighted by this research, is that the Sender field is not validated by any of these existing security extensions. This oversight is the fertile ground for the "FakeBehalf" attacks, allowing an attacker to arbitrarily spoof this field without triggering standard security alerts. The paper illustrates this with a direct example: a successful impersonation of [email protected] to a victim using 139.com mail, where the email appeared "totally legitimate" on a Gmail client, devoid of any indicators of a malicious origin.

Key Findings

▶ Watch: Demonstration of a successful email spoofing attack (2:35)

The research uncovers several critical security issues stemming from the neglected delegation mechanism, categorized into protocol and implementation vulnerabilities. These issues combine to enable sophisticated and "imperceptible" email spoofing attacks.

Firstly, the protocol issues are centered on the Sender header field. As previously noted, this field, intended to identify the delegate, is entirely overlooked by mainstream email security protocols like SPF, DKIM, and DMARC. Consequently, an attacker can arbitrarily fabricate its content without triggering any authentication failures. The measurement study conducted by the researchers extensively validated this, revealing that emails containing a spoofed Sender field successfully reached the inbox of all 16 mainstream email providers tested. Only five of these providers (e.g., NetEase Mail) implemented some form of protective measure, such as modifying the spoofed Sender field. Crucially, the remaining 11 providers, including major players like Gmail, left the spoofed Sender field unchanged, thereby enabling attackers to present a fabricated delegate identity directly to the recipient.

Secondly, the study identified significant implementation issues arising from the inconsistent handling of the delegation mechanism across various email providers and client applications. The research involved a comprehensive measurement study across 16 mainstream email providers (e.g., gmail.com, outlook.com) and 20 different email clients (ranging from web interfaces to mobile applications). The findings revealed a chaotic landscape:

• Web Interfaces: Six providers' web interfaces did not expose the delegate information to the receiver at all. Among those that did, implementations varied widely. For example, while RFC 5322 defines the Sender field as the delegate, Gmail's web interface often displays the Return-Path as the delegate. Other services adopted self-defined policies for delegate display.
• Client Applications: The inconsistencies were even more pronounced in client applications. When accessing a service like Gmail through different third-party clients, the handling of delegate information diverged significantly. Some clients were unable to correctly parse the Return-Path or other self-defined delegation information, leading to security gaps.

Combining these protocol and implementation issues, the researchers summarized three distinct attack cases:

1. Case 1: Servers don't modify, clients display wrong delegate. In this scenario, the receiving email server accepts the spoofed Sender field without alteration. Subsequently, the client application displays this fabricated delegate information to the user. For example, 139.com's web interface might correctly expose the attacker's actual address, but specific email clients, such as NetEase Mail's application, would parse and display only the spoofed Sender field, misleading the receiver.
2. Case 2: Servers modify, but clients don't expose delegate. Here, the receiving server attempts a protective measure by modifying or stripping the spoofed Sender field. However, the client application, perhaps due to its own implementation choices, still does not expose any delegate information to the user. This renders the server's defensive action ineffective from the user's perspective. For instance, NetEase Mail might modify the Sender field, but if the email is viewed in a Gmail client that doesn't expose any delegate information, the user remains unaware of the delegation, legitimate or otherwise.
3. Case 3: Inconsistent web interface display. This case highlights vulnerabilities even within web interfaces. Some providers, like mail.com, simply do not display any delegate information, creating a blind spot for users. Other providers, such as qq.com, might use both From and Sender fields in their delegate display logic. When a spoofed Sender field is present, the web interface might then fail to display the attacker's true origin accurately, or even omit crucial information about the email's actual delegate.

The comprehensive experimental results confirmed the widespread impact of these vulnerabilities, revealing that "half of the providers and all clients are affected," underscoring the effectiveness and pervasive nature of the FakeBehalf attack methodology.

Technical Deep Dive

▶ Watch: Attack model and bypassing existing security checks (3:50)

The technical foundation of the FakeBehalf attack lies in the architectural gap between established email authentication protocols and the Sender header field's role in email delegation. While SPF, DKIM, and DMARC meticulously validate aspects of the email's origin, they are primarily concerned with the envelope MAIL FROM address and the From header field, which represents the primary author. The Sender header, as defined by RFC 5322, is intended to specify an address responsible for the actual transmission of the message when different from the From address, essentially identifying the delegate. Crucially, no standardized authentication mechanism extends its validation scope to this Sender field. This means that a malicious actor can populate the Sender field with any arbitrary value without triggering an SPF, DKIM, or DMARC failure.

The attacker model employed in this research is straightforward yet highly effective. It involves three entities: Alice, the trusted author whom the attacker wishes to impersonate; Bob, the target receiver; and Eve, the attacker. Eve's operational capability is key: she controls a personal email server. This server is configured to directly initiate SMTP sessions with target mail servers. This direct interaction is fundamental to bypassing existing security checks.

Here's how Eve's server can successfully pass SPF, DKIM, and DMARC, even while spoofing:

1. SPF Evasion: Eve's server does not modify the SMTP commands that carry the MAIL FROM address. When Eve's server sends an email, it uses its own legitimate domain in the MAIL FROM command. Since Eve fully controls this domain, she can deploy a correct SPF policy that authorizes her server's IP address to send mail for that domain. Thus, the SPF check passes for the MAIL FROM domain.
2. DKIM Evasion: Similarly, because Eve controls the sending domain used in the MAIL FROM and Sender fields, she can generate and attach a valid DKIM signature for her own domain. This signature will correctly verify the integrity of the message and its origin from Eve's controlled domain, satisfying DKIM checks.
3. DMARC Evasion: DMARC's primary function is to align the From header domain with the domains authenticated by SPF or DKIM. In the FakeBehalf attack, the From header is spoofed to Alice's domain (e.g., [email protected]). However, the MAIL FROM and Sender domains are Eve's legitimate, authenticated domains. DMARC often performs alignment checks on the From header against either the MAIL FROM domain (for SPF) or the DKIM-Signature domain. While the From field might not align with Eve's domain, the attack often relies on the fact that DMARC policies might not be strictly enforced or that the Sender field itself is not part of the DMARC alignment criteria. The key insight is that the authentication results (SPF pass, DKIM pass for Eve's domain) are not prominently displayed to the end-user, especially when the Sender field is manipulated. The focus shifts to how the client displays the From and Sender fields, rather than the underlying authentication status of the MAIL FROM domain.

The core technical vulnerability is that the Sender header field's value, which carries the delegate's address, can be arbitrarily set by the attacker's server. Since existing email security protocols do not authenticate this specific header, receiving Mail Transfer Agents (MTAs) and Mail User Agents (MUAs) often trust its content or, more commonly, handle it inconsistently. This inconsistency manifests in various ways: some MTAs might pass the spoofed Sender field unaltered, others might strip or modify it. On the client side, MUAs (webmail interfaces, desktop clients, mobile apps) interpret and display this field differently. For instance, Gmail's web interface might substitute the Sender field with the Return-Path for delegate display, while other clients might directly render the Sender field, or even ignore it entirely. This fragmented approach to handling the Sender field creates a perfect storm for attackers, allowing them to craft emails where the visually prominent From field shows the spoofed legitimate sender (Alice), and the Sender field, if displayed, shows a fabricated delegate that further enhances the legitimacy, all while the underlying SPF/DKIM/DMARC checks for the actual sending domain (Eve's) pass silently in the background.

Demo / Proof of Concept

▶ Watch: Measurement study: Spoofed sender field ignored by providers (6:00)

While the talk did not feature a live, interactive demonstration in the traditional sense, the researchers presented compelling evidence of their attack's efficacy through a detailed case study and a large-scale measurement study. The primary proof of concept was a successful "A4 attack" where an adversary effectively impersonated [email protected]. In this scenario, the attacker sent an email to a victim whose email provider was 139.com. When the recipient viewed this email on a Gmail client, the message appeared "totally legitimate," with "no extra information that indicates the attack" originated from an adversary. This visual indistinguishability is the hallmark of the FakeBehalf attack, demonstrating its "imperceptible" nature and the ability to mislead recipients and automated systems alike.

Beyond this specific example, the entire measurement study served as a large-scale, systematic demonstration of the vulnerability. By testing against 16 mainstream email providers and 20 different client applications, the researchers empirically validated the widespread impact of FakeBehalf. The finding that emails with spoofed Sender fields reached the inbox of all tested providers, with 11 of them leaving the spoofed Sender field unaltered, directly proved the protocol-level vulnerability. Furthermore, the detailed analysis of how various web interfaces and client applications inconsistently displayed (or failed to display) delegate information provided concrete evidence of the implementation-level vulnerabilities. The revelation that "half of the providers and all clients are affected" by these attacks underscores the broad applicability and success of the FakeBehalf methodology across the modern email ecosystem. This extensive empirical validation, rather than a singular live demo, firmly established the reality and severity of the attack.

Defensive Implications

▶ Watch: Summarized attack cases exploiting delegation vulnerabilities (7:20)

The FakeBehalf research presents significant implications for email defenders, necessitating a multi-faceted approach to mitigate these "imperceptible" spoofing attacks. The primary defensive thrust must address the unvalidated nature of the Sender field.

The researchers propose a crucial validation scheme for the Sender field. Their core suggestion is that the delegate identified in the Sender field should be rigorously validated for consistency with the MAIL FROM command used during the first SMTP session. This means that if an email claims a delegate in its Sender header, that delegate's domain should align with the domain specified in the MAIL FROM envelope sender, which is already subject to SPF and DKIM checks. If an inconsistency is detected during the initial SMTP session, the receiving server should take protective measures, such as modifying or stripping the Sender field to prevent it from misleading the recipient. The paper provides more detailed specifics on this proposed validation scheme.

Beyond server-side enhancements, significant improvements are required at the email client level:

• Expose Email Delegate: Email clients should consistently implement strategies to clearly expose the email delegate information to the user. Making this information visible can be highly effective in revealing the true sender, especially when an attacker is attempting to conceal their identity.
• Standardized Header Parsing: Clients should be encouraged to parse the Sender header field utilizing the robust logic employed by the web interfaces of mainstream providers, aiming for a more consistent and secure display of delegate information.
• Warning Messages for Inconsistency: A critical recommendation is for email clients to display explicit warning messages when the Sender field is found to be inconsistent with the From field or other authenticated sender information. This visual cue can alert users to potential spoofing attempts that might otherwise appear legitimate.

Finally, email users also have a role in enhancing their own security posture:

• Prioritize Web Interfaces: Users should be advised to check important or suspicious emails primarily on web interfaces of their email providers. The research found web interfaces to be generally "less vulnerable" or at least more consistent in their display of delegate information compared to various third-party client applications.
• Verify Email Content: Users should maintain a healthy skepticism towards unexpected or critical emails, especially those requesting sensitive information or action. They should be encouraged to cross-verify the content of important emails through alternative, trusted communication channels (e.g., a phone call, a separate email to a known legitimate address) rather than relying solely on the email itself.

Implementing these layered defenses—from enhanced server-side validation to improved client-side transparency and user awareness—is essential to close the critical security gap exploited by FakeBehalf attacks and restore trust in email delegation mechanisms.

Key Takeaways

• Delegation Mechanism Exploited: Existing email authentication protocols (SPF, DKIM, DMARC) critically fail to validate the Sender header field, which is specifically designed for email delegation, creating a significant security blind spot.
• Imperceptible Spoofing: This oversight enables "imperceptible" email spoofing attacks where attackers can arbitrarily fabricate the Sender field, leading to emails that appear entirely legitimate to recipients and bypass standard security checks.
• Widespread Vulnerability: The attack affects a vast portion of the email ecosystem; the research found that emails with spoofed Sender fields reached the inbox of all 16 major email providers tested, with 11 of them leaving the spoofed field unchanged. Furthermore, all 20 tested client applications exhibited vulnerabilities due to inconsistent parsing and display of delegate information.
• Protocol and Implementation Gaps: The success of FakeBehalf attacks stems from a combination of protocol-level neglect of the Sender field and widespread, inconsistent implementations of delegation display across various email providers and client applications.
• Urgent Need for Validation: Effective defense requires a new validation scheme for the Sender field, ideally by ensuring its consistency with the MAIL FROM address during the initial SMTP session and modifying it if inconsistent.
• Client and User Awareness are Crucial: Email clients must improve by consistently exposing delegate information and displaying warnings for Sender field inconsistencies. Users should be educated to view important emails on web interfaces and to verify suspicious messages through alternative communication channels.

About the Speaker(s)

The research presented on "FakeBehalf: Imperceptible Email Spoofing Attacks against the Delegation Mechanism in Email Systems" was a collaborative effort. Jinrui Ma, a student from the University of Science and Technology of China, was the primary presenter, introducing the critical findings of the joint work. The research was conducted in collaboration with experts from the University of Kansas and Fordham University, highlighting a multi-institutional endeavor to address significant vulnerabilities in email security. The other named authors include Bo Luo, Xuanbo Huang, David S.L. Wei, and Yan Zhuang.