Trust is currency in our online world, and the links we establish between trusted parties enable everything from secure websites, to crypto platforms, to the software updates you install on your phone. The value we place in it is exactly what makes violating that trust so appealing to ne’er-do-wells and all the scammy operators hoping to make an illegitimate buck off you.
Back at the start of June, we had the opportunity tocheck out one of the latest tricks baddies were up tothat abused existing trust-based systems — in this case, theblue checkmark Gmail just started showingin your inbox to indicate a verified sender. While thatshouldonly appear on messages coming from authenticated businesses and institutions, scammers had devised a trick that seemingly let them squeeze past this test, displaying the blue checkmark despite not originating from the business in question. Let’s take a look at what went wrong, how it was abused, and what’s being done to fix things.
How this is all supposed to work
Email is one of the oldest ways to communicate online, and as such, it’s been tackling abuse for decades. That’s led to the design and implementation ofnumerous systems intended to add robust authentication. One of the biggies there is DMARC, or Domain-based Message Authentication, Reporting and Conformance, which builds upon Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) systems to prevent spoofing and ensure that the name in an email’sfrom:field is actually the person who sent it.
Gmail also uses VMC, or a Verified Mark Certificate, to indicate sender legitimacy. This one is essentially a digital attestation of something that’s been legally trademarked — letting us establish brand identity. That’s then used as the basis for BIMI, the Brand Indicators for Message Identification — the system that ultimately is responsible for showing a company’s icon next to its messages in your inbox.
When all this is properly configured, emails from authenticated organizations will display the company logo, as well as feature the blue “verified” checkmark. At least, that’s how it’ssupposedto work. So how did this all go so spectacularly wrong?
Wherein we lose all faith in checkmarks
Cybersecurity engineerChris Plummer noticed something was upwhen he spotted emails in his Gmail inbox from some suspicious-looking addresses… yet nonetheless included the real company’s logo and featured the blue checkmark. As you can see in the example here shared below, while this message does appear to come from a UPS.com account (spoiler: it didn’t really), the gibberish subdomain and account should immediately jump out at anyone with even a passing interest in online security as strongly suggestive of spoofing.
As we detailed in our earlier coverage, Plummer reported this to Google only to have his bug submission initially rejected on the basis that this was somehow Gmail’s intended behavior. After social media helped raise this vulnerability’s profile a bit, Google ultimately reconsidered that and acknowledged that this justified a closer look.
This past week, the company began sharing some insight into how this was possible. Speaking with Cyberscoop,Google summarized the issueas “a third-party security vulnerability allowing bad actors to appear more trustworthy than they are.” The core of this seems to be the coexistence of the dual SPF and DKIM authentication methods, and how BIMI behaves when one passes, but not the other.
Since UPS trusted Microsoft to send emails on its behalf, when Gmail saw the incoming message that a scammer directed through a Microsoft server, this was viewed as a legit, BIMI-compliant way for a UPS email to arrive — even despite the presence of that garbage-sounding spoofed subdomain.
As another security researcher,Jonathan Rudenberg, explained on Mastodon, as a consequence of the way that Gmail implemented BIMI, a message with a valid SPF check but a mismatched DKIM certificate would still be treated as legitimate. By taking advantage of misconfigured mail servers run by companies using BIMI, it was possible to abuse whitelist policies and convince a remote server to pass a message along as if it originated from the spoofed domain — all while seeming to support BIMI authentication.
In this case, Microsoft email servers were outed as making this attack possible.Christoph Dary shares how this workswith our example: Since UPS trusted Microsoft to send emails on its behalf, when Gmail saw the incoming message that a scammer directed through a Microsoft server, this was viewed as a legit, BIMI-compliant way for a UPS email to arrive — even despite the presence of that garbage-sounding spoofed subdomain. And rather than looking further back down the chain of which systems the email had passed through, and whether it failed any earlier validation attempts, if the most recent test looked good to Gmail, that’s apparently all it took to trigger the checkmark to appear.
Let’s just never use email again
This all seems pretty bad, considering how relatively easy it appears to just utterly bypass what’s supposed to be a reliable indicator of the trust you should have in a message’s sender. And if you were thinking, “well no way would I be fooled by that fake-ass UPS email,” check out what Jonathan Rudenberg was able to accomplish after a little investigation:
There is no way your average email user — or honestly, even someone with a relatively advanced eye for spam — would think twice about the authenticity of that sender. So what are supposed to do, just give up on email? Assume it’s all possibly fake? Thankfully, solutions are already being implemented.
One of the most immediately impactful has been UPS removing Outlook as an authorized mail server in its SPF record, preventing this specific attack. But what about all the other myriad organizations out there with similarly misconfigured records?
Google has basically decided not to trust SPF alone when doing DMARC checks, and instead will require the use of DKIM, which is being promoted as robust against this type of vulnerability. Enforcement of that change should already be underway.
Maybe the most frustrating thing to come out of all of this has been shining a light on just how fragile and compartmentalized email authentication is right now. Disparate systems are cobbled together, reliant on each other to do their jobs, but lacking necessary understanding about how all those parts are making the decisions they do.
When a problem actually does emerge, as it did here, the parties involved need to be resistant to taking the “well, my part works, the problem must be your part, and I can’t be bothered to investigate” stance. Even now, thegroup behind BIMIsounds almost dismissive of the whole incident, saying that it “illustrates a long-standing, and well-known, issue with SPF, one that predates BIMI and even DMARC.” If issues like these are known, the parties involved need to be proactively resolving them (rather than waiting for hackers to take notice), if we’ve got any hope of feeling confident in the trust we share online.
