Gmail's BIMI implementation only requires SPF to match, the DKIM signature can be from any domain.
This means that any shared or misconfigured mail server in a BIMI-enabled domain's SPF records can be a vector for sending spoofed messages with the full BIMI ✅ treatment in Gmail.
Until today, there was a Microsoft 365 configuration that would happily forward messages with a spoofed RFC5321.MailFrom (envelope) address intact, which allowed spoofing messages from any of the 775 domains that are both BIMI-enabled and allow outlook.com in their SPF.
More vectors like this almost certainly exist, the implementations and configurations of email forwarding are extremely complicated, as discussed in the recent Forward Pass paper: https://arxiv.org/abs/2302.07287
BIMI is worse than the status quo, as it enables super-powered phishing based on a single misconfiguration in the extremely complicated and fragile stack that is email.
Other BIMI implementations:
iCloud: properly checks that DKIM matches the From domain
Yahoo: only attaches BIMI treatment to bulk sends with high reputation
Fastmail: vulnerable but also supports Gravatar and uses the same treatment for both so the impact is minimal
Apple Mail + Fastmail: vulnerable with a dangerous treatment
The critical role played by email has led to a range of extension protocols (e.g., SPF, DKIM, DMARC) designed to protect against the spoofing of email sender domains. These protocols are complex as is, but are further complicated by automated email forwarding -- used by individual users to manage multiple accounts and by mailing lists to redistribute messages. In this paper, we explore how such email forwarding and its implementations can break the implicit assumptions in widely deployed anti-spoofing protocols. Using large-scale empirical measurements of 20 email forwarding services (16 leading email providers and four popular mailing list services), we identify a range of security issues rooted in forwarding behavior and show how they can be combined to reliably evade existing anti-spoofing controls. We further show how these issues allow attackers to not only deliver spoofed email messages to prominent email providers (e.g., Gmail, Microsoft Outlook, and Zoho), but also reliably spoof email on behalf of tens of thousands of popular domains including sensitive domains used by organizations in government (e.g., state.gov), finance (e.g., transunion.com), law (e.g., perkinscoie.com) and news (e.g., washingtonpost.com) among others.
I replicated the Microsoft 365 spoofing issue after Chris Plummer spotted it being exploited in the wild against ups.com: https://twitter.com/chrisplummer/status/1664075886545575941
Chris eventually posted the headers and after a bit of fiddling in Exchange Online, and many cursed Powershell cmdlet errors from the web UI, I figured out how it worked.
I reported it to MSRC, but I think they failed to triage properly because they closed the report as wontfix yesterday. Today I noticed that they fixed it by rewriting the envelope sender, presumably because either Google or UPS contacted them about it.
UPS also removed outlook.com from their SPF at some point yesterday.
@gvlx Definitely no bounty.
Full email: https://gist.github.com/titanous/b949c744cfd0be35b9980377bae780a8
@titanous yeah, that extended verification is pretty silly, as you've highlighted with the lessons learned from WebPKI.
Should I also interpret your list that other mail providers aren't checking the Verified Mark? If so, even more evidence! 🤡
@glyph Google is looking into it: https://twitter.com/chrisplummer/status/1664348988143722500
I emailed Fastmail but haven't heard back.
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted.