Email (in)security

Sending emails relies mainly on SMTP, the Simple Mail Transfert Protocol. This protocol is actually quite old: the first traces date back from the 70’s, and the first standardisation took place in 1982 (RFC 821). It is primarily a very simple and insecure protocol, although multiple additional protocols have developed to protect emails and avoid SPAM. In this blog post we review these different protection mechanisms.

How emails work

But first, how are emails supposed to work?

Imagine user@gmail.com wants to send an email to victim@aol.com. The email is not sent directly from one to the other. user@gmail.com has to deliver the email to his mail server (gmail.com), that will forward the email to the mail server of the recipient (aol.com). The addressee wil then fetch the email from the server using his mail client, his phone, or read the email using the webmail interface.

The communication between the sender (someuser@gmail.com) and the mail server (gmail.com) relies on SMTP, but it is usually well protected: the user has to provide a username and password, and most providers enforce the use of TLS encryption.

The communication between the recipient (victim@aol.com) and his mail server (aol.com) can take place using different protocols like POP, IMAP or ActiveSync that all require a password. This communication is usually also protected using TLS encryption.

However, between the mail servers, there is no authentication, and there is usually no encryption, only pure old SMTP and trust.

Email insecurity

So, how can an attacker use this lack of authentication and encryption between the two mail servers?

1. SPAM

The first and most obvious possibility is SPAM, or undesired email. Any device connected to the internet, anywhere in the world, is allowed to send emails to aol.com. Hackers can perform this action by either renting cheap servers or using a botnet : an army of compromised servers, computers or IoT (Internet of Things) devices.

2. Eavesdropping

Because the communication between the mail servers is not encrypted, if the hacker controls any switch or router located between the mail servers, he will be able to sniff and read the content of the emails exchanged between the servers.

3. Address spoofing

As there is no authentication between the mail servers, anyone can send an email to victim@aol.com, pretending to be someuser@gmail.com.

4. Typosquatting

Even if there is a protection against address spoofing, like DKIM (see below), the attacker may use a domain name that looks similar to gmail.com, like gmall.com. If victim@aol.com is not attentive enough, like on a Monday morning before his first coffee, he might not notice the incorrect from email address.

It is especially complicated with Internationalized Domain Names (IDN) : domain names may contain non-ASCII characters that look very similar to classical ASCII characters. A classical example is Cyrillic character a (unicode U+0430), that looks identical to Unicode character U+0061 (Latin small letter a).

Protections

Over time, some protection techniques have been implemented…

Heuristics

The first protective measures are simple to activate, because they take place only on the receiving server. However, they are absolutely not bulletproof!

With content analysis, the receiving server can block emails based on content and keywords like viagra or rolex. This is the most ancient technique used to filter SPAM.

If a server (IP) is found to send SPAM or fake emails, it’s IP can be added to a blacklist. Such lists can be found online, like spamhause SBL. Receiving servers can use these lists to block incoming emails.

A lot of SPAM protection services like Barracuda Spam Firewall check the creation time of the source domain and block emails coming from a recently created domain (less then a few weeks of months). This allows to protect the receiver from spammers that quickly created a new domain to send spam.

DomainKeys Identified Mail (DKIM)

With DKIM, the sending email server will add a signature to the email, using a private key.

The corresponding public key, that the receiving server can use to verify the signature, can be fetched using a DNS query.

This allows to ensure that the email has not been altered during transmission between the two mail servers, and thus guarantees integrity.

Sender Policy Framework (SPF)

With SPF, the administrator of the sending domain (gmail.com) can configure a special DNS record that specifically lists servers that are allowed to send emails from this domain (@gmail.com). The receiving server can check the DNS server to verify that the sending server is allowed to do so.

This technique protects against address spoofing.

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

DMARC builds on top of SPF and DKIM. It also relies on a DNS record, to indicate if a sending domain is using DKIM and/or SPF. The DMARC DNS record can also give instruction on what to do if one of these mechanisms fail, and how to notify the sender domain in case of failure.

Reverse DNS check

The receiving email server can check that the IP address of the sending server does actually belong to this domain. It does so by performing a reverse DNS lookup:

Unlike SPF, DKIM and DMARC, reverse DNS checks require the administrator of the sending domain to add a DNS PTR record in the DNS server that is responsible for the public IP addresses of his servers.

This acts like a whitelist (as opposed to the blacklists mentioned above) and protects the receiver from a spammer that is using compromised devices and botnets.

End-to-end encryption

This technique consists in using TLS for the communication between the two mail servers (SMTP over TLS). It’s actually misleading as the encryption does not take place between the users, but only between the servers. It does however protect against eavesdropping between the servers.

Of course, it requires both servers to support TLS, but nowadays this is the case for most providers (Gmail, AOL, gmx.de etc.) and it is also supported by most mail servers like Postfix.

Final words

Different techniques exit to protect users from malicious emails. However, none of them is bulletproof. Moreover, some of these techniques (like domain age and reverse DNS check) may block legitimate emails. In anyway, for the time being, you should never blindly trust an email!

This blog post is licensed under CC BY-SA 4.0