Google changes email authentication after spoof shows a bad delivery for UPS
(2023/06/09)
- Reference: 1686272528
- News link: https://www.theregister.co.uk/2023/06/09/google_bimi_email_authentication/
- Source link:
Google says it has fixed a flaw that allowed a scammer to impersonate delivery service UPS on Gmail, after the data-hoarding web behemoth labeled the phony email as authentic.
The problem stemmed from an issue in an email authentication program called Brand Indicators for Message Identification (BIMI) that aims to protect email users from brand spoofing and phishing attacks claiming to be from a trusted org. BIMI also protects senders from reputational damage if their names and logos are used in a cyber attack.
BIMI, and [1]email providers that support it – including Google – do this via email authentication standards: [2]Sender Policy Framework (SPF) , [3]Domain-based Message Authentication, Reporting, and Conformance (DMARC) , and [4]DomainKeys Identified Mail (DKIM) . BIMI requires participating brands to adopt DMARC along with either SPF or DKIM.
[5]
Google started [6]supporting BIMI in July 2021, and it implemented the blue checks for [7]verified senders last month.
[8]
[9]
Up until this week, Google also used BIMI's requirements for senders: DMARC alignment with either SPF or DKIM.
It's since switched to DKIM after security architect Chris Plummer [10]found a bug in SPF in late May. He spotted that an email purporting to be from a verified UPS sender – complete with the logistic giant's logo, and the Google-verified blue check – was a scam. The problem was a [11]vulnerability in SPF that upgraded non-authenticated emails, making them authentic.
[12]
"This issue stems from a third-party security vulnerability allowing bad actors to appear more trustworthy than they are," a Google spokesperson told The Register . "To keep users safe, we are requiring senders to use the more robust DomainKeys Identified Mail (DKIM) authentication standard to qualify for Brand Indicators for Message Identification (blue checkmark) status."
Bad delivery on all sides
Plummer submitted a bug report to Google, alerting it to the issue, and shared the report with The Register . Here's some of what he relayed:
I believe there is a bug in Gmail which has permitted a malicious sender to trick Gmail into this sense of assurance. Based on the message trajectory from email headers (full message attached to this case), this message was sent by way of a Facebook account, and onward through third-party infrastructure ( [13]fa83.windbound.org.uk , if DNS is to be believed) en route to O365, where it was then relayed to Gmail. Through this series of hops, it seems exceptionally unlikely this message was legitimately sourced by the UPS Corporation and that the brand mark in use is being used legitimately, which is what Gmail is communicating.
The spoof email, which managed to trick Google into thinking it originated from UPS, did not include a malicious payload, Plummer told The Register . "But if it had, that call would be highly regarded by an end user as genuine."
[14]Barracuda tells its ESG owners to 'immediately' junk buggy kit
[15]You might have been phished by the gang that stole North Korea's lousy rocket tech
[16]Why Microsoft just patched a patch that squashed an under-attack Outlook bug
[17]Google puts $1M behind its promise to detect cryptomining malware
Initially, Google ignored his report, with a "won't fix – intended behavior" message, Plummer said. However, increased media attention around the flaw seems to have swayed some hearts and minds about the matter.
"What we will likely never know is how many times it was taken advantage of and used maliciously, how many other brands were successfully impersonated, and how many users were victimized by it," Plummer said.
BIMI, for its part, addressed the issue in a Wednesday blog post, and also blamed the bug on a "long-standing, and well-known, [18]issue with SPF , one that predated BIMI and even DMARC."
The brand authentication program "is working exactly as designed," it added. And this recent Gmail incident highlights "long-standing edge cases" that still need to be fixed.
[19]
"We hope the benefits of BIMI and the necessary implementation components create further incentives for mailbox providers who participate in BIMI (and those who define and implement the standards) to address these long-standing gaps in authentication protocols," the BIMI blog said. ®
Get our [20]Tech Resources
[1] https://bimigroup.org/bimi-infographic/
[2] https://support.google.com/a/answer/33786?sjid=9271933804391582000-NA
[3] https://support.google.com/a/answer/2466580?sjid=9271933804391582000-NA
[4] https://support.google.com/a/answer/174124?sjid=9271933804391582000-NA
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://workspaceupdates.googleblog.com/2021/07/BIMI-support-across-gmail.html
[7] https://workspaceupdates.googleblog.com/2023/05/expanding-gmail-security-BIMI.html
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://twitter.com/chrisplummer/status/1664075886545575941?s=20
[11] https://systemweakness.com/email-spoofing-due-to-invalid-spf-record-vulnerability-e53ede4e758e
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] http://fa83.windbound.org.uk/
[14] https://www.theregister.com/2023/06/08/barracuda_immediately_replace_esg/
[15] https://www.theregister.com/2023/06/02/us_south_korea_kimsuky_warning/
[16] https://www.theregister.com/2023/05/12/microsoft_patches_second_flaw/
[17] https://www.theregister.com/2023/06/08/google_1m_cryptominer_guarantee/
[18] https://bimigroup.org/update-on-check-marks/
[19] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[20] https://whitepapers.theregister.com/
The problem stemmed from an issue in an email authentication program called Brand Indicators for Message Identification (BIMI) that aims to protect email users from brand spoofing and phishing attacks claiming to be from a trusted org. BIMI also protects senders from reputational damage if their names and logos are used in a cyber attack.
BIMI, and [1]email providers that support it – including Google – do this via email authentication standards: [2]Sender Policy Framework (SPF) , [3]Domain-based Message Authentication, Reporting, and Conformance (DMARC) , and [4]DomainKeys Identified Mail (DKIM) . BIMI requires participating brands to adopt DMARC along with either SPF or DKIM.
[5]
Google started [6]supporting BIMI in July 2021, and it implemented the blue checks for [7]verified senders last month.
[8]
[9]
Up until this week, Google also used BIMI's requirements for senders: DMARC alignment with either SPF or DKIM.
It's since switched to DKIM after security architect Chris Plummer [10]found a bug in SPF in late May. He spotted that an email purporting to be from a verified UPS sender – complete with the logistic giant's logo, and the Google-verified blue check – was a scam. The problem was a [11]vulnerability in SPF that upgraded non-authenticated emails, making them authentic.
[12]
"This issue stems from a third-party security vulnerability allowing bad actors to appear more trustworthy than they are," a Google spokesperson told The Register . "To keep users safe, we are requiring senders to use the more robust DomainKeys Identified Mail (DKIM) authentication standard to qualify for Brand Indicators for Message Identification (blue checkmark) status."
Bad delivery on all sides
Plummer submitted a bug report to Google, alerting it to the issue, and shared the report with The Register . Here's some of what he relayed:
I believe there is a bug in Gmail which has permitted a malicious sender to trick Gmail into this sense of assurance. Based on the message trajectory from email headers (full message attached to this case), this message was sent by way of a Facebook account, and onward through third-party infrastructure ( [13]fa83.windbound.org.uk , if DNS is to be believed) en route to O365, where it was then relayed to Gmail. Through this series of hops, it seems exceptionally unlikely this message was legitimately sourced by the UPS Corporation and that the brand mark in use is being used legitimately, which is what Gmail is communicating.
The spoof email, which managed to trick Google into thinking it originated from UPS, did not include a malicious payload, Plummer told The Register . "But if it had, that call would be highly regarded by an end user as genuine."
[14]Barracuda tells its ESG owners to 'immediately' junk buggy kit
[15]You might have been phished by the gang that stole North Korea's lousy rocket tech
[16]Why Microsoft just patched a patch that squashed an under-attack Outlook bug
[17]Google puts $1M behind its promise to detect cryptomining malware
Initially, Google ignored his report, with a "won't fix – intended behavior" message, Plummer said. However, increased media attention around the flaw seems to have swayed some hearts and minds about the matter.
"What we will likely never know is how many times it was taken advantage of and used maliciously, how many other brands were successfully impersonated, and how many users were victimized by it," Plummer said.
BIMI, for its part, addressed the issue in a Wednesday blog post, and also blamed the bug on a "long-standing, and well-known, [18]issue with SPF , one that predated BIMI and even DMARC."
The brand authentication program "is working exactly as designed," it added. And this recent Gmail incident highlights "long-standing edge cases" that still need to be fixed.
[19]
"We hope the benefits of BIMI and the necessary implementation components create further incentives for mailbox providers who participate in BIMI (and those who define and implement the standards) to address these long-standing gaps in authentication protocols," the BIMI blog said. ®
Get our [20]Tech Resources
[1] https://bimigroup.org/bimi-infographic/
[2] https://support.google.com/a/answer/33786?sjid=9271933804391582000-NA
[3] https://support.google.com/a/answer/2466580?sjid=9271933804391582000-NA
[4] https://support.google.com/a/answer/174124?sjid=9271933804391582000-NA
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://workspaceupdates.googleblog.com/2021/07/BIMI-support-across-gmail.html
[7] https://workspaceupdates.googleblog.com/2023/05/expanding-gmail-security-BIMI.html
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://twitter.com/chrisplummer/status/1664075886545575941?s=20
[11] https://systemweakness.com/email-spoofing-due-to-invalid-spf-record-vulnerability-e53ede4e758e
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] http://fa83.windbound.org.uk/
[14] https://www.theregister.com/2023/06/08/barracuda_immediately_replace_esg/
[15] https://www.theregister.com/2023/06/02/us_south_korea_kimsuky_warning/
[16] https://www.theregister.com/2023/05/12/microsoft_patches_second_flaw/
[17] https://www.theregister.com/2023/06/08/google_1m_cryptominer_guarantee/
[18] https://bimigroup.org/update-on-check-marks/
[19] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZIKj3-LlW4VLDDIDCw0IWwAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[20] https://whitepapers.theregister.com/
Bug/Vulnerability or just bad implementation?
Maybe it's because the article is referencing two different analyses on the issue, but I'm trying to understand why they are calling this a "bug" or "vulnerability" in SPF.
"Too many lookups" is something that has been known about for ages (although most companies probably have no clue when it's happening). The results of the lookup is "Permanent error". I would venture to say you should have a policy to reject email on both fail and permerror SPF lookups, so it would never be delivered. Otherwise, how will someone know their SPF is borked if people treat it like "dunno". Unfortunately, the RFC just leaves the choice up to the receiving end. Barring a complete block, you should at LEAST have increased scrutiny on the email (i.e. don't allow the email to pass DMARC or BIMI in order to call attention to the issue). However, that doesn't seem to be the case for the ups.com email.
In the ups.com email, the headers show SPF passed because Microsoft's servers were authorized to send on their behalf according to the ups.com SPF (they have since changed their SPF). DKIM alignment failed, since it was signed by onmicrosoft.com, but SPF alignment succeeded, thus passing DMARC (a requirement for BIMI). This still isn't a "bug" in SPF; it's doing exactly what it intended: say these servers (e.g. Microsoft) are allowed to send email purported to be from ups.com. The more interesting part is why Microsoft decided to relay an email FROM a "ups.com" address when the SPF check failed (and no DKIM signature). This touches on the problem of SPF as a whole (it breaks relaying). I believe Google only allows relaying FROM domains that you can prove you have some control over.
Ultimately this sounds more like an implementation flaw, not an SPF bug. BIMI is intentionally supposed to be hard to spoof, which is why you need to have everything set up the "proper" way. Requiring DKIM alignment is better in the long run anyway, since that is really hard to spoof.