Faking e-mails: Why it is even possible

[harlan4096]

Phishing and business e-mail compromise attacks rely on fake e-mails. But why is it so easy for attackers to make them so convincing?

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.

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.
...

Continue Reading