How We Can Stop Email Spoofing

According to our research, 98 percent of the internet is vulnerable to this attack. And here’s how our tool, SpoofCheck, can help us bring a stop to it.

Most web domains are not protected against email spoofing, which is a relatively easy problem to solve. If you’re concerned that your domain may be vulnerable to spoofing, check out SpoofCheck, our tool that diagnoses web and email domains. (Please note - SpoofCheck is temporarily down for upgrades.) 

What We Discovered

To determine the prevalence of email spoofing, Bishop Fox researchers scanned the Alexa top million-ranked internet domains. The results speak for themselves.

Forty percent of the domains had SPF records, but only two percent had both Sender Policy Framework (SPF) and a strict DomainKeys Identified Mail (DKIM). This means that 98 percent of the top million domains are vulnerable to email spoofing*. That’s nearly the entire internet.

Here’s what we can do to bring email spoofing to a complete stop.  

Email Spoofing TL;DR

Basically, email spoofing allows attackers to send emails from addresses that appear to belong to someone else. The attack is simple: SMTP, the protocol for sending emails, allows the sender to set the email address it is sending from freely. This video explains how an attack unfolds:

So now that we’ve covered that, let’s talk about the defenses against email spoofing.

Are There Defenses? Yes, But No One Uses Them

Sender Policy Framework (SPF)

SPF protects domains from email spoofing by defining the IP addresses that can send emails from that domain. SPF is defined as a DNS TXT record for the protected domain. An example of an SPF record follows:

~ % dig txt bishopfox.com
…omitted for brevity…

;; ANSWER SECTION:
bishopfox.com. 300 IN TXT
"v=spf1 include:spf.protection.outlook.com include:mailgun.org -all"
…omitted for brevity…

An SPF record defines the IP addresses permitted to send emails from its domain. If an email is received that was not sent from the whitelisted addresses, it fails the SPF check.

SPF was originally designed to work alone. A valid SPF configuration should cause any spoofed email to be either marked as spam or even rejected; however, this is not the case. 

The domain bishopfaux.com was actually protected with a strong SPF configuration, but I still received a spoofed email from it. This is because of two other technical controls.

DomainKeys Identified Mail (DKIM)

DKIM implements automatic email signing. A DKIM signature protects the integrity of the email, preventing the content from tampering before it is delivered. DKIM uses DNS TXT records to publish the public keys, so anyone can check an email’s validity.

Below is an example of a DKIM signature in an email header:

dmarc=pass (p=REJECT dis=NONE) header.from=bishopfox.com

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bishopfox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ecsj1jOpUDCYi4PYizF6HEhdhV8o+XAnAfKqKNF1XH4=; b=EDscYqOzyLfncr73+Zf+vOLz0BuVxDzqxavriHgKFp7AFWwjJ8UzQMkniY2fD8StKCzG6+u6O92pg204LkpPyEa5H+p73JO1f9xizF3cL2IQ2NM8+VoGcGtkdFFA08EQ2+cycH82JhvysBIvzarvu439yrKi6SumovEU3sxqqGY=

