Mail Security - SPF - WTF

Today I'm going to explain the three technologies that can be used to secure mail and protect against spam & spoofing(DMARC,DKIM & SPF) however given each is just as important I'm going to split into three posts. I'll also explain how an attacker can leverage them to attack users and aid in phishing attacks. Before I get started, this is purely a quick blog explaining what each one does, all three can be confusing but hopefully after reading you'll be a bit less bewildered!

Mail technologies are important to understand from all sides; for system administrators responsible for setting up these technologies, blue teams for defending your organisation and red teams for abusing misconfigurations and validating phishing domains, C2 redirectors and other mail servers.

Part 1 will give you an overview of the three technologies and dive deep into SPF creation and explanation.

Mail Security-Specific DNS Records

In addition to the standard DNS records, these can be dialed down more as each can provide multiple functions. As an example, TXT records can contain lots of information relating to securing a domain and restricting access to information and data. There are three technologies used to secure and protect mail going to and from a domain which are contained within TXT records. These three technologies are; SPF, DKIM & DMARC.

DomainKey Identified Mail (DKIM), Sender Policy Framework (SPF) and Domain-Based Message Authentication Reporting & Conformance(DMARC) are three methods that can protect your domain and organisation from email spamming, spoofing, and phishing attempts.

SPF allows you  to specify which email servers are legitimate servers for your domain.

Whereas DKIM allows you to attach a DomainKey signature to your outgoing mail. The receiving server then verifies the validity of the key and either accepts or rejects the mail based on the outcome.

SPF and DKIM are frequently used in combination since they attack email security problems from two different angles.

Now time to take a deep dive into  how each of these works and how an attacker can leverage them to not only spoof emails but also secure false domains to legitimise them and bypass defensive measures!

Sender Policy Framework(SPF)

SPF like all three mail technologies described in this section is used to validate mail being transferred to and from a domain. It is an email authentication method designed to detect forging or spoofed sender addresses during the delivery of the email. It is however limited  to detect a forged sender claimed in the envelope of the mail.

To correctly configure SPF, there are a few questions that you need to consider;

1. Which server or servers do you want mail from the domain to come from?

• It is worth considering all legitimate mail servers that might be involved in mail transfer including ISP mail servers to reduce potential issues further down the line.

1. How do you want to handle non-legitimate mail being sent?

• Do you want messages that are not legitimate to be rejected outright, or should the message be classified as a soft fail, meaning that the email will be subjected to further checks to validate the authenticity of what has been sent.

Once you've decided, you will likely want to configure a SPF record to define how mail is handled.

Your First SPF Record Setup

First and foremost, when configuring SPF, DKIM or DMARC all configuration is done inside a TXT record. Therefore you will need to configure this in your DNS records on your hosting provider.

Here is an example SPF record broken down, it is important to add in specifics otherwise you run the risk of legitimate emails being blocked or restricted thus producing false positives.

TXT @ "v=spf1 a include:_spf.zsec.uk ~all"

A SPF record always starts with the v= element which indicates which version of SPF is being used. The most common version supported and understood by services is spf1.

Typically the version indicator will have one or more terms. These terms define the rules for which hosts are allowed to send mail from the domain, or provide additional information for processing the SPF record. Terms are made up of mechanisms and modifiers.

The example record above can be broken down as explained below:

• TXT: The DNS zone record type; SPF records are written as TXT records
• @: In a DNS file, the "@" symbol is a placeholder used to represent "the current domain", for example zsec.uk.
• v=spf1: Identifies the TXT record as an SPF record, in this case it is utilizing SPF Version 1.
• a: This authorises the hosts identified in the domain's A record(s) to send e-mail, therefore if you have multiple IP addresses they will all be allowed to send mail from the domain. This also accepts CIDR notation, so technically you could have 1.2.3.4/16 as an accepted range to send emails on behalf of the domain.
• include:: This authorises mail to be sent on behalf of the domain from zsec.uk. The "include" mechanism makes it possible for one domain to designate   multiple administratively independent domains.  For example, a vanity    domain "zephr.fish" might send mail using the servers of    administratively independent domains zephrsec.com and zsec.uk. zephr.fish's SPF record  could say   IN TXT "v=spf1 include:zephrsec.com include:zsec.uk -all"
• ~all: Outlines that this list is all inclusive, and no other servers are allowed to send e-mail. There are a few options for this section of the record:

