AFAIK you can't spoof the path listed in the Received: headers as all the servers on the path will add their own. That's always been my way of verifying where emails come from, and it's reassuring to know that I would've caught this one too. Emails coming from Google aren't going to take a detour through Microsoft servers.
This is terrifying. Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass… it doesn’t feel good to imagine their reaction.
This is still limited in what you can do though. For example you can’t use this to forge messages from other people’s Gmail accounts.
> When the message is forwarded, the original DKIM signature usually remains untouched as long as the email content and headers covered by the signature are not modified
It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature. They should just change how their signing is configured, and email clients should warn when the email is legit but the intended recipient could have been changed.
> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature
It is, which is why they had to preserve it. The screenshot of delivery under the reproduction section shows the original To: address. This isn't the address that it is delivered to; you can deliver an email to any address with any other To: field in it.
> This is terrifying. Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass… it doesn’t feel good to imagine their reaction.
I mean, this has been policy at my work for a while now, and in general is good practice for anything on the internet. We deal with a lot of small businesses or just individual contractors, a good chunk still don't even use MFA, or if they do are still falling victim to token theft. We then get malicious emails from these compromised accounts, so to our users - they pass all checks and look legitimate, after all it appears to be actually from our customers.
So yeah it's fair to treat everything with suspicion, especially email.
It seems the issue is that the to: field is signed, but the whole email can be forwarded afterward as though it were being sent from the source server to a person who wasn't actually a recipient.
In this case Google really did send an email to the strange domain, which then forwarded it to the recipient and made it seem as though it was coming from Google's server directly to the recipient.
This works as long as the recipient doesn't realize that they are not in the "to:" field.
Sadly, BCC is still a real thing, so the recipient system can't reliably tell that the recipient wasn't in the "to:" field and drop the message. That's one of the authentication holes that DKIM2 is planning to fix.
Okay, the technical breakdown is wild. But my first thought was: how on earth do I explain this risk to my non-technical boss or clients? If I say 'they can bypass DKIM with a replay attack,' their eyes will just glaze over. We need a simple, powerful way to communicate this stuff. Anyone have a good one-liner for this?
This is a very confusing read. It gives the impression that the attacker managed to manipulate the email body to insert their phishing link, by talking at length about how the sites.google.com link is suspicious (of course it is, no doubt about that). But at the same time, they don’t say or show evidence that the body was manipulated; in fact quite the opposite.
My understanding is that the DKIM signature contains a bh= field with a hash of the email body. While you can technically also include an optional I= field to limit the body length for hashing, so that an attacker can append to the body, which is a pretty big security hole, it’s probably never used by Google for such short emails (I checked some of my own emails from no-reply@accounts.google.com and they certainly don’t have I=). Therefore to pass DKIM and DMARC the body had to be intact, so the “phishing link” was actually from Google, just intended for a different recipient.
If my analysis is correct then TFA really is a lot of words to say a scary email was forwarded to wrong people to scare them. Scary of course, but much less scary than the “DKIM replay attack” title implies to technical people who are not deep into this subject.
Edit: Oh, I thought “The Takeaway?” was the end of TFA since it had CTA for their product. Apparently there’s an update below explaining the link was actually part of a Google OAuth app name which was then inserted into Google’s email template. Terrible writing and structuring of the article, burying arguably the most important part of the attack that made it somewhat convincing, and misleading readers to believe the attack can be used to send arbitrary content.
Edit 2: Other commenters pointed out that the screenshot of the email is conveniently cut off so the fixed part of the Google email template isn't shown. The attack is probably even more clumsy then it seems from the quite deceptive crop.
Yeah from what I understand the DKIM is checking out because they are literally forwarding an actual email they got from Google. The real attack vector is being able to coerce Google to send you an email whose text you control.
I wouldn't call the banner huge, at least not in the examples I've found at [1]. The cookie banner doesn't look out of the ordinary and hides when you start scrolling.
If I received an email from google with text formatted like this. I would automatically have doubts it's anythig genuine.
While Gmail isn't anything to boast about UI wise. Google often have good enough an consistent UI patterns where this screenshot looks like there was no thought put into it past slapping a google logo on top.
This trick of stuffing a huge mass of text into the title of something to make a Google email like this isn't a new trick and is a much bigger issue than this email not properly showing up as being forwarded.
I received almost exactly this email a couple of months ago, but targeted at a google domains admin! I was, of course, also spooked by it. I did wait out and avoided clicking links in it, but I could not really find any references to this scam.
What gave it away was that all email-addresses were masked, and those masks did not match up with any emails that I administer as a workspace admin. But yes, the email itself was legit, I googled that and the text passage matched. In my case it was an email for a deceased persons email, which ofc also did not match reality. But I was almost 100% at some point that someone had actually convinced Google I was deceased, and was going to access my entire Google account, talk about scary!
This to me just appears to demonstrate what a house of cards email security really is....surely with the collective brains on this forum we can come up with an alternative that solves all of this. And surely Google needs to serve these sites under a different domain name....why aren't these sites published under something like 'hostedbygoogle.com'?
I've seen a similar attack in my inbox recently where people do the same trick by sending an email to yourgoogleaccount@google.com instead of Gmail.com and then forwarding the bounce from Google's mail servers to yourgoogleaccount@gmail.com with a spam message smuggled at the end.
Passes all checks. Just kinda weird that a postmaster error is intertwined with a phishing campaign. But easy to gloss over as a non-technical user.
In my case the phishing campaign told me I won some construction tools or something.
I consistently get the same phishing emails. From the headers I assume they are coming from a google service. I have been reporting them using google's reporting page for over a year.
I actually have had the FBI seize all of my Google account materials before when I was convicted of computer hacking. The search took place in 2016 and 2018 as they came back and took everything a second time.
Anyhow, they don't do it at all like this. I would have to check my discovery for some details and it's in cold storage, but they basically just send an e-mail to a specific department at Google and have that communication. They go through a decent amount of trouble to try to NOT tip you off.
People keep trying to use DMARC as some sort of sender authorization scheme. It continues to be a server reputation scheme.
An unsigned email is still anonymous, no matter what DKIM and SPF say. It should be treated as such. No one should ever think: This email passed through a Google email server at one point. It must be legit.
IMO the real vulnerability here is that you can put a URL in the App Name for a Google OAuth app, and Google will render that in no-reply emails to arbitrary addresses from its root domain. (And even if that render is not clickable, if you make the surrounding text scary enough, the victim will navigate there.)
The fact that any number of keep-DKIM-intact forwarding services can be stacked on top is almost secondary - though educational.
There should be no legitimate reason for the App Name of an OAuth app to contain a URL, and especially one containing google.com. That is where this should be fixed.
Google allows you set input long paragraphs and URLs into a field called "App name" and they then send you an email with the paragraph you entered in (malicious with phishing links) to your inbox. Since this is sent by Google, it's DKIM signed and passes DMARC so you can simply download the entire email and just send it as a raw email to other people and it'll continue to be signed and land in their inboxes.
The other thing is that with these we cannot change the "To" header in the email (not envelope TO (which is where email is delivered to) but rather what shows up in the "To" when the client renders the email) and so the attacker bought a domain that looks like it's google owned "(rand)goog-ssl.com". When looking at emails in your inbox ensure that the "To" is always valid along with the "From".
Note that it doesn't help avoid Google actually sending out a message with user-provided text in it, but it does stop it being replayed to you without Google intending it, because the SMTP FROM/TO are protected.
The motivation draft doesn't include technical detail, see early drafts of the technical detail in the various related docs at:
>The branding and language were polished and professional
>There were no obvious grammar issues or suspicious attachments.
Really? No. Not even close to true. That looks nothing like professional, native-english-speaking legalese (which it would be if it were actually a notification from Google).
Post is several months old, and it appears that the underlying OAuth issue was fixed by Google a while back - you can't make arbitrarily long app names anymore...
36 comments
[ 5.1 ms ] story [ 66.9 ms ] threadAFAIK you can't spoof the path listed in the Received: headers as all the servers on the path will add their own. That's always been my way of verifying where emails come from, and it's reassuring to know that I would've caught this one too. Emails coming from Google aren't going to take a detour through Microsoft servers.
> "Here is the URL from that email [..] https://sites.google.com[...]"
THAT link is the first red flag, and I think the author should say so right there, not three paragraphs later.
This is still limited in what you can do though. For example you can’t use this to forge messages from other people’s Gmail accounts.
> When the message is forwarded, the original DKIM signature usually remains untouched as long as the email content and headers covered by the signature are not modified
It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature. They should just change how their signing is configured, and email clients should warn when the email is legit but the intended recipient could have been changed.
It is, which is why they had to preserve it. The screenshot of delivery under the reproduction section shows the original To: address. This isn't the address that it is delivered to; you can deliver an email to any address with any other To: field in it.
It adds friction, but does solve the problem. For banking/systems, I'd much rather have the friction.
I mean, this has been policy at my work for a while now, and in general is good practice for anything on the internet. We deal with a lot of small businesses or just individual contractors, a good chunk still don't even use MFA, or if they do are still falling victim to token theft. We then get malicious emails from these compromised accounts, so to our users - they pass all checks and look legitimate, after all it appears to be actually from our customers.
So yeah it's fair to treat everything with suspicion, especially email.
It seems the issue is that the to: field is signed, but the whole email can be forwarded afterward as though it were being sent from the source server to a person who wasn't actually a recipient.
In this case Google really did send an email to the strange domain, which then forwarded it to the recipient and made it seem as though it was coming from Google's server directly to the recipient.
This works as long as the recipient doesn't realize that they are not in the "to:" field.
My understanding is that the DKIM signature contains a bh= field with a hash of the email body. While you can technically also include an optional I= field to limit the body length for hashing, so that an attacker can append to the body, which is a pretty big security hole, it’s probably never used by Google for such short emails (I checked some of my own emails from no-reply@accounts.google.com and they certainly don’t have I=). Therefore to pass DKIM and DMARC the body had to be intact, so the “phishing link” was actually from Google, just intended for a different recipient.
If my analysis is correct then TFA really is a lot of words to say a scary email was forwarded to wrong people to scare them. Scary of course, but much less scary than the “DKIM replay attack” title implies to technical people who are not deep into this subject.
Edit: Oh, I thought “The Takeaway?” was the end of TFA since it had CTA for their product. Apparently there’s an update below explaining the link was actually part of a Google OAuth app name which was then inserted into Google’s email template. Terrible writing and structuring of the article, burying arguably the most important part of the attack that made it somewhat convincing, and misleading readers to believe the attack can be used to send arbitrary content.
Edit 2: Other commenters pointed out that the screenshot of the email is conveniently cut off so the fixed part of the Google email template isn't shown. The attack is probably even more clumsy then it seems from the quite deceptive crop.
I guess they edited the screenshot.
[1]: https://www.reddit.com/r/GoogleSites/comments/1ffz1a5/google... ; see websites like https://www.woofiepie.me/ https://www.manuelfally.com/home https://www.wedding-whisperer.com/
Is this the screenshot you're mentioning? https://easydmarc.com/blog/wp-content/webp-express/webp-imag...
If I received an email from google with text formatted like this. I would automatically have doubts it's anythig genuine.
While Gmail isn't anything to boast about UI wise. Google often have good enough an consistent UI patterns where this screenshot looks like there was no thought put into it past slapping a google logo on top.
I received almost exactly this email a couple of months ago, but targeted at a google domains admin! I was, of course, also spooked by it. I did wait out and avoided clicking links in it, but I could not really find any references to this scam.
What gave it away was that all email-addresses were masked, and those masks did not match up with any emails that I administer as a workspace admin. But yes, the email itself was legit, I googled that and the text passage matched. In my case it was an email for a deceased persons email, which ofc also did not match reality. But I was almost 100% at some point that someone had actually convinced Google I was deceased, and was going to access my entire Google account, talk about scary!
Passes all checks. Just kinda weird that a postmaster error is intertwined with a phishing campaign. But easy to gloss over as a non-technical user.
In my case the phishing campaign told me I won some construction tools or something.
https://support.google.com/mail/contact/abuse
Only in the last couple of weeks have a seen a decrease in one particular source. I always thought they were using a gmail mailing list service.
Anyhow, they don't do it at all like this. I would have to check my discovery for some details and it's in cold storage, but they basically just send an e-mail to a specific department at Google and have that communication. They go through a decent amount of trouble to try to NOT tip you off.
An unsigned email is still anonymous, no matter what DKIM and SPF say. It should be treated as such. No one should ever think: This email passed through a Google email server at one point. It must be legit.
The fact that any number of keep-DKIM-intact forwarding services can be stacked on top is almost secondary - though educational.
There should be no legitimate reason for the App Name of an OAuth app to contain a URL, and especially one containing google.com. That is where this should be fixed.
Google allows you set input long paragraphs and URLs into a field called "App name" and they then send you an email with the paragraph you entered in (malicious with phishing links) to your inbox. Since this is sent by Google, it's DKIM signed and passes DMARC so you can simply download the entire email and just send it as a raw email to other people and it'll continue to be signed and land in their inboxes.
The other thing is that with these we cannot change the "To" header in the email (not envelope TO (which is where email is delivered to) but rather what shows up in the "To" when the client renders the email) and so the attacker bought a domain that looks like it's google owned "(rand)goog-ssl.com". When looking at emails in your inbox ensure that the "To" is always valid along with the "From".
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
Note that it doesn't help avoid Google actually sending out a message with user-provided text in it, but it does stop it being replayed to you without Google intending it, because the SMTP FROM/TO are protected.
The motivation draft doesn't include technical detail, see early drafts of the technical detail in the various related docs at:
https://datatracker.ietf.org/wg/dkim/documents/
>The branding and language were polished and professional >There were no obvious grammar issues or suspicious attachments.
Really? No. Not even close to true. That looks nothing like professional, native-english-speaking legalese (which it would be if it were actually a notification from Google).