Splitting the email atom exploiting parsers to bypass access controls

Splitting the email atom exploiting parsers to bypass access controls

Speakers: Gareth Heyes

Conference: DEF CON 32

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

Overview

In "Splitting the Email Atom: Exploiting Parsers to Bypass Access Controls," Gareth Heyes, a prominent security researcher, delves into the often-overlooked complexities and inherent vulnerabilities within email address parsing. The talk meticulously uncovers how discrepancies in how different systems interpret seemingly valid RFC-compliant email addresses can lead to critical security bypasses, including remote code execution (RCE). Heyes challenges the common assumption that email addresses are simple, stable identifiers, revealing a landscape fraught with ancient protocols, exotic encodings, and a surprising lack of consistency across various email processing engines.

The significance of this research lies in its direct impact on modern web application security. Many contemporary services, such as Slack and Cloudflare Zero Trust, rely on the domain portion of an email address to infer a user's organizational affiliation and enforce access controls. This makes email verification a critical security boundary. Heyes demonstrates that if an attacker can manipulate how an email address is parsed, they can effectively trick these systems into granting unauthorized access, leading to severe implications for data confidentiality and system integrity.

Background

▶ Watch: Introduction: Why email parser discrepancies matter (0:00)

The foundation of email addresses, while seemingly straightforward, rests upon a complex and often contradictory set of Request for Comments (RFCs) that were designed many years ago. This antiquated and intricate specification forms a "shaky foundation" for modern email processing. A common practice for email validation in web applications involves copying and pasting regular expressions from sources like Stack Overflow, often with the intent of adhering to these RFCs. However, even a minor mistake in such a regex, or a fundamental misunderstanding of the RFCs' nuances, can open the door to critical vulnerabilities.

