@glauca Hey, any chance you’re going to support configuring webauthn as the sole 2FA option for accounts?
| pronouns | they/them |
| github | https://github.com/titanous |
Jonathan Rudenberg
- 179 Followers
- 298 Following
- 26 Posts
debugger.
Annnd tagging @fastmail here got an immediate response to the ticket confirming that as of this week they "now require an aligned DKIM pass for BIMI".
So @fastmail didn’t respond at all to my report sent to security@ about the BIMI spoofing issue. The auto reply from their ticket system claimed that it may take “10 business days to respond” which elapsed this morning (and is way too long for an initial response to a security issue).
Great coverage of the BIMI spoofing issue from AJ: https://cyberscoop.com/security-professionals-tweet-bimi-google-gmail/
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.
hannoGmail'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
Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy
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.