-all The minus “-” in front of “all” means that any senders not listed in this SPF record should be treated as a "hardfail", ie. they are unauthorised and emails from them should be discarded.

~all The tilde “~” in front of “all” means that any servers not listed in this SPF record should be treated as a "softfail", ie. mail can be allowed through but should be tagged as spam or suspicious.

+all The plus "+" in front of "all" means that any IP is a pass and therefore is very permissive.

Exploiting Insecure SPF Records

With all security controls, there are always going to be ways to exploit these for nefarious purposes. SPF is often exploited if not configured properly and spammers/phishers alike will leverage misconfigurations to attack end users of the service.

When you've setup SPF you most likely, will not see any significant changes in terms of security and spam. SPF is originally an altruistic protocol, so it does not provide any advantages to anyone who publishes the SPF policy. Theoretically, if you implemented SPF, this protocol could protect someone else from receiving fake emails from your domain. But in fact, even this assumption is not true, because the results of applying SPF are rarely used directly.

Without SPF or with a misconfigured SPF record, an attacker can essentially pretend to be your business and spoof emails that appear to come from your domain. An example would be sending an email appearing to come from a financial organisation and asking the user to provide their debit or credit card credentials.

This is also a common way to get passwords whereby an attacker constructs a false email in an attempt to phish credentials from a user. The attack leans upon misconfigured SPF as by spoofing the sender an attacker can improve the legitimacy of the email and thus coerce a user into providing sensitive information.

How To Enable & Setup SPF?

Now we've gone through how a record is constructed and why you might want to set one up, you are probably wondering how does one go about building one?

First start off by gathering the IP addresses and services that you currently use to send email.  Lots of businesses and organisations send email from lots of different locations.

Take all of the known locations and create a list of them, remember to account for  whether any of the following is used to send email on behalf of your company:

• Different servers; web, application, content management system
• Any on premise or cloud mail servers; Microsoft Exchange, Office 365, Google Cloud, Azure, AWS, etc
• Your ISP’s mail server

Next up create a list of all the domains for your brand or company, if you're anything like me you probably own a few domains and subdomains.  Some of these domains will be used to send email and run mail services therefore should be included in your SPF setup.

One key point that a lot of businesses forget is to create SPF records for not just domains that send emails but also ones that don't. Once you have protected your sending domains with SPF, the first thing an attacker will do is try to spoof your non-sending domains.

SPF authenticates a sender’s identity by comparing the sending mail server’s IP address to the list of authorized sending IP addresses published by the sender in the respective DNS record. As I explained the structure earlier on in this article you'll want to build a record starting with the version tag.

1. Start with v=spf1 (version 1) tag and follow it with the IP addresses(ipv4 and ipv6) that are authorized to send mail. v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 ip4:8.7.6.5 ip6:2a01:4f8:d11:1337::2
2. If there are third party providers in the mix, you must use the include: operator;  v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 ip4:8.7.6.5 ip6:2a01:4f8:d11:1337::2 include:spf.protection.outlook.com this example includes office 365 however remember if you have multiple providers you'll want to include them.
3. Once all the authorised IP addresses and include statements have been added, end your record with an ~all or -all tag which has been explained earlier. Our finished example record will look like this:

v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 ip4:8.7.6.5 ip6:2a01:4f8:d11:1337::2 include:spf.protection.outlook.com -all

Using -all makes this a more secure solution as if the sender does not match the SPF record the mail will be rejected.

4. Once we've got our record the next thing to do is actually publish it to our DNS provider, this is done via a TXT record and should look similar to below:

TXT @ "v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 ip4:8.7.6.5 ip6:2a01:4f8:d11:1337::2 include:spf.protection.outlook.com -all"

5. Finally the most important step, test your newly created SPF record with a SPF checker. This will enable you to see what recipients see: a list of the servers authorised to send email on behalf of your sending domain. If one or more of your legitimate sending IP addresses is not listed, then you can update your record to include it. Keep tweaking the setup till you have all your IP addresses and settings in place as there may be false positives when starting out.

Hopefully the above has been useful for explaining SPF and how it is created, setup and secured. Next up is part 2 all about DKIM!