Heyes highlights several key RFC concepts that contribute to the problem. The local part of an email address, which precedes the @ symbol, allows for considerable flexibility. The quoted local part permits characters not normally allowed in the local part, such as an @ symbol itself, by enclosing them in double quotes (e.g., "user@example"@domain.com). Similarly, the quoted pair mechanism allows for the use of otherwise forbidden characters like double quotes (") and backslashes (\) within the local part by escaping them with a backslash (e.g., user\"[email protected]). Additionally, characters enclosed in parentheses () are treated as comments and are entirely ignored during email delivery, regardless of their position (except within a quoted local part). These seemingly innocuous features, when interpreted differently by various parsers, become potent tools for an attacker.

The core of the problem stems from the "ludicrously difficult" task of predicting an email's final destination, even for RFC-compliant addresses. Heyes illustrates this with a compelling example: two distinct email addresses that one might expect to route to example.com due to the visible domain, but which instead both route to psres.net. This discrepancy arises because different Mail Transfer Agents (MTAs) interpret these special characters in divergent ways. For instance, one address might be correctly handled by Postfix, while another might be redirected by Sendmail, an older MTA that still influences email routing.

This unpredictable routing capability is rooted in ancient email protocols and routing mechanisms that predate modern internet email. One such mechanism is source routing, sometimes referred to as the percent hack. This technique uses a percent symbol (%) to effectively rewrite the destination address. An email like user%[email protected] would first be sent to example.com, which would then convert the % into an @, forwarding the email to [email protected]. This process can be chained multiple times. Another critical historical artifact is the UUCP (Unix to Unix Copy Protocol) bang path. Originating from the early days of networked computing, UUCP used an exclamation mark (!) to separate hosts in a routing path, listing them from left to right with the destination user on the far right (e.g., hostA!hostB!user). Heyes reveals that modern MTAs, particularly Sendmail, can still interpret certain email address constructions, especially those involving escaped characters or comments, as UUCP bang paths, completely altering the intended recipient domain. The manipulation of comments (parentheses) or escaped @ symbols (backslash) can effectively remove the intended domain from the parser's view, causing it to fall back to these older, less predictable routing mechanisms.

Key Findings

▶ Watch: Shaky foundations: RFCs, quoted parts, comments (2:00)

Gareth Heyes' research uncovers several critical findings that collectively paint a concerning picture for email-based security:

1. Email Parser Discrepancies are a Critical Attack Vector: Just as discrepancies in URL parsing can lead to severe vulnerabilities like Server-Side Request Forgery (SSRF) and path traversal, email address parser discrepancies are equally, if not more, critical. When email domains are used for access control, these discrepancies enable attackers to bypass authentication and authorization mechanisms.
2. RFC Compliance Does Not Guarantee Security: A central revelation is that an email address being "RFC compliant" does not ensure it will be parsed consistently or securely across all systems. Different MTAs (e.g., Postfix, Sendmail) and web application parsers interpret the same RFC-compliant address in fundamentally different ways, leading to unpredictable routing and security bypasses.
3. Exploitation of Ancient Protocols: The talk demonstrates how leveraging historical email routing mechanisms like the percent hack (source routing) and the UUCP bang path can be used to redirect emails. By carefully crafting an email address using RFC-allowed characters (like comments or escaped symbols), an attacker can trick a parser into interpreting the address according to these older protocols, sending the email to an unintended destination despite the apparent domain.
4. Unicode Overflows for Filter Evasion: Heyes introduces the concept of Unicode overflows as a sophisticated technique to bypass input filters. This method exploits how some systems normalize or truncate higher Unicode code points, effectively generating ASCII characters (such. as the @ symbol) that might be explicitly blocked by web application firewalls or validation routines designed to prevent multiple @ symbols. This allows attackers to inject characters necessary for their exploits into otherwise sanitized input fields.
5. Access Control Bypass Leading to RCE: The culmination of these parsing vulnerabilities is the ability to bypass access controls. By redirecting an email intended for a legitimate example.com address to an attacker-controlled psres.net domain, an attacker can intercept verification tokens, password reset links, or other sensitive information. This unauthorized access to an administrator's account, particularly in vulnerable applications like Joomla, can then be leveraged to achieve Remote Code Execution (RCE).

Technical Deep Dive

▶ Watch: Core problem: Predicting email destination is hard (4:00)

The technical core of Heyes' research lies in the intricate interplay between RFC specifications, diverse parser implementations, and the vestiges of ancient email protocols. The speaker meticulously breaks down how these elements can be manipulated to achieve unexpected email redirection and filter bypasses.

RFC Nuances and Their Exploitation:

Modern email addresses are defined by RFCs, primarily RFC 5322 (Internet Message Format) and RFC 5321 (Simple Mail Transfer Protocol). Heyes focuses on specific features that, while RFC-compliant, are often misunderstood or inconsistently implemented:

• Quoted Local Part: This allows for characters normally forbidden in the local part (the part before the @) to be used if enclosed in double quotes. For example, “user@internal”@external.com is a valid address. A parser might correctly identify external.com as the domain, but a vulnerable system might misinterpret the internal @ symbol.
• Quoted Pair: Within a quoted local part, special characters like \ and " can be included by preceding them with a backslash (e.g., “user\\name”@domain.com). This escaping mechanism can be crucial for crafting payloads that bypass initial validation.
• Comments: Characters enclosed in parentheses () are treated as comments and are ignored during the actual email delivery process. This is a powerful primitive for attackers. An address like user(comment)@domain.com will still deliver to [email protected]. The key insight is that these comments can be strategically placed to obscure or remove parts of the domain from a pre-delivery parser, while the delivery MTA ignores them. For example, user@(example.com)psres.net might be parsed by a web application as example.com (due to the ( acting as a delimiter for the domain), but the actual mail server, ignoring the comment, routes it to psres.net. Similarly, [email protected](comment) is valid. If the comment contains an @ symbol or other routing characters, and a parser fails to correctly identify the end of the domain before the comment, it can lead to misinterpretation.

Exploiting Ancient Protocols: Source Routing and UUCP:

The ability to leverage source routing (percent hack) and UUCP (bang path) is central to redirecting emails.

• Percent Hack: An address like user%[email protected] is initially sent to attacker.com. The MTA at attacker.com then interprets the % as an @ and forwards the email to [email protected]. This allows an attacker to intercept emails intended for recipient.com if attacker.com is under their control and the initial application validates attacker.com but the MTA routes based on the %. Heyes demonstrates how characters like comments () can effectively remove the intended domain from the email address for certain parsers, causing them to fall back to interpreting the address as a percent source route. For example, user@(example.com)%[email protected] might be perceived by a web app as belonging to attacker.com, but the MTA might route to psres.net via attacker.com.
• UUCP Bang Path: The ! character is used in UUCP addresses (e.g., hostA!hostB!user). Heyes found that Sendmail, an older but still prevalent MTA, can interpret certain malformed email addresses as UUCP bang paths. Specifically, if a character like a backslash \ is used to escape an @ symbol, and an exclamation mark ! is present, Sendmail might treat the address as UUCP. For instance, user\@example.com!psres.net might appear to belong to example.com to an initial parser, but Sendmail, seeing the ! and the escaped @, could treat psres.net as the destination host in a UUCP path. The speaker discovered this behavior "by sheer luck" when pasting "all sorts of special characters" into an email field and observing a "host unknown" error in the Delivery Status Notification (DSN) for psres.net, where the ! was missing in the error message, indicating a different interpretation.

Unicode Overflows for Filter Bypass:

A significant challenge for attackers is bypassing input filters that block multiple @ symbols or other problematic characters. Heyes introduces Unicode overflows as a clever technique to overcome this.

• Concept: Some systems, when converting higher Unicode code points to a lower byte range (e.g., ASCII), perform a modulo operation (% 256) or truncation. This can result in a higher Unicode character "overflowing" and producing an ASCII character.
• PHP Example: The PHP chr() function, which generates a character from an integer code point, illustrates this. If a code point is greater than 255, it's effectively code_point % 256. So, chr(0x140) (320 in decimal) would result in chr(0x40), which is the @ symbol. This means an attacker could input a Unicode character that appears benign but is normalized into an @ symbol by the backend.
• JavaScript Example: Similar behavior can be observed in JavaScript using String.fromCodePoint(). Heyes provides the example String.fromCodePoint(0x100, 0x40). When this Unicode character is later processed by a system that doesn't fully support higher Unicode or performs normalization to fit into a 255-byte range, it can produce the ASCII @ character (0x40). This allows an attacker to inject an @ symbol that was not explicitly present in the initial input, bypassing filters designed to count or restrict @ symbols.

While the talk mentions encoded word and Punycode as other areas of parser discrepancies, the detailed technical explanation and real-world case studies primarily focus on the historical protocols and Unicode overflows. The demo, however, explicitly uses a "malformed Punycode" address, suggesting its utility in similar bypasses. Punycode is used to encode internationalized domain names (IDNs) for compatibility with the ASCII-only Domain Name System. Discrepancies here can involve how different systems validate, normalize, or decode Punycode, potentially leading to domain spoofing or redirection.

Demo / Proof of Concept

▶ Watch: Exploiting Unicode overflows for character generation (6:17)

Gareth Heyes reinforced his findings with a live demonstration, showcasing a practical access control bypass attack leading to token exfiltration on a vulnerable application, specifically a Joomla installation. The setup involved three components: a victim (admin user) on the left, an attacker on the right, and an exfiltration server running in the background to capture stolen tokens.

The attack sequence proceeded as follows:

1. Attacker Account Registration (Phase 1 - Malformed Punycode): The attacker first attempts to register an account using an email address containing malformed Punycode. While the speaker noted that this particular attempt resulted in an error (due to a mail server misconfiguration on his demo setup, not a flaw in the exploit technique itself), the intent was to demonstrate how such an address could be used to interact with the system's parsing logic.
2. Attacker Account Registration (Phase 2 - Payload Injection): Next, the attacker successfully registers a second account using an email address crafted with the actual payload designed to exfiltrate a token. This email address, while appearing valid to the web application's frontend parser, exploits the backend's parser discrepancies (likely using the Unicode overflow or ancient protocol redirection techniques discussed) to ensure that sensitive emails intended for a legitimate admin address are instead routed to an attacker-controlled mailbox.
3. Admin Login and Token Exfiltration: The crucial step involves the victim, the admin user, logging into their account. During this process, or potentially through some subsequent action (e.g., password reset, verification email), the vulnerable Joomla application attempts to send an email to the admin. Due to the attacker's crafted email address and the parser discrepancy, this email, which contains a sensitive token, is redirected to the attacker's exfiltration server.
4. Token Capture: The exfiltration server, running on the attacker's side, successfully captures the token. This token, likely a session token, password reset token, or similar sensitive credential, grants the attacker unauthorized access to the admin's account.

Heyes specifically mentioned that the "import chaining technique" used to exfiltrate the token was inspired by the work of researchers Pat Villa and Donut, indicating a sophisticated method often employed in real-world attacks. By gaining control of the admin account through token exfiltration, an attacker can then perform privileged actions, which, depending on the application's capabilities (as in the case of a vulnerable Joomla instance), could ultimately lead to Remote Code Execution (RCE). The speaker provides a Docker file for a vulnerable Joomla installation on his GitHub repository, allowing others to replicate and study these attacks.

Defensive Implications

▶ Watch: PHP char() function: A Unicode overflow example (6:50)

Gareth Heyes provides crucial advice for developers and security professionals to defend against these sophisticated email splitting attacks. The core message is to move beyond superficial email validation and understand the deeper implications of parser discrepancies.

1. Filter Out or Disable Encoded Word: The speaker explicitly recommends filtering out or disabling the use of encoded word in email processing. While not extensively detailed in the technical deep dive, encoded word (defined in RFC 2047) allows non-ASCII characters in email headers and can be another source of parser discrepancies if not handled carefully. Disabling it reduces a potential attack surface.
2. Always Verify Email Addresses Thoroughly: It is paramount to perform robust verification of email addresses at multiple stages. This includes not only client-side and server-side validation against a strict, secure regex but also understanding how the underlying MTA will interpret the address. Crucially, Heyes warns against implicitly trusting email addresses, even when received from seemingly secure sources like an SSO (Single Sign-On) provider. An attacker might bypass initial SSO validation using these techniques, leading to a compromised email being passed downstream.
3. Do NOT Use the Email Domain as the Sole Means of Authorization: This is perhaps the most critical defensive implication. Many modern applications rely heavily on the domain part of an email address for access control (e.g., allowing [email protected] access to internal resources). Heyes unequivocally states that this practice is fundamentally insecure. Due to the demonstrated parser discrepancies, an email address that visually appears to belong to yourcompany.com might, in reality, be routed to an attacker-controlled domain. Therefore, authorization decisions should incorporate stronger, multi-factor identity verification mechanisms that do not solely depend on the email domain.
4. Adopt a Probing Methodology for Defense: Heyes outlines a four-step methodology for discovering and understanding these vulnerabilities, which can also be adapted for defensive testing:

• Probe: Actively test email input fields with various special characters, Unicode characters, and RFC-compliant but unusual constructions.
• Observe: Carefully monitor how the application and the underlying mail system process these inputs. Look for delivery status notifications (DSNs), syslog entries, or any unexpected routing behavior.
• Encode: Experiment with different encoding schemes (e.g., Unicode overflows, quoted pairs, percent encoding) to see how they are normalized or interpreted.
• Exploit: Attempt to trigger the identified discrepancies to confirm their exploitability and understand their impact.

1. Stay Informed about RFCs and MTA Behavior: Developers and security engineers must have a deep understanding of the relevant email RFCs and, crucially, how specific Mail Transfer Agents (Postfix, Sendmail, Exim, etc.) and programming language email libraries implement and interpret these standards. This knowledge is vital for anticipating and mitigating parser discrepancies.

Key Takeaways

• Valid RFC-compliant email addresses can trigger major parser discrepancies across different systems, leading to unpredictable routing and security vulnerabilities.
• An email address appearing to end in @example.com might not actually go to example.com due to hidden routing mechanisms like source routing (% hack) or UUCP bang paths (!).
• It is never safe to use the email domain as the sole means of access control enforcement because an attacker can manipulate parsing to bypass authorization checks.
• Unicode overflows are a potent technique for bypassing input filters, allowing attackers to inject characters like @ by exploiting normalization behaviors in backend systems.
• Ancient email protocols like UUCP and source routing remain relevant attack vectors due to their continued support or legacy interpretation by modern Mail Transfer Agents.
• Thorough, multi-stage email validation is essential, extending beyond simple regex checks to include an understanding of how MTAs will process the address, even for inputs from trusted sources like SSO providers.

About the Speaker(s)

Gareth Heyes is a distinguished security researcher who presented "Splitting the Email Atom: Exploiting Parsers to Bypass Access Controls" at DEF CON 32. His work focuses on uncovering subtle yet critical vulnerabilities in widely used systems, particularly those involving parsing and interpretation of data. Through his detailed research, Heyes demonstrates a profound understanding of complex technical specifications, historical protocols, and their often-unforeseen security implications. His contributions include not only identifying these intricate parser discrepancies but also developing methodologies and tools to automate their exploitation and providing actionable defensive strategies.