Mail protection measures: SPF

Let’s face it. SMTP has been a mess for security since the beginning. But what is the state of the current efforts to secure this “not built with security in mind” service?

SPF (Sender Policy Framework)

As the name suggests, this method is thought to attack the problematic of sender address forgery.

The solution is based on DNS (great, another service designed without security in mind) and basicly consists on the organization establishing a policy that states which servers are able to forward email for this domain. This is performed through TXT records in the authoritative servers of the forementioned organization.

This way, when a server receives an email with a sender address belonging to this organization (in the MAIL FROM field), checks first if the IP address used in the HELO command is allowed to forward email for the domain. To do this check, it queries the following record from the domain’s DNS server:

carlos@pattern:~$ dig @208.67.222.222 nscglobal.com ns

; <<>> DiG 9.5.0-P2 <<>> @208.67.222.222 nscglobal.com ns
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26587
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nscglobal.com.                 IN      NS

;; ANSWER SECTION:
nscglobal.com.          85371   IN      NS      a.ns.joker.com.
nscglobal.com.          85371   IN      NS      b.ns.joker.com.
nscglobal.com.          85371   IN      NS      c.ns.joker.com.

;; Query time: 49 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Mon Jul  6 21:36:06 2009
;; MSG SIZE  rcvd: 88

Now that we know the nameservers for this domain, let’s query them for the TXT records, one of them being the SPF record:

carlos@pattern:~$ dig @a.ns.joker.com nscglobal.com txt

; <<>> DiG 9.5.0-P2 <<>> @a.ns.joker.com nscglobal.com txt
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58587
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available
carlos@pattern:~$ dig @a.ns.joker.com nscglobal.com txt

; <<>> DiG 9.5.0-P2 <<>> @a.ns.joker.com nscglobal.com txt
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43969
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;nscglobal.com.                 IN      TXT

;; ANSWER SECTION:
nscglobal.com.          86400   IN      TXT     “v=spf1 mx ip4:217.77.187.125 ip
4:195.217.168.151 ?all”

;; AUTHORITY SECTION:
nscglobal.com.          86400   IN      NS      a.ns.joker.com.
nscglobal.com.          86400   IN      NS      b.ns.joker.com.
nscglobal.com.          86400   IN      NS      c.ns.joker.com.

;; ADDITIONAL SECTION:
a.ns.joker.com.         7200    IN      A       207.44.185.10

[truncated for simplicity]

Let’s analyze the info contained in this text record,

nscglobal.com.          86400   IN      TXT     “v=spf1 mx ip4:217.77.187.125 ip4:195.217.168.151 ?all”

The SPF version used is 1 (v=spf1)

The MX records for this domain are allowed to forward email in behalf of it, obvious (mx).

Those two individual IP addresses (if not mask is specified /32 is used) are allowed as well.

And now the mystery record: ?all, this is different in the sense that it has attached a symbol at the beginning, in this case “?”.

Well, the truth is that all of them have one appended but the default is “+” and is not shown. The SPF record is, besides the version information, a list of so called mechanisms with modifiers attached. It’s similar actually to an ACL and is read sequentially as well.

Some of the most common mechanisms are all, ip4, ip6, a, mx, etc.

It’s clear that ip4, ip6 match ranges of IP addresses, while a, mx matches an A and MX record for this domain respectively. The meaning of all shouldn’t be a surprise either and why it appears always at the end… yes, it’s the default rule in an ACL and for this reason is one of the most important parts of a SPF record.

What about the modifiers? There are four of them:

“+” : Pass

“-” : Fail

“~” : SoftFail

“?” : Neutral

The action associated with each modifier is the following:

Result Explanation Intended action
Pass The SPF record designates the host to be allowed to send accept
Fail The SPF record has designated the host as NOT being allowed to send reject
SoftFail The SPF record has designated the host as NOT being allowed to send but is in transition accept but mark
Neutral The SPF record specifies explicitly that nothing can be said about validity accept
None The domain does not have an SPF record or the SPF record does not evaluate to a result accept

Notice that, in contrast with an ACL, unless specified, the default behaviour if a match is not found is to accept the email.

Finally we can read and interpret the SPF record for our company, with sad results…

Allow my MX’s, those two hosts and with the rest of the emails coming from IP addresses not belonging to the company, claiming to be from our company… We can’t say anything about the validity, so let them through! This is basicaly equivalent to not implementing a policy.

Most of the companies have a default rule like “-all” instead of “?all”, effectively dropping the spoofed emails.

As an example, the berliner-sparkasse.de SPF record:

carlos@pattern:~$ dig @ns.bankgesellschaft.de berliner-sparkasse.de txt

; <<>> DiG 9.5.0-P2 <<>> @ns.bankgesellschaft.de berliner-sparkasse.de txt
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7877
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;berliner-sparkasse.de.         IN      TXT

;; ANSWER SECTION:
berliner-sparkasse.de.  100     IN      TXT     “v=spf1 ip4:212.121.135.74 ip4:193.31.187.5 ip4:193.31.187.9 ip4:194.37.255.0/24 ip4:91.198.224.0/24 ip4:62.181.134.163 ip4:62.181.134.164 ip4:62.181.134.165 ip4:62.181.134.166 ip4:212.222.91.0/24 ip4:62.50.32.0/19 -all”

;; AUTHORITY SECTION:
berliner-sparkasse.de.  28800   IN      NS      sec2.dns.psinet.de.
berliner-sparkasse.de.  28800   IN      NS      sec1.dns.psinet.de.
berliner-sparkasse.de.  28800   IN      NS      sec3.dns.psinet.de.
berliner-sparkasse.de.  28800   IN      NS      ns.bankgesellschaft.de.

As you can see, the Berliner Sparkasse defines pretty clearly which networks are allowed to relay email for this domain and denies explicitly all the other incoming email.

Now what about the efficiency of this method? Well, its basis are the DNS entries so it has all the vulnerabilities inherent to this protocol. For a regular spammer it wouldn’t be practical to fake the DNS answers but for a very decided individual it could be easy to fake an email and the credibility would be respalded for the SPF mechanism itself.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s