Brand Indicators for Message Identification (BIMI) has recently hit new heights of visibility with the release of Google’s Blue Checkmark last month. Since its inception, Valimail has been instrumental in developing BIMI as a standard, and continues to drive its adoption. Not only is our CEO, Alexander Garcia-Tobar, one of the founders of the group, but our CTO, Seth Blank, currently chairs the AuthIndicators Working Group, which develops the BIMI standard.
Since Google’s blue checkmark announcement, an example has circulated of an email bearing a spoofed blue checkmark:
These reports have cast a negative light on BIMI, calling it a weakness of BIMI, specifically on the blue checkmark that Google is displaying in concert with BIMI logos. However, we don’t believe that’s the case!
The issue being highlighted in these articles is a problem which predates BIMI, and even Domain-based Message Authentication, Reporting, and Conformance (DMARC), by nearly a decade. BIMI has successfully brought email authentication front and center in a visual form that individuals can see, and as a result, it is now making visible long-standing gaps that still need to be addressed by the email ecosystem.
To better understand how the recent attack and spoofed blue checkmark occurred, let’s begin with how email authentication started.
Some background on email authentication
Email’s first step with authentication, and the one which pioneered domain-based authentication, was Sender Policy Framework (SPF). Since it was the first protocol of its kind, SPF tried to solve many use cases, but was not a complete email authentication solution. SPF effectively creates an allow list of IPs which are authorized to send on behalf of a domain. This works somewhat well when a company runs its own mail systems, but has many challenges in a cloud world where a service sends on behalf of many companies. This 5 page document from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) covers many of SPF’s shortcomings.
The next email authentication method to be established was DomainKeys Identified Mail (DKIM), which built on the lessons learned SPF, but still left gaps in the email system. At their core, SPF and DKIM are anti-spoofing technologies that mail systems understand. In order to better leverage the protection of both SPF and DKIM, and to tie them to what a user sees in their inbox, DMARC was finally developed. In other words, of the three email authentication protocols, SPF is the first and weakest mechanism. It’s why we work closely with our customers to broadly deploy DKIM, so that the issues with SPF are minimized.
In the specific case being highlighted above, email authentication was only performed by implementing SPF. Without DKIM in place, this left a gap in the email system that was abused by an attacker.
Let’s take a deeper dive into the specific issue, which is known as an SPF upgrade attack:
Spoofing the checkmark
From the reports and the above screenshot, we have an idea of what the attacker did to pass authentication, get a blue checkmark, and get delivered to the recipient’s inbox:
First, email for the domain ups.com is hosted by a well-known hosting provider, and the attacker was also able to create an account on this provider’s system. From there, the attacker sent mail to their account on that system, and that account was configured to forward the message on to Gmail, thus allowing the forwarded message to pass SPF authentication, and giving them the blue checkmark.
In theory, the message could’ve been rejected by the hosting provider because the message didn’t pass DMARC validation checks when it initially reached that platform, and ups.com’s DMARC policy record is set to enforcement (p=reject). Unfortunately, the hosting provider does not currently honor such policy statements. So, rather than rejecting the message (preventing its delivery), it accepted and forwarded the message to the end recipient’s Gmail.
It’s important to note here that the DMARC protocol doesn’t require that mailbox providers honor a domain’s DMARC policy record. Many soften the handling decision globally (i.e., treat a p=reject policy as p=quarantine) and/or offer their customer tenants the opportunity to do so. Mailbox providers are in the business of ensuring that their customers receive the email that they want to receive, and such policy overrides can help them perform that function when legitimate mail streams fail authentication, as sometimes happens. However, this incident illustrates the danger of applying these overrides with too broad a brush, which can allow illegitimate mail to reach its destination when a domain owner’s DMARC policy is ignored.
When the message got to Gmail, it passed DMARC checks because it now passed SPF, as it was originating from the well-known provider that hosts mail for ups.com. The key takeaway here is that the message received the blue checkmark because it passed DMARC at Gmail and UPS has BIMI configured. It then passed DMARC at Gmail because it passed SPF with an aligned domain.
Preventing future attacks like this
There are two ways that this SPF upgrade attack can be prevented in the future:
- Honor DMARC policies – DMARC is relied upon by companies of all sizes to mitigate fraud, so it’s important that all hosting providers honor policies set by organizations.
- Require aligned DKIM pass to obtain a DMARC pass – DMARC currently requires only an aligned SPF pass or an aligned DKIM pass, because many small senders only do SPF. Since BIMI only requires DMARC, senders have the choice of using SPF, DKIM, or both. Wherever possible, Valimail encourages both SPF and DKIM to guard against the possibility that one of the two might fail.
- Consider ARC, even when DMARC passes – In this particular example, the failing authentication received by the hosting provider was codified in its ARC Set. However, because DMARC passed, the ARC Set was never evaluated. Utilizing ARC even when DMARC passes could mitigate some of these attack vectors.
Unfortunately, email is rife with fraud, and is why email authentication is so critical to anti-abuse protections. Validating sender identity is the front door to entry of an email system, but is far from the last. Email systems all layer on additional protections after email authentication is checked, but email authentication does not mean a message is safe or ready for delivery to a user. There is always room for strengthening both email authentication at the front door and the additional anti-abuse protections after it.
How Valimail can help
At Valimail, we recommend that DMARC enforcement should not be done solely with SPF, and we even go so far as to assist organizations in implementing and managing their DKIM. With SPF and DKIM in place, and with a DMARC policy at enforcement, it’s much, much more difficult for an attack like this to occur.
Valimail has been deeply involved in driving stronger protections and closing gaps in email authentication, through work at the Internet Engineering Task Force (IETF) and the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), authoring protocols like the Authenticated Received Chain (ARC), working on DMARC 2.0, and driving ecosystem automation of DKIM. With malicious attackers always on the hunt for mechanisms to exploit, the work here will never be done, but we can endeavor to constantly raise the bar and make it more difficult for attackers, and more illegal for malicious actors to orchestrate.
Email authentication like DMARC is a critical element in any email system, and Valimail can help you maintain continuous DMARC enforcement. Valimail’s focus on the strongest and highest quality authentication ensures our customers get the best protection possible. Once in place, you can then implement other email authentication features, such as BIMI, and receive Google’s checkmark.
To learn more about protecting your brand, domain, customers, and employees from email attacks, contact one of Valimail’s DMARC experts today to schedule a demo.