E-mail is NOT secure.
Let’s have a bit of history so you can understand this from first principles. What you know as e-mail transmission, Simple Mail Transfer Protocol (SMTP), started life out as RFC778 way back at the dawn of Internet time (1981), before then there was the Mail Transfer Protocol (one assumes it was not Simple) and before that it was wild west of non-standard ways based on the network being used. The current Draft Standard for SMTP is RFC5321 Simple Mail Transfer Protocol.
From RFC 5321 Section 7.1:
‘7.1. Mail Security and Spoofing
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else.’
The most common cyber-attack vector is phishing.
I tell all my clients this and generally their immediate response is “we have training for our staff, so they know not to click on links in emails from people they do not know”. My comeback to that is “OK so that addresses one element of The Golden Triangle for achieving increased security (allegedly wrongly attributed to Bruce Schneier) but what about the other elements?”. Their reply is usually “well we have sandboxes and end point protection, and…….(insert whizzy expensive technology based silver bullet here)”. It is at this point that I fire up the browser (I really wanted to say Fire up the Quattro there) and check the status of the SPF, DKIM and DMARC settings for the client. So, what am I talking about?
- Sender Policy Framework (SPF) RFC7280.
- Domain Keys Identified Mail (DKIM) RFC6376.
- Domain-based Message Authentication, Reporting and Conformance (DMARC) RFC7489
Now for The Rest of the Story
‘In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [RFC5321] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. This specification applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope. However, some message systems may use information from the contents to create the envelope.’
The above paragraph from Section 1.1 of Internet Message Format, which is RFC5322 is crucial when it comes to understanding how e-mail can be spoofed.
When a user views an e-mail in their client it will usually only show the “From” address. This address identifies the author of the email. That is, the mailbox of the person or system responsible for writing the message. This is sometimes called the 5322:From address because this Originator Field is specified in Section 3.6.2 of RFC5322 and is mandatory. The important thing to note here is the e-mail client uses the “From” address that is in the content of the message, not the envelope which the message came in.
There is also the “Mail From” address which identifies the sender and specifies where to send return notices if any problems occur with the delivery of the message, such as non-delivery notices. This appears in the envelope portion of an email message and is not usually displayed by your e-mail application. This is sometimes called the 5321:MailFrom address or the reverse-path address and, unsurprisingly, is specified in RFC5321.
Why does e-mail have two ‘From’ addresses?
The 5322.From address is contained within the ‘Originator Fields’ specified in RFC5322:
‘The originator fields indicate the mailbox(es) of the source of the message. The “From:” field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message.’
The 5321:MailFrom address is an interesting field, in that it can be changed as the e-mail moves through the transmission subsystem, an example being:
‘3.9. Mailing Lists and Aliases
An SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery. When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope (“MAIL FROM:”) MUST be changed to be the address of a person or other entity who administers the list.’
And reading this section further it states:
‘However, in this case, the message header section (RFC 5322 [4]) MUST be left unchanged; in particular, the “From” field of the header section is unaffected.’
Thus, in plain English, the 5321:MailFrom is not a reliable indicator of who sent the e-mail, so your client relies upon and displays the 5322:From address.
Well that’s not a problem is it?
Actually, yes it is, and now I am going to show you how to send a spoof e-mail, so usual caveats apply – if you break the law and get caught don’t come crying to me, I am showing you how easy it is to send a spoof e-mail to yourself, so you appreciate why you need to use SPF, DKIM and DMARC. My spoofer of choice is https://emkei.cz/ though a search of the internet will bring back plenty of other websites you could use. Below is an e-mail I received from Donald Trump:
I think that could be categorised as fake news.
What is not fake news though is that whitehouse.gov does not have DKIM or DMARC set up. We can see this by looking at the following snippet of the source code for the e-mail I received from Donald.
Authentication-Results: spf=softfail (sender IP is 46.167.245.206)
smtp.mailfrom=whitehouse.gov; otsupport.pro; dkim=none (message not signed)
header.d=none;otsupport.pro; dmarc=fail action=none
header.from=whitehouse.gov;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
whitehouse.gov discourages use of 46.167.245.206 as permitted sender)
It is important at this point to cast our minds back to the two-address paradox. SPF uses a DNS TXT record to provide a list of authorized sending IP addresses for a given domain. Normally, SPF checks are only performed against the 5321:MailFrom address. This means that the 5322:From address is not authenticated when you use SPF by itself. This allows for a scenario where a user can receive a message which passes an SPF check but has a spoofed 5322.From sender address.
What we see above is that SPF is setup on the whitehouse.gov domain but that the result of ‘softfail’ indicates that ‘The SPF record has designated the host as NOT being allowed to send but is in transition’. (I so want to say something sarcastic about the Whitehouse transitioning)
When you use DMARC, the receiving server also performs a check against the 5321.From address. Like the DNS records for SPF, the record for DMARC is a DNS TXT record. DMARC TXT records validate the origin of email messages by verifying the IP address of an email’s author against the alleged owner of the sending domain. The DMARC TXT record identifies authorized outbound email servers. Destination email systems can then verify that messages they receive originate from authorized outbound email servers.
What have we learnt?
We can see that my e-mail client tried to authenticate using SPF, DKIM and DMARC, which are there to allow the client to confirm the validity of the sender. But as the e-mail ‘originated’ from a domain that was not configured correctly I received an e-mail from Donald.
Now think about your domain, and your supply chain. Without these simple safeguards in place it is a trivial task for a threat actor to send an e-mail from your CFO to a client to tell them that you have changed banks and that invoices are to be paid to the new account, or for the CEO to send an e-mail to the accounts department telling them to pay a supplier right now to secure a great deal (https://www.csoonline.com/article/3238187/fraud/business-email-fraud-financial-scams-under-the-guise-of-authority.html).
True these three things alone will not stop a determined threat actor, but they will help slow them down, and maybe they will go looking for an easier target. The bonus is they are the cheapest risk mitigation measures I have come across.
Right now, you are thinking about checking my domain to see if I practice what I preach, I will save you the effort, yes I do.