By Damien Mascré, David Verdin, Laurent Aublet-Cuvelier (RENATER)
On the list of the many issues inflicted by emails, phishing appears to be social disease: rare, shameful and unfortunately fatal.
Phishing occurs when a message appears to come from one sender when in fact it has come from another. Posing as a trusted third party, the hacker will use the opportunity to steal financial or strategic information.
Spam is a problem generally, but phishing exacerbates the issue; it erodes the trust placed in messaging tools. As a general rule, users expect the identity given in an email’s “From” header to correspond to the actual sender. When not only is this not the case, but the confusion over the identity also has serious consequences for the user, mistrust begins to grow, not only with regards emails, but more generally the tools provided by the establishment.
However, if you look carefully at a phishing email, you’ll almost certainly realise the deception and so it has very few chances of succeeding. These scams therefore rely on two factors for success: bulk mailing and the readers’ vulnerability. Since there will always be at least one reader of a phishing email who is vulnerable and likely to succumb, the success of the phishing email is statistically certain as long as bulk mailings continue.
Moreover, this is, to a certain extent, a viral issue because by taking control of an email inbox hackers can extend their influence by sending “real” messages from the establishment’s infrastructure. Consequently, we find ourselves facing a scourge which is very hard to fight.
For years, email administrators have tried to rid themselves of this problem. Since users are not equipped to know for sure whether or not an email is legitimate, a certain number of mechanisms has been implemented to identify fraudulent messages before the user sees them. Such mechanisms either reject the emails or display them to the user accompanied with clear warnings.
Make no mistake, the purpose of these technologies is to limit emails sent from illegitimate sources. This does not mean that the emails are not spam, nor that the sender is legitimate; for example, in the context of a compromised inbox, no mechanism can protect us.
Several RFCs attempt to guarantee the legitimacy of the dispatch server. The most notable are SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). These two RFCs are designed to allow the authentication of the sending server. Their main problem is that they leave what to do with an email to the discretion of the server receiving the message if it violates any of the RFCs.
In order to give clear instructions to the servers receiving the emails, these two RFCs have been supplemented by DMARC (Domain-based Message Authentication, Reporting and Conformance). This clearly indicates what should be done when an email is suspect: do nothing, quarantine or reject the email. Implementing an aggressive DMARC policy is an excellent prevention method when simply sending from one inbox to another. However, as soon as mail relays are involved, even if they are legitimate such as transfers to an inbox or list servers, DMARC then becomes an issue.
This is why some consumer email operators now want the cherry on top of the RFC cake: ARC (Authenticated Received Chain). This new RFC seeks to establish a certificate chain between mail relays. In short, a server issuing an email which violates a DMARC policy may still see the email accepted if:
- it proves that the message was correctly authenticated when it received it,
- it is itself a trusted server.
Trust. The word has been used three times in just a few paragraphs.
Indeed, just as the Education and Research identity federation relies on a circle of trust, the effective processing of phishing emails relies on establishing trust between third parties responsible for mail relays, whether in the circle of education and research or between this circle and major private and public organisations.
It’s easy to imagine the establishment of lists of legitimate servers. Nothing as complex as the blacklists for anti-spam systems, simply a list of known servers for sending emails. Consequently, it would be possible to implement aggressive DMARC policies to remove phishing emails, while permitting legitimate mail relays using ARC.
But such an implementation assumes the coordinated involvement of the entire community.
This would involve:
- collating the legitimate mail servers and their IPs,
- offering technical solutions to set up inbound filtering, both severe for unknown sources and taking into account ARC headers for known sources,
- offering technical solutions to implement an ARC authentication chain,
- contacting the main private and public organisations to announce that the French ESR has a system for guaranteeing email senders so that they can also trust us.
The authors are aware that the RFCs mentioned in the article are only one resource among many in the fight against this form of cyber crime, but a resource that can be effective as part of a coordinated action.
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://dev.connect.geant.org/csm2020