Authentication Results Injection
This attack involves injecting fake Authentication-Results headers into emails to make them appear to have passed authentication checks when they haven't.
Attack Summary: Injecting fake Authentication-Results headers to make emails appear to have passed authentication checks.
Background: Authentication-Results Headers
The Authentication-Results header is defined in RFC 8601 and is used by email servers to indicate the results of various authentication checks performed on an incoming email. These checks typically include:
- SPF (Sender Policy Framework): Verifies that the sending server is authorized to send email for the domain in the From header
- DKIM (DomainKeys Identified Mail): Verifies that the email was cryptographically signed by the domain in the From header
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Verifies that the email passes SPF and/or DKIM checks and that the From header domain aligns with the authenticated domain
The Authentication-Results header is added by the receiving email server after it performs these checks. It is intended to be used by downstream systems (such as email clients) to determine whether an email is legitimate.
Attack Methodology
This attack exploits the fact that some email systems may not properly validate or strip Authentication-Results headers from incoming emails. If an attacker can inject a fake Authentication-Results header into an email, they may be able to make it appear that the email has passed authentication checks when it hasn't.
This variant involves injecting a fake Authentication-Results header into an email to make it appear that the email has passed authentication checks.
Basic Injection Example
Injecting a fake Authentication-Results header
How It Works
- Attacker sends an email with a spoofed From header
- Attacker includes a fake Authentication-Results header in the email
- The fake header indicates that the email has passed SPF, DKIM, and DMARC checks
- If the receiving email server does not strip or validate this header, it will be passed to downstream systems
- Downstream systems (such as email clients) may trust the email as legitimate based on the fake Authentication-Results header
This variant involves injecting multiple Authentication-Results headers into an email to confuse downstream systems.
Multiple Injection Example
Injecting multiple Authentication-Results headers
Header Processing Inconsistencies
Different email systems may process multiple Authentication-Results headers differently:
- First header wins: Some systems may only consider the first Authentication-Results header
- Last header wins: Some systems may only consider the last Authentication-Results header
- Most secure wins: Some systems may choose the most secure result (e.g., fail over pass)
- Least secure wins: Some systems may choose the least secure result (e.g., pass over fail)
- Confusion: Some systems may become confused and default to a specific behavior
This variant involves impersonating a trusted email server in the Authentication-Results header.
Trusted Server Impersonation Example
Impersonating a trusted email server
Trusted Server Identification
Attackers can identify trusted servers by:
- Examining existing emails: Looking at Authentication-Results headers in legitimate emails
- Public information: Many organizations publish information about their email infrastructure
- DNS records: MX records can reveal the email servers used by a domain
- Common providers: Impersonating well-known email providers (e.g., Google, Microsoft)
- Trial and error: Testing different server names to see which ones are trusted
Impact
This attack allows attackers to:
- Make spoofed emails appear to have passed authentication checks
- Bypass email filtering systems that rely on Authentication-Results headers
- Increase the likelihood that recipients will trust and act on malicious emails
- Conduct more effective phishing and business email compromise attacks
Detection
Organizations can detect these attacks by:
- Configuring email servers to strip or validate Authentication-Results headers from incoming emails
- Implementing email security solutions that perform their own authentication checks
- Monitoring for inconsistent or suspicious Authentication-Results headers
- Checking for Authentication-Results headers that claim to be from trusted servers but aren't
Mitigation
To protect against these attacks, organizations should:
- Strip incoming headers: Configure email servers to strip Authentication-Results headers from incoming emails
- Add trusted headers: Add Authentication-Results headers based on their own authentication checks
- Validate headers: If not stripping headers, validate that they come from trusted servers
- Implement authentication: Implement SPF, DKIM, and DMARC for all domains
- Use email security: Implement email security solutions that perform their own authentication checks
- Train users: Educate users about the risks of email spoofing and phishing
Testing
Security professionals can test for this vulnerability using the following approach:
- Send test emails with fake Authentication-Results headers
- Check if the headers are stripped or validated by the receiving email server
- Check if downstream systems trust the fake headers
- Test different header variations to identify processing inconsistencies
- Document the results and recommend appropriate mitigations
References
- RFC 8601: "Message Header Field for Indicating Message Authentication Status." https://tools.ietf.org/html/rfc8601
- RFC 7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email." https://tools.ietf.org/html/rfc7208
- RFC 6376: "DomainKeys Identified Mail (DKIM) Signatures." https://tools.ietf.org/html/rfc6376
- RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance (DMARC)." https://tools.ietf.org/html/rfc7489