Misconfigured email servers open the door to spoofed emails from top domains

Wed, 22nd Jun 2016

FYI, this story is more than a year old

By Linus Särud, Security Researcher, Detectify

Missing SPF records are a common and long-standing security issue that puts sensitive information at risk. To get a better idea of just how widespread the problem is, the Detectify team decided to scan the 500 top-ranked Alexa sites for it. We found that less than half of those domains have configured email authentication correctly to prevent spoofed emails being sent from their domains, which means that users are at risk of receiving false emails appearing to come from domains that they trust. To prevent spoofed emails, all systems must be manually configured correctly to the highest standard of authentication. Unfortunately, the process is complicated, and often servers are misconfigured. The Detectify team has put together an extensive guide to help you check if your domain is at risk of forced spoofed emails, and also give you the tools to configure the authentication correctly.

Background

According to a study from 2014, 193 billion emails are sent every day. Email has become a system that is very essential to our lives, but it was first designed in 1982. The Internet was different back then, and the threats we see today were not obvious at that time.

Email spoofing is when someone sends an email with a forged sender address. Because email does not have authentication built in, spam, phishing and attackers use spoofing to take advantage of the trust that the spoofed domain carries, and to get users to give up sensitive information.

To protect a domain, you need to take action yourself, and configure authentication on your email servers, such as SPF and DMARC. It is however common that SPF is misconfigured, and for companies to be at risk without realizing it.

The Detectify team have done research on how common the issue with vulnerable email servers is, scanning the top 500 ranked sites on Alexa, the biggest provider of commercial web traffic data and analytics, to map the problem. We found that over 50% of the domains were vulnerable, either from having no authentication configured, or by having it misconfigured. This shows how widespread the problem really is, and that installing email authentication the right way can be difficult. In this guide, we explain how to evaluate and improve your authentication configuration and protect yourself from spoofing. At the end of the article, we also show the results of our research on vulnerable email servers and what this means in terms of security.

Examples of potential impact

An example of a spoofing could be sending an email appearing to come from a bank and asking the user to enter their credit card credentials. This is also a common way to get passwords.

The same method can be used to fool the media. One example is when someone sent an email that appeared to be a press release coming from the startup Fingerprint Cards in Sweden, announcing that they were about to be bought by Samsung. Media published the news, manipulating stock buyers and increasing the stock price of Fingerprint Cards increased by 50%. More on the story from The Verge.

Companies are well aware of the risks with spoofed emails coming from similar looking domains, and many have warnings on their websites, informing their customers and users to be careful:

Like this one from iTunes:

Or this one from Twitter:

The solutions available today: SPF, DMARC and DKIM

Today, there are three solutions available to protect yourself from spoofed emails: SPF, DKIM and DMARC. To effectively stop forged email being delivered, the sending domains, their mail servers, and the receiving system all need to be configured correctly for these higher standards of authentication.

SPF

SPF is a record that is applied to the DNS-record (a global database containing information about domain names and their corresponding address) that specifies what servers are allowed to send email using that domain.

SPF can be set up to have three different actions: hardfail, softfail och neutral.

SPF set up to hardfail means that all emails that are suspected to be forged or spam are rejected and not delivered.

If the SPF record is set up to softfail, emails are accepted / shown for the user, but marked with a warning as suspicious / spam.

If the SPF is set up as neutral, all emails are accepted.

Mode	Action
Softfail	Accept but mark
Hardfail	Reject
Neutral	Do nothing

Softfail is usually recommended as a first step when setting up a SPF record, this way you are able to check if legit emails are marked as spam or not, and then able to accept them as legit for future correspondence. After softfail has been in place for a while, it is common to switch the configuration to hardfail.

The problem is that many email providers today, for example Gmail, seem to skip marking emails as possible spam in the user inbox even if softfail is in place. That way, users are receiving suspected emails anyway, while thinking that they've already taken measures to protect themselves. In other words, just setting up a SPF record is not enough.

More on DMARC:

Why SPF is not enough

Despite email authentication methods that can be manually set up, email spoofing is still a problem. This is mainly due to the fact that authentication setup is often missing or misconfigured.

A lot of domains only use SPF with softfail, and have not implemented DMARC. Many believe that just using SPF is be enough, with the intended action configured to 'accept but mark'. The problem is that softfail in reality is as good as nothing if you are using some email providers, eg. Gmail, as explained in the earlier description about SPF. There is no marking or special treatment of these emails, at least not visible to the end user.

This also applies to using SPF with softfail, and implementing DMARC but with the action 'nothing'.

We decided to scan the internet for it

To find out how many domains were vulnerable, either by not having configured or by having misconfigurated email authentication, Detectify scanned the top 500 domains of Alexa (http://www.alexa.com/topsites) to get an idea of just how widespread this problem is.

We wrote a script to request those top domains' SPF- and DMARC-records. We then let another script go over the result to sort out what records, and combinations of records, we considered to be insufficient. This was all done with a few lines of Python.

The combinations we counted as vulnerable for spoofed emails were:

No SPF at all
SPF with softfail, only
SPF with softfail, and DMARC with action none

Results

If all these combinations are added up, 276 out of the 500 top domains scanned can be spoofed. That is over 50% of the world's top domains. And if half of the internet's most used domains can be spoofed, that probably means that it is even worse if you look at the entire internet.

According to our research, only 42% of the top 500 Alexa sites use DMARC. Of the ones that use only SPF, 40% of these use softfail. Since there are in fact ways to prevent this, the problem must be misinformation or lack of knowledge as to how vulnerable email without authentication configured can really be. Hopefully, we can raise awareness to mitigate this better in the future.

We contacted several of the top 276 domains to notify them of the vulnerability, of which a few got back to us and said that they would reconfigure their email configuration to protect themselves. They asked their names not to be disclosed in this article.

We also reached out to top domains that had configured their domains correctly to gain a deeper understanding of how straightforward or difficult they had found the process. One of them where Zendesk, whose VP of Security, Ryan Gurney, commented:

"Email spoofing is a big issue, and is one of the most sought out vectors for social engineering and phishing. We know that the correct use of SPF and DKIM can help to protect an email domain from these attacks. To setup SPF and DKIM correctly was challenging and required that we change the way we send email. However, we knew how important this was in order to maintain a high level of email security."

How to check if your domain is vulnerable

Get all the TXT-records for the domain (example.com) and look for the SPF-record, it will start with v=spf1. Then get the DMARC-record by looking at the TXT-record that begins withv=DMARC1 at the subdomain _dmarc (_dmarc.example.com).

If the SPF-record ends with "-all" that is enough. If it instead ends with "+all" or "~all" the DMARC-record needs to contain "p=reject" or "p=quarantine". In any other case it would be considered insufficient.

The SPF-record should exist on all subdomains as well, while DMARC is only on the main domain. p refers to the main domain, while sp controls subdomains.

How to resolve this?

If you are a smaller player and you have a good overview of the email servers used at your company, it is quite easy. Make sure that SPF and/or DKIM (SPF is often considered easier) is set up correctly, and configure DMARC to either reject or quarantine all failed emails – meaning that if you use SPF and someone tries to send a forged email, it will be rejected. Read our guide on how to do this here.

However, if you are a bigger company this actually can be harder to do. You need to map out every server that someone at your company uses to send emails with your domain. Support, marketing, and the reset-password email may all use different servers to mention a few. Forgetting to include one will result in them being unable to send emails.

If you suspect that you may have missed a server, we would recommend configuring DMARC in such way that it will not reject any emails, but will send you a report with the emails that should have failed. After making sure no server is missed, you then reconfigure DMARC to reject emails.

Share on: