Continues from Demystiphying phishing – Part 1
By Damien Mascré, David Verdin, Laurent Aublet-Cuvelier (RENATER)
Phishing aims to steal your secrets. Actually, it is even more malicious than that; it is designed to make you voluntarily hand over your secrets. A bit like a burglar asking you to deliver your furniture to a specific address.
Presented like that, it might be said that the approach is unlikely to be successful, yet phishing is still on the rise.
Why on earth is it successful? There are many reasons, but all are based on one premise: at some point, the user trusts a trap message and clicks on a link or opens an attachment which gives the hacker access to sensitive information. Whether this is due to a particularly well-crafted message, naivety or a temporary carelessness, the consequences are the same: the information is stolen and the hacker has ample opportunities to use it.
SMTP: breach of trust by design
The sender’s identity is one of the many elements that can inspire trust. No-one gives their login credentials to a stranger. However, they will do so using a form that they’re used to seeing or if asked by a trusted individual such as a colleague or a line manager. That’s SMTP’s major weakness: nothing prevents it from being used to impersonate someone else.
Seeing is believing, right? Well, the only thing that a user sees to believe that a message comes from a particular sender is the “From” header. More specifically, what is displayed instead of the “From” header by the email client, often its gecos. But, nothing could be easier than tampering with a “From” header. Today’s email clients even allow you to “Personalise the sending address”. Clearly, if there are no countermeasures in place, you can put whatever address you want in this “From” field and that’s what the email recipient will see when they want to know who sent the email.
Security through standards
Since at some point, anyone can fall into the trap, users need to be protected from themselves. It is important to prevent users from being exposed to phishing emails or, where doubt exists, that they have clear information about the nature of this doubt.
The objectives when protecting against phishing are therefore:
- not to display phishing emails to the user, just as browsers do not display a website with an invalid server certificate;
- to provide trusted information about the email displayed in the user’s client.
While much has been done to accomplish the first objective, very little has been done for the second.
There are four RFCs which, when combined, can be used to accomplish objective 1 while providing avenues for objective 2.
The common purpose of these RFCs is to allow the authentication of email servers. The idea is that only emails that actually come from a legitimate messaging infrastructure are received and not, for example, those from a farm of hacked machines.
SPF
The first – and oldest – is Sender Policy Framework (SPF). What is it used for? To specify which IPs are authorised to send emails on behalf of a domain. So, if you receive an email from an IP other than those declared in the SPF, there is a strong possibility they come from a malicious source.
The problem with this RFC is that the authentication is based on the “Mail from” of an SMTP transaction and not the content of the “From” header of the email.
Does it matter? Not really; what the user sees is the email’s “From” header not the “Envelope From” which disappears once the SMTP session is finished. So an email with the address “toto@domaine1.tld” in the “From” header can be sent from a domain server “domaine2.tl2”. As long as the address used in the “Envelope from” is from this domain, the SPF RFC will be complied with.
Another issue with this RFC: if there is a mail relay between the sender and the recipient, SPF verification becomes impossible.
DKIM
DKIM (DomainKeys Identified Mail) goes further. The principle is simple: the sending mail server signs the email body and headers.
With DKIM, if the email is tampered with, the signature will be invalid. Furthermore, as long as the email is not modified, the DKIM signature will be valid regardless of the number of relays. The guarantee that the From header is indeed that which was used when signing the email will be kept.
Is that it?
But that’s good, isn’t it? SPF guarantees that the dispatch server is indeed that of the sending domain and DKIM ensures the integrity of the email headers and specifically the famous “From” field.
Well no.
Remember objective 2: that the user is given reliable information. This comes back to this single piece of data: the “From” header, the essential element in the identity for end users. This is the information that they see, the information they believe.
So what’s important, is not the presence of a valid DKIM signature or a compliant SPF record but that these RFCs conform for the domain used in the “From” header!
Indeed, a hacker can easily affix a valid DKIM signature to an email and send it from a server with an SPF record. What’s more, many do. The sending address “president@organisation.com” can be used in a message sent from a server authorised by the SPF of “francis123.com” and with a valid DKIM signature of “fouchtra456.net”.
Both from the recipient’s point of view and that of a spam filter, compliance with SPF or DKIM is in no way a free pass. Only the violation of these RFCs is a potential indicator of malicious intent and even this has only a marginal effect on the classification as spam.
So, as it stands, these two RFCs cannot really be trusted. For them to be effective, the notion of alignment must be introduced. Put simply, alignment is respected if the DKIM and SPF RFCs are valid from the perspective of the domain present in the “From” header. Do you see the difference? Taking the alignment into account, you can add all the DKIM signatures that you want for the domain “fouchtra456.net”, they will be completely ignored if the email has the address “president@organization.com” in its “From” header.
DMARC
There we have something and it is introduced by DMARC (Domain-based Message Authentication, Reporting and Conformance). The principle of DMARC is to validate the authentication of the sending domain of an email based on SPF and DKIM, while respecting the alignment.
So, how does it work? If a third party receives an email where the “From” header is an address from a domain with a DMARC policy, it must check whether the SPF and DKIM authentications of this domain are valid. If neither is valid, it applies the DMARC policy. A DMARC policy indicates what recipient domains should do with messages that do not comply with SPF or DKIM. There are three possible policies: “reject”, “quarantine” or “do nothing”.
DMARC therefore requires the recipient to check the sender’s authentication, hence the word “authentication” in the name of the RFC.
An attentive reader will have noticed that this name also contains two other words: “Conformance” and “Reporting”.
- “Conformance”: refers to compliance with the DMARC policy set out above.
- “Reporting”: the recipient server regularly sends reports to the sender, about the emails received and their authentication status.
DMARC is a powerful weapon: if you are sure about your email infrastructure, you can impose a strict policy (to reject non-compliant emails). Consequently, any email which does not come from it will be rejected. And if you are unsure, you can use a permissive policy (allow emails through in all cases) and use the reports received to find out from where emails are originating.
And so that’s it? All good?
Almost. The domain is guaranteed not to be abused if:
- the SPF and DKIM records are put in place,
- these two RFCs are complied with through a controlled infrastructure,
- an aggressive DMARC policy is set up, demanding the rejection of non-compliant emails.
With this, only a compromised account can still send phishing emails from the protected domain.
The problem is that DMARC will also block legitimate uses.
For example, a mailing list cannot comply with either SPF or DKIM and is therefore covered by the DMARC policy.
In order to protect these legitimate uses, a mitigation solution is offered by the fourth RFC: ARC.
ARC or restoring trust
ARC, for “Authenticated Received Chain” is designed so that during the transfer of a message intermediaries sign the message if they have received it correctly authenticated.
This works on the same principle as a succession of sealed envelopes:
- an intermediary receives an email,
- if the DMARC authentication is successful, it places it in an envelope which it seals,
- the next intermediary does the same if the DMARC authentication is still valid, and so on, each sealed envelope protecting the content sent in the previous step and therefore creating an authentication chain – hence the name of the RFC.
This is the moment at which the attentive reader – the same one as earlier, undoubtedly, the kind to ask questions sitting in the front row of a conference, with a deceptively innocent smile – wonders what’s the use of all this.
Well… if a server receives a message where the DMARC authentication has failed but:
- where the ARC authentication has been successful,
- where the server which applied the ARC seal received the email with a valid DMARC authentication,
- and where the server which applied the ARC seal is a trusted server.
THEN the recipient server can ignore the DMARC failure.
Complicated? Yes, perhaps, but all the complexity is server side, so the user never sees it.
In addition, this allows exceptions to be added. We can then keep a trusted server list, for example list servers, known to break DMARC authentication but without malicious intent. If these servers implement ARC, then they can provide guarantees as to the quality of the authentication at the moment that they received the message. If this was valid, then the message content and its origin can be trusted.
Where does all this lead us?
Arriving at this point, it seems appropriate to summarise where we are at.
We have:
- SPF and DKIM to authenticate the email sources;
- DMARC to define what should happen to emails that do not comply with SPF or DKIM;
- ARC for allowing emails through that do not validate DMARC but have been validated along the way by a trusted source.
In order to achieve this article’s objective, namely to get rid of phishing emails, as many servers as possible need to implement SPF, DKIM and DMARC.
In order to set up a strict policy:
- DMARC must be implemented with a “reject” policy;
- SPF records must end with “-all”;
- outbound messages must have a DKIM signature.
In this way, the greatest possible severity with regard to incoming messages can be ensured. Obviously, all this only works if the recipient servers comply with this policy. This will greatly reduce the number of phishing emails reaching their destination.
This proposal comes up against two difficulties:
- some servers can send messages without passing through an identified outgoing MTA;
- many legitimate services break SPF and DKIM;
The move to such a level of strictness therefore requires a transition and analysis period and the organisation for implementing ARC.
During the transition period, a DMARC policy will be set to “do nothing”. Consequently, no message is rejected and the reports received can be analysed. In particular, error reports can be used to identify abnormal servers in the infrastructure.
From an organisational perspective, we can act on two levers:
- organise a list of relay servers;
- work together to improve the implementation.
A list of trusted intermediary domains that can modify messages (redirects or lists) could be centralised and made available for download for use by the ARC analysis tools, in a similar way to the metadata of an identity federation.
The possible constraints to the establishment of such a list are:
- its verification: ensuring that the information on it is reliable and up to date;
- its security: making it available securely.
Once the RFCs are implemented, the legitimacy of the information must be displayed habitually (like the padlock in the browser). Note that no generic email client offers an information display relating to the authentication of a message’s source.
It will also be difficult to bring together a sufficient number of entities implementing all these RFCs This article targets the population of higher education and research establishments, but it aims to increase awareness.
In summary, the point of these RFCs is to force email servers to establish their credentials, in a similar way as happened on the internet when most websites switched to HTTPS. From there, we can begin to be intentionally severe with domains that do not implement these RFCs. Clearly, if we want messages to get through, we must make an effort. This would mean hackers would also need to implement them. On this basis, the sending domain is guaranteed for a legitimate message as well as for a phishing email. With guarantees on the domain, problem domains, potentially controlled by hackers can legitimately be identified and the list of trusted or untrusted servers can be expanded.
About the authors
Laurent Aublet-Cuvelier has been an engineer at RENATER for several years. He is responsible for the SHARING service (more than 400,000 users at the end of 2019) and the shared anti-spam service (3 million protected accounts).
Damien Mascré is an electronic messaging engineer at RENATER. He has 15 years of experience in e-mail administration in higher education. He was responsible, for 8 years, for the electronic messaging system of the University of Paris XIII. Within RENATER, he is responsible for the development and modernisation of the messaging infrastructure on which all of RENATER’s services are based.
David Verdin is an engineer, messaging and mailing list specialist at RENATER. For twelve years, he has worked on Sympa software, in all aspects of the software: development, training, promotion, deployment and operation of services. In particular, he is responsible for the RENATER list service, currently operated for around 40 domains, bringing together 350,000 unique users and distributing 7 million messages per month.
Read more on the GÉANT Cyber Security Month 2020: https://connect.geant.org/csm2020
