With BIMI, a blue tick verification symbol is displayed on emails when the brand logo displayed as the sender\u2019s avatar has been authenticated as matching the company claiming to be sending the email. BIMI is not exclusive to Google, rather it is part of ongoing efforts by a working group with a broad range of members who support the verification standard. The flaw brought to Google’s attention only impacts its own implementation of BIMI.<\/p>\n
UPDATE<\/strong> (6\/5 1:45pm ET<\/em>): In a statement to SC Media sent after this report initially published Google said:<\/p>\n \u201cThis issue stems from a third-party security vulnerability allowing bad actors to appear more trustworthy than they are. 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.\u201d<\/p>\n When Google announced the universal availability of BIMI<\/a> to all Google Workspace customers and personal Google account users on May 3, the company emphasized the security benefits of the feature.<\/p>\n \u201cThis will help users identify messages from legitimate senders versus impersonators,\u201d Google said.<\/p>\n \u201cStrong email authentication helps users and email security systems identify and stop spam, and also enables senders to leverage their brand trust. This increases confidence in email sources and gives readers an immersive experience, creating a better email ecosystem for everyone.\u201d<\/p>\n Given Gmail Google Workspace\u2019s popularity as personal and business email platforms, users of the services are natural targets for threat actors<\/a>.<\/p>\n Less than a month after rolling out BIMI across the platforms, New Hampshire security architect Chris Plummer received a malicious spoofed email in his Google inbox that had been incorrectly check-marked to indicate it was sent by UPS.<\/p>\n Plummer said on Twitter<\/a> he alerted Google to the vulnerability through its bug bounty program but the company rejected his report with the message \u201cwon\u2019t fix – intended behavior\u201d.<\/p>\n The sender found a way to dupe @gmail<\/a>\u2019s authoritative stamp of approval, which end users are going to trust. This message went from a Facebook account, to a UK netblock, to O365, to me. Nothing about this is legit. Google just doesn\u2019t want to deal with this report honestly.<\/p>\n \u2014 plum (@chrisplummer) June 1, 2023<\/a><\/p><\/blockquote><\/div>\n \u201cHow is a scammer impersonating @UPS in such a convincing way \u2018intended\u2019[?] he wrote. \u201cThe sender found a way to dupe @gmail\u2019s authoritative stamp of approval, which end users are going to trust. This message went from a Facebook account, to a UK netblock, to O365, to me. Nothing about this is legit.\u201d<\/p>\n Plummer posted the email headers<\/a> which indicated the spoofed message had failed the Sender Policy Framework (SPF) authentication process, another verification method.<\/p>\n After his tweet went viral, Google\u2019s security team contacted Plummer to say they had had a change of heart over his bug bounty claim.<\/p>\n \u201cAfter taking a closer look we realized that this indeed doesn’t seem like a generic SPF vulnerability. Thus we are reopening this and the appropriate team is taking a closer look at what is going on,\u201d their message said.<\/p>\n \u201cWe apologize again for the confusion and we understand our initial response might have been frustrating, thank you so much for pressing on for us to take a closer look at this!\u201d<\/p>\n Plummer posted a scr<\/a>e<\/a>enshot<\/a> showing the investigation had been assigned a \u201cPriority P1\u201d status by Google.<\/p>\n Commenting on Plummer\u2019s posts, one Twitter user said the problem appeared to be that UPS\u2019s main domain had an SPF record and the spoofer had circumvented that protection by using a related subdomain.<\/p>\n \u201cThat subdomain don’t have a SPF record, and SPF is not meant to be inherited by subdomains. Perhaps it falls between the cracks because they’re using a subdomain.\u201d<\/p>\n Another Twitter user said the email appeared to comply with BIMI because it passed the requirements of the Domain Message Authentication Reporting and Conformance<\/a> (DMARC) authentication method.<\/p>\n \u201cIt passed DMARC because UPS use Microsoft for email (and it\u2019s in their SPF record), so you just need to send it from any Microsoft account.\u201d<\/p>\n Another commenter said: \u201cGmail can’t fix the fact that [Microsoft] knowingly delivered [an email] that it KNEW failed SPF and DMARC.\u201d<\/p>\nSpoof-proof, at least in theory<\/h2>\n
Ups and downs of BIMI<\/h2>\n
\n
It’s a bug, not a feature<\/h2>\n
![](\"https:\/\/www.scmagazine.com\/_next\/image?url=https%3A%2F%2Ffiles.scmagazine.com%2Fwp-content%2Fuploads%2F2023%2F06%2FImage-from-Google.png&w=1920&q=75\")
<\/figure>\nBest laid plans of DMARK and SPF<\/h2>\n