Received: from SN1PR05MB2224.namprd05.prod.outlook.com (10.169.124.148) by SN1PR05MB2221.namprd05.prod.outlook.com (10.169.124.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.6; Fri, 16 Sep 2016 16:53:01 +0000

Note the selector (s) and domain (d) fields. These are used to locate the public key, which is published as a DNS TXT record. Below is the command used to access the public key for the above signature:

~ % dig txt selector1._domainkey.bishopfox.com
…omitted for brevity…

;; ANSWER SECTION:
selector1._domainkey.bishopfox.com. 300 IN CNAME selector1-bishopfox-com._domainkey.stachliu.onmicrosoft.com.
selector1-bishopfox-com._domainkey.stachliu.onmicrosoft.com. 3600 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDB2Hx9MW9Z0HVLqcHDmMLnN4rXu49EJ4g6NpIRvS1pgkzirGTTsnf5ewRGYJJ83WJ2+Df0vI6E0jxUAvPC6Q/t9O97u7zz5/ggEKDKqpPzYwNIEdKPM7WxhLAflAj9unf/FVobgaN/FB2zZOkJiW3tbUA8H6nLKTX9LP99DiV3cQIDAQAB\; n=1024,1453269508,1"
…omitted for brevity…

Upon receiving a DKIM-signed message, mail servers access the public key from DNS and use it to verify the signature. A valid signature proves that the message has not been altered before delivery.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC is an email protection that works in tandem with SPF and DKIM. A DMARC record directs receiving mail servers on what to do with emails that fail SPF or DKIM checks. It is also stored as a DNS TXT record on the _dmarc subdomain.

DMARC’s most important field is p, which sets the policy for the domain. This can be set to p=none, p=quarantine, or p=reject. When the policy is set to quarantine, emails that fail SPF or DKIM checks are usually delivered to the spam folder. When the policy is set to reject, emails that fail the checks are not delivered at all.

Two other important fields are rua and ruf. These can be configured to define email addresses or web URIs to send reports when emails fail security checks. This can alert email providers to improperly configured records, improperly configured email setups, and email-spoofing attacks.

Below is an example of a DMARC configuration.

~ % dig txt _dmarc.bishopfox.com
…omitted for brevity…

;; ANSWER SECTION:
_dmarc.bishopfox.com. 300 IN TXT
"v=DMARC1\; p=reject\; pct=100\;rua=mailto:[email protected]\; aspf=r\;"
…omitted for brevity…

The above DMARC record sets the policy to reject, the strongest configuration to prevent email spoofing. This configuration causes all mail servers that respect DMARC to not deliver any emails that fail SPF and DKIM alignment.

Why Should I Care About DMARC?

Nearly all Mail Transport Agents, including the ones used by Gmail and Microsoft Exchange Server, default to relying on DMARC for direction on what action to take if an email fails SPF or DKIM. If the sending domain has no DMARC record or a record with a policy of none, the mail server fails open and delivers the email.

This means that if a domain does not have an SPF, DKIM, and strict DMARC record, it can be spoofed.

Most of the Internet is Not Protected!

So, how does this affect you? It depends on your services providers, but more than likely an attacker can send emails as:

• Your manager, co-workers, and company’s IT department
• Your bank
• Even government officials

And unless proper precautions are taken, attackers can send these emails to everyone in your organization.  But, despair not - there are protections available – you just need to use them.

Protect Yourself in Three Steps

Step 1: Review Protection Settings

Check the organization’s DNS records for SPF and DMARC. Work to ensure that the domain has a properly configured SPF record and a DMARC record with a policy of quarantine or reject. Bishop Fox has developed a tool for automatically identifying if a domain is sufficiently protected, which you can find here. (Please note - SpoofCheck is down for repairs at the moment.) 

There are some technical reasons why a domain cannot be protected with DMARC. One common reason is that your organization uses a managed email system that doesn’t support DKIM yet. In this case, implement a strong SPF record, and voice your concern to the email provider.

Step 2: Deploy Technical Controls

Configure the mail server to mark emails that fail SPF as spam. SPF was designed to be used alone, and 40 percent of the top million domains have SPF records. When examining the top thousand domains, that number increases to 70 percent. By configuring the mail server to respect SPF even without DMARC, it is protecting the domain from various future attacks. Since so few domains use it though, relying on it makes the internet more vulnerable.

Step 3: Plan Ahead

In 2016, two new Internet Engineering Task Force (IETF) drafts were proposed to improve the state of email security.

SMTP Strict Transport Security (SMTP-STS): provides requirements on how TLS certificates are validated, as well as the ability to report on and/or refuse to deliver messages that cannot be delivered securely.

Authenticated Received Chain (ARC): serves as support for DKIM style message authentication for mailing lists. It works by maintaining initial email authentication results across hops between other servers that would modify the message and previously cause email authentication to fail to verify when the message reaches its destination.

Say Goodbye to Email Spoofing

Protect users of our email infrastructure by configuring our SMTP servers to be secure by default. Let’s make email spoofing another chapter of internet history.

*We did not actually attempt to spoof these domains, and they may indeed have other email appliances in place for security. They do not have proper DKIM/DMARC records.