We now have an update on that video I made a couple weeks ago talking about how scammers
figured out a way to trick Gmail into showing a blue verified checkmark on a fake spoofed email
from UPS. And there are really several companies involved in how this whole process worked,
like Google, Microsoft, BIMI, and really, they're all pointing fingers at each other
at whose fault this ultimately is, but I'll go over who I think is at fault in a minute.
The main thing to know though, is that Google has issued an update
that fixes this exploit by implementing stricter requirements for verification
for actually displaying this checkmark. Though of course,
I'll give a more detailed explanation for those who want it. First I'll go over how it works,
and then I'll go over who's at fault because it's not exactly cut and dry.
And if you're wondering if this was isolated to just UPS, no it wasn't. There was actually
another researcher, Jonathan Rudenberg, who demonstrated this by spoofing emails from DigiCert
and Entrust.com, which are literal security companies that are root authorities who are
trusted to create digital signatures for like code signing and SSL certificates, that sort of thing.
So clearly this wasn't just UPS. And if these security companies were vulnerable to this,
I think it could be considered very serious. To understand how it works,
you do need to know some context, such as there's a few technologies that exist to prove,
or allow someone to prove that they are someone who they say they are.
But if you already know about this, you can just skip ahead. One is called SPF,
where a website will literally publish a list of servers that are allowed to send emails
on their behalf. So if you know an email is supposed to come from Google servers,
but instead it comes from some random email server in Brazil or something, you know it's fake.
Another is called DKIM, and it's a little bit more robust. And it not only allows you to verify the
sender of the email, but also that the email was not tampered with in transit. This isn't a perfect
analogy, but you can think of DKIM sort of like if you're writing a check and you fill it out and
sign it, and then say the bank has a copy of your signature on file that they can compare it to.
And they'll also see if the security paper that the check is made of has
been tampered with or not. The third technology is called DMARC,
and it basically ensures that the domain that the email is using for
verification is the same one that is actually displayed as the "from" address to the user.
Without DMARC, it would be like going to the bank with a check that you stole to cash,
and instead of signing the check owner's name, you signed "Abraham Lincoln." And then the bank said,
"Well, somebody signed it. Guess it must be legit." Without even
checking that the signature matches the checks owner that's listed on there.
So with that context, I can better explain how the scammers actually did this. First,
what the scammers did was set up an account with Microsoft
to create a instance of Exchange, which is Microsoft's email server system that you
can set up for your company and stuff. And this essentially lets your company have an
email service that Microsoft manages at the base level and you can configure and stuff.
Then the scammers sent themselves an email spoofing ups.com, which was blatantly fake.
And UPS's DMARC policies indeed even said to reject such an email. And you can see in the
headers that it said it failed. But apparently Microsoft allows you to configure your own
Exchange account to accept an email, even if it fails the DMARC policy that a website says that
you should treat for emails supposedly coming from them that fail the policy.
In this case, UPS said, "Hey, if this doesn't pass, then you should delete it." But effectively,
the scammers changed their account so that it accepted it anyway, knowing it would fail. Then
the scammer had their Exchange instance forward that email on to the final recipient at Gmail,
but preserved the so-called envelope info, which contains like the from address.
But here's the key point. UPS must have Microsoft as one of their email systems
because their SPF records that they publish do have Microsoft IP addresses in there as
being listed as allowed to send on behalf of UPS. And the scammers knew this. Therefore,
when Google received the forwarded email, they saw the From address as ups.com.
They saw the sending servers as from Microsoft,
and they saw ups.com's SPF records allowing Microsoft IPs to send UPS emails. Therefore,
they believe that the DMARC test "aligned," it's called, and authenticated the email.
And this is because at the time to show a verified checkmark, the BIMI checkmark,
the logo, then Gmail required that DMARC pass with alignment with either SPF or DKIM, but not both.
Which wouldn't necessarily be unreasonable if there wasn't more info in that chain
clearly showing that the DMARC failed in the original email being sent,
or anywhere else in the chain. They ignored that and only looked at the most recent link
in the chain. And while the DKIM test passed because it was sent and signed by Microsoft,
it didn't actually align with the From address.
But what I failed to remember in the previous video is that to pass the DKIM test, it doesn't
require being aligned. As long as there's some matching signature in the email headers, then
it might pass DKIM. But DMARC is the whole thing that decides whether it's aligned or not. And the
default policy mode for DMARC is to pass if either SPF or DKIM aligned, which in this case SPF did.
So what has been done about this and whose fault really was it? Well first of all,
with Google, I would say they're partly at fault because they authenticated the
email by not looking far enough back in the chain and seeing that the first
one out failed. They only looked at the most recent one. But now they have addressed that.
And now to show the BIMI checkmark, they require that DKIM specifically aligns and
DMARC passes. And that's because DKIM is a lot harder to spoof if it's possible at all.
So this should effectively fix that on Gmail. Next, I would say Microsoft is also partly at
fault because they allowed this whole nonsense to happen of just overriding the DMARC policy.
And you can even see in the headers that the Exchange server that scammers were using had
a action of "oreject", which is override reject, accept it, and forward on anyway,
maintaining the envelope part of the headers. Maybe there's a legitimate
reason for allowing that. I'm sure there is. But surely there also must be some way to
prevent this from being used in this type of scam, because it's a very specific scenario.
From what I've seen, Microsoft made a statement that basically said, "Hey, this
isn't our problem. This is an SPF problem that's been known about for a while," which I mean,
doesn't really satisfy me. Though that security researcher I mentioned before who was able to
replicate the attack, he did mention in one of his tweets, well, it was on Mastodon, but still.
He said that until now, this was possible on Microsoft's server. So I'm not sure if that
means it was patched or not, but hopefully it does, but I'm not sure. And finally,
is UPS at fault? And I guess you could make the argument that, "Yeah, they should have
had a strict DMARC policy." But it's not the default to be strict and it is relaxed.
So they kind of had their whole thing configured correctly and standard. And also after seeing
that literally two of the biggest trusted security companies could also be spoofed,
I don't think you can blame UPS for also being vulnerable to this. Because yes,
they did have Microsoft in their list of trusted servers for SPF,
but I mean, so do tons of organizations, tons of them use Microsoft for their email system.
And it turns out that there are like over 700 companies that have BIMI check marks and also
use Microsoft in some capacity and have that in their SPF records that would also be vulnerable
to this. That being said, UPS did end up removing Microsoft from their trusted SPF
servers. So they probably decided, "We're not even going to deal with this anymore."
Now, if you're wondering like me, if Gmail was the only email service that was susceptible to this,
so was I. But someone did actually do a test here and you can see that some were,
most weren't. They say iCloud was not susceptible,
but Apple Mail still did show it. I'm not 100% sure what the difference is there.
But regardless, now that there is a lot of attention being brought to this issue,
hopefully now every email service will require a stronger authentication,
at least for showing this super verified checkmark thing. Anyway,
that seems to be the full story of it. So let me know down in the comments what you think.
If you want to keep watching, the next video I'd recommend is one I recently made talking
about some advanced Windows features that you should at least know about,
even if you don't have to use them. They are pretty important. So I'll put that link right
there. And if you enjoyed this video, be sure to give it a thumbs up, subscribe if you want.
I make videos twice a week. And thanks so much for watching, and I'll see you in the next one.