DKIM Bypass

This attack focuses on bypassing DomainKeys Identified Mail (DKIM) email authentication to send spoofed emails that appear to come from a legitimate domain.

Attack Summary: Bypassing DKIM authentication to send spoofed emails that appear to come from a legitimate domain.

Background: DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails. DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain.

DKIM works by:

The sending domain generates a public-private key pair
The public key is published in the domain's DNS records
When sending an email, the mail server uses the private key to generate a digital signature for the email
The signature is included in the email headers
When receiving an email, the receiving server retrieves the public key from the sender's DNS
The receiving server uses the public key to verify the signature
If the signature is valid, the email is considered authentic

Despite its cryptographic strength, DKIM has several limitations and vulnerabilities that can be exploited to bypass its protection.

Attack Methodology

This attack involves exploiting various limitations and vulnerabilities in DKIM to send spoofed emails that bypass DKIM checks.

Selector Enumeration and Key Theft

Identifying and exploiting DKIM selectors

This variant involves identifying DKIM selectors used by a domain and attempting to steal or compromise the private keys.

Selector Enumeration Example

Identifying DKIM selectors

# Identify DKIM selectors from existing emails # Extract the DKIM-Signature header from an email from the target domain # Look for the s= parameter, which indicates the selector # Example DKIM-Signature header DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1609459200; h=from:to:subject:date:message-id; bh=... # Check if the selector exists in DNS dig +short selector1._domainkey.example.com TXT # Example output v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEfyZ...

Explanation: In this example, the attacker identifies a DKIM selector (selector1) used by the target domain (example.com) by examining the DKIM-Signature header in an existing email. The attacker then confirms that the selector exists by querying the DNS record for selector1._domainkey.example.com. If the attacker can compromise the private key corresponding to this selector, they could forge DKIM signatures for the domain.

Key Theft Vectors

Attackers can attempt to steal or compromise DKIM private keys through various vectors:

Server compromise: Gaining access to mail servers where keys are stored
Backup compromise: Accessing backups that contain private keys
Key generation issues: Exploiting weak key generation processes
Insider threats: Obtaining keys from insiders with access
Third-party compromise: Compromising third-party email providers

Weak Key Exploitation

Exploiting weak DKIM keys

This variant involves identifying and exploiting weak DKIM keys that can be factored or broken.

Weak Key Identification Example

Identifying weak DKIM keys

# Check the key length of a DKIM public key dig +short selector1._domainkey.example.com TXT # Example output for a weak 512-bit key v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEfyZ... # Example output for a strong 2048-bit key v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87...

Explanation: In this example, the attacker checks the length of a DKIM public key by examining the p= parameter in the DNS record. A shorter key (e.g., 512 or 768 bits) may be vulnerable to factoring attacks, while a longer key (e.g., 2048 bits) is more secure. If a weak key is identified, the attacker may be able to factor it and derive the private key, allowing them to forge DKIM signatures.

Key Strength Recommendations

DKIM key strength recommendations have evolved over time:

512 bits: Originally used, now considered extremely weak
768 bits: Previously common, now considered weak
1024 bits: Minimum recommended in RFC 6376, becoming weak
2048 bits: Currently recommended minimum
4096 bits: Provides additional security margin

Header Field Exclusion

Exploiting incomplete header field coverage

This variant exploits the fact that DKIM only signs specific header fields, allowing attackers to modify unsigned fields.

Header Field Exclusion Example

Exploiting unsigned header fields

# Examine a DKIM-Signature to identify signed headers # Look for the h= parameter, which lists the signed headers # Example DKIM-Signature header DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1609459200; h=from:to:subject:date:message-id; bh=... # In this example, only the following headers are signed: # - From # - To # - Subject # - Date # - Message-ID # Headers that might not be signed include: # - Reply-To # - CC # - BCC # - Content-Type # - Content-Transfer-Encoding

Explanation: In this example, the attacker examines the DKIM-Signature header to identify which headers are signed (listed in the h= parameter). Headers that are not signed can be modified without invalidating the DKIM signature. For example, if the Reply-To header is not signed, the attacker could modify it to redirect replies to their own email address.

Commonly Unsigned Headers

Headers that are commonly not signed by DKIM include:

Reply-To: Can be modified to redirect replies
CC/BCC: Can be modified to include additional recipients
Content-Type: Can be modified to change how content is displayed
Content-Transfer-Encoding: Can be modified to change how content is encoded
X-* headers: Custom headers often used for internal routing or filtering

Body Canonicalization Exploitation

Exploiting DKIM body canonicalization

This variant exploits how DKIM canonicalizes the email body before signing, allowing certain modifications that don't invalidate the signature.

Body Canonicalization Example

Exploiting relaxed canonicalization

# Examine a DKIM-Signature to identify the canonicalization method # Look for the c= parameter, which specifies the canonicalization method # Example DKIM-Signature header DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1609459200; h=from:to:subject:date:message-id; bh=... # In this example, c=relaxed/relaxed means: # - Header canonicalization: relaxed # - Body canonicalization: relaxed # With relaxed body canonicalization: # - Trailing whitespace in lines is ignored # - Multiple whitespace characters are reduced to a single space # - Empty lines at the end of the body are ignored

Explanation: In this example, the attacker examines the DKIM-Signature header to identify the canonicalization method used (c=relaxed/relaxed). With relaxed body canonicalization, certain modifications to the email body won't invalidate the DKIM signature. For example, the attacker could add or remove whitespace, or add empty lines at the end of the body.

Canonicalization Methods

DKIM supports two canonicalization methods:

Simple: Minimal changes to the message, more strict
Relaxed: More forgiving of whitespace and line ending changes

The canonicalization method is specified in the c= parameter of the DKIM-Signature header, in the format c=header/body (e.g., c=relaxed/simple).

Impact

This attack allows attackers to:

Send spoofed emails that bypass DKIM checks
Modify unsigned headers without invalidating DKIM signatures
Make subtle changes to email bodies without invalidating DKIM signatures
Conduct phishing attacks with higher success rates
Potentially damage the reputation of legitimate domains

Detection

Organizations can detect these attacks by:

Monitoring for emails with suspicious modifications to unsigned headers
Implementing additional email authentication mechanisms (SPF, DMARC)
Using email security solutions that check for DKIM anomalies
Regularly auditing DKIM configurations and key strength

Mitigation

To protect against these attacks, organizations should:

Use strong keys: Use at least 2048-bit RSA keys for DKIM
Sign all important headers: Include all security-relevant headers in the DKIM signature
Use simple canonicalization: Consider using simple canonicalization for better security
Implement DMARC: DMARC can help prevent domain spoofing even if DKIM is bypassed
Rotate keys regularly: Regularly rotate DKIM keys to limit the impact of key compromise
Protect private keys: Securely store and manage DKIM private keys
Monitor for weak keys: Regularly check for and replace weak DKIM keys

Testing

Security professionals can test for this vulnerability using the following approach:

Identify DKIM selectors used by the target domain
Check the strength of DKIM keys
Analyze which headers are signed by DKIM
Test modifying unsigned headers to see if they bypass security checks
Test making subtle changes to the email body to see if they invalidate the DKIM signature
Check if emails with these modifications are delivered and how they are displayed to recipients

References

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
Chen, J., Duan, H., Weaver, N., Paxson, V., & Jiang, J. (2021). "Measuring and Mitigating Email Sender Spoofing Attacks." In Proceedings of the 30th USENIX Security Symposium.
Foster, I. D., Larson, J., Masich, M., Snoeren, A. C., Savage, S., & Levchenko, K. (2015). "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.

Back to Email Authentication Attacks Next: SPF Bypass