Faking e-mails: Why it is even possible

Sometimes it’s easy to spot phishing e-mails just by checking the “From” field. However, that’s not always the case; making a fake e-mail indistinguishable from a genuine one actually is possible. If an attacker knows how to do such a thing, the targeted organization is really in trouble. Most people wouldn’t have a second thought before clicking on a malicious link or file that they got in an e-mail seemingly from their boss or their top client — and it’s hard to blame them, especially if there’s no way to tell the e-mail was spoofed.

But why is it possible to forge a perfect fake e-mail in the first place? Andrew Konstantinov’s talk on e-mail authentication for penetration testers, at the 36th Chaos Communication Congress, answers this very question and gives some insight into the effectiveness of protection from e-mail spoofing.

Problem 1: E-mail must flow

E-mail is a staple communication method of the modern world, and every organization relies heavily on e-mail in its daily operations. Though we don’t think much about the technology when everything goes smoothly, if all of a sudden e-mails start going missing, you can be sure everybody will notice. Therefore, reliability is generally the top priority of every e-mail server administrator. E-mail simply has to be sent and delivered, no matter what.

The implication here is that every organization’s e-mail server has to be as compatible as possible with everything else in the world. And therein lies the problem: E-mail standards are badly outdated.

Problem 2: The e-mail protocol with no authentication

The main protocol used both for client-to-server and server-to-server e-mail communications is SMTP. This protocol was first introduced in 1982 and last updated in 2008 — more than a decade ago. And like many other ancient standards, SMTP is a security nightmare.

First let’s take a look at what your typical e-mail message consists of:

• SMTP envelope. This part is used for server-to-server communications and is never shown in e-mail clients. It specifies the sender’s and recipient’s addresses.
• E-mail clients display this part. It’s where you’ll find the familiar “From,” “To,” “Date,” and “Subject” fields that you see for any e-mail.
• Message body. The e-mail text and other contents.

What’s in an e-mail message. Image source

The main problem is that the standard provides no means for authentication. Responsibility for the sender’s address field — in both the SMTP envelope and the header — lies completely with the sender’s server. What’s worse, the sender’s address in the SMTP envelope doesn’t have to match the one in the header (and the user sees only the latter).

Also, though the standard specifies one header per e-mail, SMTP doesn’t actually enforce the limit. If a message contains more than one header, then the e-mail client simply chooses one to show to the user.

It doesn’t take a professional hacker to see a lot of room for trouble here.

The e-mail protocol provides no means of making sure an e-mail actually came from the indicated sender

Problem 3: Fake in, fake out — gotta watch them both

To complicate things even more, every e-mail communication involves two parties, so this no-authentication problem actually unfolds into two subproblems.

On the one hand, you definitely want to be sure any e-mail you receive was actually sent from the address indicated. On the other hand, you probably want to prevent other people from sending e-mails that seem to be coming from your address. Unfortunately the standard can’t help with any of that.

It’s no surprise that the SMTP protocol was so frequently abused that people started devising new technologies to fix the flaws mentioned above.

Fix attempt 1: Sender Policy Framework (SPF)

The idea behind the Sender Policy Framework is rather simple: The receiving server should be able to check whether the address of the server that actually sent an e-mail matches the address of the genuine e-mail server associated with the domain.

Unfortunately, that’s easier said than done. The SMTP standard has no means to perform such a check, so any method of authentication would have to be added on top of the existing stuff. Getting such technology to the point of becoming a “proposed standard” took a decade. Today only about 55% of the top 1 million servers use SPF, and most use quite relaxed policies.

SPF faces loads of other problems here as well, such as messy architecture that makes it easy to misconfigure, certain ways to bypass it using other servers hosted on the same address, and so on. But SPF’s fatal flaw is that it checks only the address indicated in the SMTP envelope and completely ignores the “From” field in the header — the one that a user actually sees.

Outcome:

• SPF helps check if an e-mail came from a genuine server.
• The address visible to users still can be faked.

Fix attempt 2: DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail approaches the problem differently: DKIM cryptographically signs the message header and part of the message body using a private key, which signature can be verified using a public key that is published in the Domain Name System.

It is worth mentioning, however, that DKIM is not supposed to encrypt the whole message. Rather, it appends a cryptographically signed addendum to it. That is a problem. The crypto part is hard to modify, but deleting the signature entirely and crafting a fake message is easy — and the results are undetectable.

DKIM is hard to implement because it involves issuing and managing cryptographic keys. Also, misconfigured DKIM can enable an attacker to preserve the genuine DKIM signature in a message while completely changing its header and body.

Outcome:

• DKIM lets you digitally sign messages, helping assure the receiving server that a message really came from you.
• It’s hard to implement because it involves cryptographic key management.
• Forgers can simply delete the signature while faking an e-mail in your name.
• Certain misconfigurations can result in fake messages containing genuine DKIM signatures.

Fix attempt 3: Domain-based Message Authentication, Reporting and Conformance (DMARC)

Despite its rather lengthy name, the Domain-based Message Authentication, Reporting and Conformance protocol is actually easier to understand than SPF or DKIM. It is really an extension of the two that fixes their most glaring omissions.

First, DMARC helps the domain administrator specify which protection mechanism — SPF, DKIM, or both — the server is using, which really fixes the DKIM mechanism. Second, it fixes SPF as well, providing a check of the address specified in the header’s “From” field (the one that is actually visible to a user), on top of the check of the sender address in the SMTP envelope.

The downside is that the DMARC protocol is relatively new, is not yet a proper standard (RFC 7489 defines it not as standard or even proposed standard, but only as “Informational”), and is not as widely used as it should be. According to this study of 20,000 domains, only 20% had adopted DMARC at all by 2019, and only 8.4% had strict policies.

Unfortunately, DMARC adoption is not yet widespread, and in many cases it is used with “none” policy. Image source

Outcome:

• Fixes the most important issues of SPF and DKIM.
• Not widely adopted yet, and therefore not as effective as it could be.

How to protect yourself from e-mail spoofing

To sum up: Faking e-mails is still possible because the SMTP protocol wasn’t designed with security in mind, so it lets an attacker insert any sender’s address in a forged e-mail. In the past few decades, certain protection mechanisms emerged — namely, SPF, DKIM, and DMARC. However, for those mechanisms to be effective, they have to be used — and implemented correctly — by as many e-mail servers as possible. Ideally, they should be implemented on every mail server on the Internet.

In addition, it is important to consider that some mail relay server may start adding something to the letters due to configuration errors, and this will automatically fail the DKIM check. Also, we must not forget that these technologies will help to deal with mass threats, but to protect your business from sophisticated e-mail attacks you should still use additional protective solutions both on workstations and on the mail server.

Here are some recommendations for e-mail protection:

• Adopt SPF at the least. Make sure that it is configured properly. Also keep in mind that resourceful attackers can bypass SPF (more details in the talk).
• Implement DKIM for better protection. It might be a bit harder, but it’s worth considering. And again, make sure it’s configured properly (some tips on what attackers look for).
• Adopt DMARC, ideally, because it fixes most of SPF’s and DKIM’s exploitable flaws.
• Check your configuration for incoming e-mails as well.
• Use security solutions that support modern authentication mechanisms. For example, use Kaspersky Security for Mail Servers or Kaspersky Security for Microsoft Office 365.