Email Security Features Fail to Prevent Phishable ‘From’ Addresses
By Robert Lemos
The security features for verifying the source of an email header fail to work together properly in many implementations, according to a team of researchers. Three standards for email security that are supposed to verify the source of a message have critical implementation differences that could allow attackers to send emails from one domain and have them verified as sent from a different — more legitimate-seeming — domain
says a research team who will present their findings at the virtual Black Hat conference next month.
Researchers have discovered 18 different ways of fooling the triumvirate of email technologies — Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC) — for a subset of email services, including Gmail, and clients, including Microsoft Outlook. While the three technologies should ensure the FROM header of an email cannot be spoofed — for example, stating that the email comes from email@example.com when, in fact, an attacker has sent it from their own mail server — undermines the authentication that the three technologies are designed to provide.
The potential for spear-phishing is significant, says Vern Paxson, a professor at the University of California at Berkeley and one of the researchers investigating the issues.
“This is really sobering because the mindset today [is] if you are using an industrial-strength mail system like Gmail, and it tells you that the message really is from ‘firstname.lastname@example.org,’ you are going to believe them,” says Paxson, who is part of the trio of researchers who conducted the tests. “And it boils down to the fact they followed the spec, but they just did it in a different way than others may have expected.”
The research highlights a major issue with component-based software design, where different development teams create software components to meet certain specifications: When the specifications are not clear, developers will often make a best guess. The resulting software may meet the specification but will react differently to edge cases.
In the current research, Paxson, post-doctoral student Jianjun Chen, and Jian Jiang, the director of engineering at Shape Security, found that the simple act, for example, of including two FROM lines in an email header can result in a mail server verifying the first FROM header while the email client displays the second FROM address. The result? An email sent from an attacker’s mail server is verified as coming from a legitimate address, such as email@example.com.
“At a high level, this is a general problem, which is that we build complex systems these days out of components that we get from different parties, and those parties can have inconsistencies in really minor ways that turn out to have security implications,” Paxson says. “It is not anyone being boneheaded or a specification being sloppy so much as the complexity of the systems we build and the components we use, making security both hard and nasty.”
The researchers created three different classes of attacks on 10 popular email providers and using 19 different email clients. The first class abuses the security assumptions of components in the same email server, while the second class exploits inconsistencies between a component on a server and one in a client-side email agent. A third class of weakness allows replay attacks in some cases, allowing attackers to make changes to an email without breaking the authentication.
Every email provider — including Google’s Gmail.com, Apple’s iCloud.com, Microsoft’s Outlook.com, and Yahoo.com — had at least one issue that resulted in mismatched authentication, the researchers found. The FROM header in an email could be modified to include multiple addresses, for example, and iCloud and Gmail would both authenticate on the first address and display the second address.
Other attacks include adding special characters to the HELO or MAIL FROM fields of the header that are handled differently depending on the mail server.
The researchers notified email services of the research, garnering different reactions. Google fixed at least two of the issues immediately and rewarded the researchers bounties for the reports, as did Zoho.com, Mail.ru, Protonmail.com, and Fastmail.com. Other providers thanked the researchers and are analyzing the issues. Microsoft “disregarded our report (which included our paper and a video demoing [one] attack) because the threats rely on social engineering, which they view as outside the scope of security vulnerabilities,” the researchers stated in a yet-to-be-published report. And Yahoo apparently misunderstood the attack details.
The research is ongoing. Even with 18 different techniques, Paxson and Chen do not believe they have exhausted the possibilities for attacks.
“What is worrisome is that I would meet with the research group at Berkeley, and I would duck in every month or so, and [Chen] would have a few more attacks,” Paxson says. “I wouldn’t think that the paper is complete. It is what we could find in a year. Until we really have good tooling to find these things, I could not say that we have found them all.”