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:
How would this work with mailing lists/groups? A common pattern is to have emails from third parties to e.g. accounts-payable@example.com be auto-forwarded to members of the relevant team.
Would the end recipient team member's receiving system need to be set to "trust" the mailing list forwarder, or internally track what lists it is on to be able to understand that the original recipient accounts-payable is a valid recipient?
Glad you asked! In a similar way to ARC (but better). The mailing list/group would add its own signature, and potentially a Delta-Body or Delta-Headers describing what changes it made (so that the verifier could undo the changes and verify the original signature, plus determine which changes were made by which hop).
So I could tell that the message came through example.com, and verify their signature on the message, as well as verify that trusted.com had intended the message to go to example.com in the previous hop.
This is amazing and I really appreciate you commenting here, but wow, my gut feeling is that this just feels like a yearly car registration sticker on top of the previous year and then a razor blade cut through it to prevent someone from stealing it.
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.
I'll fill in the details for the curious. You receive an email from `usernotice@google.com` with this body:
Dear Google user,
Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.
For more information about how Google handles legal process, view our transparency report at http://www.google.com/transparencyreport/userdatarequests/legalprocess/.
Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.
Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.
Regards,
Legal Investigations Support
Google LLC
--
In the case of a Federal Grand Jury subpoena, the Government will request a delayed notification of 1 or 2 years to prevent the service provider (i.e. Google) from notifying you. A subpoena only provides generalized records and not content. So things like billing information, login records, etc.. are fair game. The government is required to obtain a search warrant for actual data (i.e. your emails). Typically, Google will not notify you about executed search warrants against your account.
Interesting. Would that request somehow get logged / tagged at some point and make its way into "your" account full data in say a GDPR "give me all the data you have related to my account" type of a request?
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.
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.
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.
I agree, the article is intentionally deceptive. It's written to make people think the part of the mail shown in the image is the whole email when in reality it's definitely followed by some text that would raise suspicion in any person.
And from what they do show, it doesn't look like the sites.google.com link was actually clickable, which will reduce the success rate of the attack substantially. I'm not sure if it's not clickable because the OAuth App Title field that the phishing contents is put in won't produce clickable URLs, because the email itself has been flagged by Gmail as suspicious and disabled links, or possibly both.
From what we do see we can also clearly see the "forwarded message" details are present at the top of the email. Then the author writes that the email has "no typos" while ignoring that it has very suspicious formatting. It's still likely people will fall for it, but the article author clearly is being deceptive about how sophisticated this attack actually appears.
> some text that would raise suspicion in any person
As someone who worked in IT-support I have to say this sentence is doing a lot of heavy lifting. I have seen people click on shadier things that looked much less credible. In fact I have seen the same people do it multiple times, even after it has been explained to them, multiple times and they have experienced consequences in the form of locked accounrs and the likes.
Real world users can be magnitudes dumber than you think they would be, even if they otherwise simulate the appearance of functional adults.
I have seen people who have a problem click away error dialogues with the explaination of the problem without reading the text. When asking what they clicked and why, they couldn't tell you if their life depended on it.
Yes, but my point is that the article is constructed in a way that deliberately obfuscates that there is unrelated text following the phishing message (quoting my initial comment: The full email is definitely in the format "scary text here" "actual google message", so something like "Give us all your money or die has been created as a google app")
This led to the initial response here being quite frantic (some people even claiming that DKIM is now pointless) because presumably not everyone read the article to its very end where the actual explanation is, and then went back to the first image to realize that the author has been intentionally misleading to sell their cybersecurity services.
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 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!
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.
I'm going to go out on a limb and guess you don't manually check the headers for every single email, or even only every one from Google and co, so are you doing something to flag or visualise this in some way?
Whenever I get an email that seems like it's a scam or scary like this I will open headers and the Received headers (sometimes even a From et. al. are enough) will give it away.
In zero cases did I care about SPF, DMARC or DKIM.
I recognize that this is not something non technical people or even technical people that don't know how email works and that don't have a broader technical ability/knowledge can usually use/do but it has worked 100% for me so far. knocks on wood.
I literally only skimmed the article looking for any place they might show all headers and finally when they had the list of Received I was like: duuuh, that's the first you should have looked at and this would be a non blog.
So of course it's still bad this happens as most folks, even technical ones, couldn't read email headers to save their lives and rely on little badges and filters based on things like DKIM to keep them safe.
The sibling comment basically answered for me; I don't check the headers unless I'm feeling suspicious, and such an immediate urgent call-to-action definitely counts as suspicious.
It helps that I'm using a client which shows all the headers by default, and I normally just scroll past them if I don't have doubts; all the mainstream consumerist ones seem to make that very difficult or even impossible.
If anything, it seems hiding these details is a way to increase blind trust in things like DKIM and promote learned helplessness, so they have the incentive to make clients opaque.
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.
> 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
Imagine explaining to a relative what dkim/dmarc/spf is!
These are all behind the scenes technology that users should not be aware of.
Honestly this attack is not as scary as it sounds. The article is being misleading to sell their product.
> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature.
I dont think that would really matter. How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.
> How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.
Perhaps if the address at which you received the email does not match any which are covered by the DKIM signature then your client could warn you about the potential for foul play?
I don't think that would be a good idea. The false positive rate would be too high and i don't think forging the to header is useful enough to phishing to make it worth it.
>These are all behind the scenes technology that users should not be aware of.
Every time I hear this statement, alarm bells ring in my head. We aren't immortal. None of us is omniscient, and unfortunately the bad actors we're trying to protect against obviously don't give two shits about getting their hands dirty. We can't just hide all implementation details from users, especially when today's users may of necessity become tomorrow's admins.
I've blown people's minds by spoofing "From" before. It's amazing the completely unwarranted level of trust people have in things. I tell people it's no different from me typing up a letter and putting "love from Mum" at the bottom.
I blame shiny email clients like Outhouse etc. It's really dangerous to make something look like a better system than it is. If email were still viewed as plain text I don't think it would be seen the same.
SPF (without dmarc) validates the envelope from, not the from header.
When DMARC is present, it changes this to be the normal from header (dmarc requires one of either spf or dkim to match the from header. So if dkim matches then spf doesn't have to)
> 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.
No, you can't expect everyone to know about every subdomain of google.com.
I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).
> I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).
IIRC, this is the main reason GitHub moved Pages to github.io
The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.
This is why your gmail attachments should show up on googleusercontent.com instead of google.com
Many years ago, some naive websites would let users upload images, but wouldn't validate their content; and some browsers would ignore file content type headers if they had a better guess. So an attacker could rename a .html to a .jpg, upload it as your user profile image, then direct people to www.example.com/avatars/eviluser.jpg and they'd get a HTML page and run its javascript.
That's why, to this day, you sometimes see websites sending the header "X-Content-Type-Options: nosniff" which tells Internet Explorer 8 not to guess the content type.
> The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.
This was solved a long time ago by marking such cookies as "HTTP only", preventing client-side scripts from reading their values.
Google does mark their account login cookies as both "Secure" (sent only over HTTPS) and "HttpOnly" (not exposed to client-side scripting). You can see this in the server response headers in the browser dev tools' network tab. Even a piece of first-party JavaScript loaded directly from google.com -- even with SRI -- cannot read these cookies for google.com.
> This was solved a long time ago by marking such cookies as "HTTP only"
That stops the attacker from exfiltrating your cookies with their evil JavaScript - but they can still have their script make http requests, and they’ll be made with your cookies.
Or they can throw up a fake login page, which will fool plenty of users because it’s on the right URL, and do what they like with your inputs. Lots of attack options.
SVGs are also images that can contain scripts if not validated.
It's also relevant that github.io is on the public suffic list, which impacts a bunch of downstream things and isolates the subdomains from each other.
Well there are a few different big failures, from not signing the To: to allowing long arbitrary content in an email sent from a legitimate Google address...
But I think Google sites is the most important one because it makes sites look like they are actually Google wherever one comes from, it could be a pop-under loaded by another site or whatever, I think it's a more universal avenue for phishing than just exploiting DKIM.
The To header was included in the DKIM signature. The reproduction section of the article shows the result of final delivery to the victim which shows the original To header. If that were removed it would invalidate the signature.
There have been a few exploits over the years relying on sites.google.com because of the need to use a subdomain to make things work for the exploiters.
I don't think I've ever seen Google advertise Sites either? Why not GoogleSites.com?
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'?
All of the alternatives that can actually happen involve handing over full control of the system to one company, and thereby eliminating email's major remaining value, which is that it is a thing not controlled by one company.
The technical problems are challenging but solvable. The human problems are not. Nobody with the resources to truly solve the problem is willing to do it to create an open platform where they don't get effectively all the money and control, but then, the rest of the world is not terribly willing to let them have all the money.
Hence the impasse we are at.
This is the problem you have to solve, not a technical one.
(See also "why the metaverse where we do things like share avatars across all services is a stupid idea that will effectively never happen". It writes well in a novel, but in practice it requires World of Warcraft to accept that someone can run around in it as Mickey Mouse while wielding a Call-of-Duty-branded sniper rifle, and none of the relevant rights holders will ever agree to that, for all kinds of reasons. The technical problems are also formidable but they are nothing next to the fact nobody will ever agree to this.)
Our secure, centralized and proprietary offering with native AI and blockchain layers will replace the obsolete cruft that is email. Already secured several DoD contracts and expect to fully replace email for all internal and external communications of the federal government by 2027.
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?
"Read the full email before freaking out" would probably be appropriate. This article is deceptive because it does not show the full email and only shows the phishing part. The full email is definitely in the format "scary text here" "actual google message", so something like "Give us all your money or die has been created as a google app", which would raise an eyebrow even in the most non-technical person.
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.
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.
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...
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".
No, it wouldn't. SPF alignment just verifies that the Envelope From address matches the Header From address, and in this case both are no-reply@accounts.google.com, so SPF is aligned.
Strict vs relaxed just specifies whether a subdomain address is aligned with a different subdomain (or root domain) address.
Note that autoforwarding an email, as is happening in the article, is different from clicking Forward in your mail client. When emails are automatically forwarded, generally all the headers, including Envelope From, are preserved, so to the recipient it looks like it came from the original sender, not the party who forwarded it.
It does. It's not obvious from the writing but Google actually sent this email to the attacker (which then redirected it mostly unchanged except for the To: header).
The main content of the email is text used for the "App Name" field of the attacker's OAuth app. This explains why the screenshot of the email actually does look weird, with unlinked URLs and weird formatting.
I'm pretty sure there is a lot more at the end of the email that makes it obvious it's not legitimate. But then I also understand how quite a few people wouldn't even get to the end.
The attacker did not change the To: header. This would invalidate the DKIM signature and result in a DMARC fail and the message landing in Spam (or being rejected).
You can receive e-mail with a To: header saying anything. It doesn't have to be you.
I don’t think the content was modified. If it had been then the signature would have been invalidated. The attacker found a way to send themself an email from Google that the author later replicated using Google workspace + a Google OAuth app. Then they replayed that because Google isn’t signing the “to” field.
> Then they replayed that because Google isn’t signing the “to” field.
Google is signing the To field (at least on all email they send me). The attacker didn't change that either, as displayed in the screenshots in the article. The attacker took an email legitimately sent from Google to them, then redirected it to the victim.
An equivalent real-world mail scenario would be me taking a letter from my bank to me, putting it in a new envelope, then sending it to you. Then your assistant takes it out of the envelope and puts it into your inbox. The letter in your inbox is a completely valid letter from said bank, intended for me.
There's two things in this article Google does badly: Allowing free input of an app name and putting it directly at the top of an email they send without preceding it with an indication what the email is about, and hosting user-managed websites on a subdomain of google.com.
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.
They may have changed the screenshots but I confirm that I received the same kind of email. Same technique and email from Google, the only difference was that it had some spam at the bottom of the email.
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.
>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).
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.
Yeah, I recently started to administer a mail server. Most Spam comes from gmail lists (always newly created) with tons of headers explaining, why this absolutely isn't Spam, sometimes even longer then the content of the message itself.
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.
> This means you can just copy a server's signature from a piece of mail it signed onto another piece of mail that it didn't send, and it will still look like it's been signed by the server and coming from that server.
DKIM signs both body and select headers. Unless those match, the signature verification will fail. TFA is about a replay attack.
DKIM doesn't decide which headers are signed, the mail server does (in the h= field). Gmail signs both To and From[0], but these don't control the 'real' recipient - the RCPT TO command in SMTP does. The recipient would presumably show wrong in the mail client, but since mailing lists and aliases are a thing, this is not suspicious by default.
I'm working on the solution to this (co-authors from Google and Yahoo, it's legit):
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/
How would this work with mailing lists/groups? A common pattern is to have emails from third parties to e.g. accounts-payable@example.com be auto-forwarded to members of the relevant team.
Would the end recipient team member's receiving system need to be set to "trust" the mailing list forwarder, or internally track what lists it is on to be able to understand that the original recipient accounts-payable is a valid recipient?
Glad you asked! In a similar way to ARC (but better). The mailing list/group would add its own signature, and potentially a Delta-Body or Delta-Headers describing what changes it made (so that the verifier could undo the changes and verify the original signature, plus determine which changes were made by which hop).
So you'd have something like:
DKIM2: i=1; mf=sender@trusted.com; rt=accounts-payable@example.com; d=trusted.com
DKIM2: i=2; mf=bounce@example.com; rt=me@mydomain.com; d=example.com
So I could tell that the message came through example.com, and verify their signature on the message, as well as verify that trusted.com had intended the message to go to example.com in the previous hop.
This is amazing and I really appreciate you commenting here, but wow, my gut feeling is that this just feels like a yearly car registration sticker on top of the previous year and then a razor blade cut through it to prevent someone from stealing it.
At what point do we rip it all off and restart?
... When the message is delivered? I think 0 or 1 message-rewriting proxies is typical, anything more is out of the ordinary.
Bah, the datatracker doesn't list the candidate documents. Here's some direct links:
https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header...
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi...
https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce...
https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...
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.
I'll fill in the details for the curious. You receive an email from `usernotice@google.com` with this body:
--In the case of a Federal Grand Jury subpoena, the Government will request a delayed notification of 1 or 2 years to prevent the service provider (i.e. Google) from notifying you. A subpoena only provides generalized records and not content. So things like billing information, login records, etc.. are fair game. The government is required to obtain a search warrant for actual data (i.e. your emails). Typically, Google will not notify you about executed search warrants against your account.
It's a Friday and your comment is the first thing that got me 10% awake. Please, do spill the tea. There must be a story there...
Interesting. Would that request somehow get logged / tagged at some point and make its way into "your" account full data in say a GDPR "give me all the data you have related to my account" type of a request?
Let me guess, the raid warrant got signed for either CFAA violations, wire fraud, or a conspiracy charge.
Hope you lawyered up and came out okay.
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've been getting those for weeks, makes me think Google has given up email.
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.
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.
I agree, the article is intentionally deceptive. It's written to make people think the part of the mail shown in the image is the whole email when in reality it's definitely followed by some text that would raise suspicion in any person.
And from what they do show, it doesn't look like the sites.google.com link was actually clickable, which will reduce the success rate of the attack substantially. I'm not sure if it's not clickable because the OAuth App Title field that the phishing contents is put in won't produce clickable URLs, because the email itself has been flagged by Gmail as suspicious and disabled links, or possibly both.
From what we do see we can also clearly see the "forwarded message" details are present at the top of the email. Then the author writes that the email has "no typos" while ignoring that it has very suspicious formatting. It's still likely people will fall for it, but the article author clearly is being deceptive about how sophisticated this attack actually appears.
Most people, even those looking out for something suspicious will let their guard down once they are convinced it is from a trusted and known source.
> some text that would raise suspicion in any person
As someone who worked in IT-support I have to say this sentence is doing a lot of heavy lifting. I have seen people click on shadier things that looked much less credible. In fact I have seen the same people do it multiple times, even after it has been explained to them, multiple times and they have experienced consequences in the form of locked accounrs and the likes.
Real world users can be magnitudes dumber than you think they would be, even if they otherwise simulate the appearance of functional adults.
I have seen people who have a problem click away error dialogues with the explaination of the problem without reading the text. When asking what they clicked and why, they couldn't tell you if their life depended on it.
Yes, but my point is that the article is constructed in a way that deliberately obfuscates that there is unrelated text following the phishing message (quoting my initial comment: The full email is definitely in the format "scary text here" "actual google message", so something like "Give us all your money or die has been created as a google app")
This led to the initial response here being quite frantic (some people even claiming that DKIM is now pointless) because presumably not everyone read the article to its very end where the actual explanation is, and then went back to the first image to realize that the author has been intentionally misleading to sell their cybersecurity services.
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.
Oooooh, finally!!!
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!
Step 3: Attacker sends the email from Outlook
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.
You cant spoof the header of the last trusted server, that's it.
I'm going to go out on a limb and guess you don't manually check the headers for every single email, or even only every one from Google and co, so are you doing something to flag or visualise this in some way?
I'm with the person you are replying to here.
Whenever I get an email that seems like it's a scam or scary like this I will open headers and the Received headers (sometimes even a From et. al. are enough) will give it away.
In zero cases did I care about SPF, DMARC or DKIM.
I recognize that this is not something non technical people or even technical people that don't know how email works and that don't have a broader technical ability/knowledge can usually use/do but it has worked 100% for me so far. knocks on wood.
I literally only skimmed the article looking for any place they might show all headers and finally when they had the list of Received I was like: duuuh, that's the first you should have looked at and this would be a non blog.
So of course it's still bad this happens as most folks, even technical ones, couldn't read email headers to save their lives and rely on little badges and filters based on things like DKIM to keep them safe.
The sibling comment basically answered for me; I don't check the headers unless I'm feeling suspicious, and such an immediate urgent call-to-action definitely counts as suspicious.
It helps that I'm using a client which shows all the headers by default, and I normally just scroll past them if I don't have doubts; all the mainstream consumerist ones seem to make that very difficult or even impossible.
If anything, it seems hiding these details is a way to increase blind trust in things like DKIM and promote learned helplessness, so they have the incentive to make clients opaque.
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.
> 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
Imagine explaining to a relative what dkim/dmarc/spf is!
These are all behind the scenes technology that users should not be aware of.
Honestly this attack is not as scary as it sounds. The article is being misleading to sell their product.
> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature.
I dont think that would really matter. How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.
> How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.
Perhaps if the address at which you received the email does not match any which are covered by the DKIM signature then your client could warn you about the potential for foul play?
I don't think that would be a good idea. The false positive rate would be too high and i don't think forging the to header is useful enough to phishing to make it worth it.
>These are all behind the scenes technology that users should not be aware of.
Every time I hear this statement, alarm bells ring in my head. We aren't immortal. None of us is omniscient, and unfortunately the bad actors we're trying to protect against obviously don't give two shits about getting their hands dirty. We can't just hide all implementation details from users, especially when today's users may of necessity become tomorrow's admins.
> always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass
This was the default state of email for a long time, and is still the level of caution some people apply to email: never trust `From`.
I've blown people's minds by spoofing "From" before. It's amazing the completely unwarranted level of trust people have in things. I tell people it's no different from me typing up a letter and putting "love from Mum" at the bottom.
I blame shiny email clients like Outhouse etc. It's really dangerous to make something look like a better system than it is. If email were still viewed as plain text I don't think it would be seen the same.
Note, you can't forge the from header if DMARC is turned on. The From header was not forged in the article afaict.
It doesnt really matter because email clients usually dont even show the email part of the from header.
> email clients usually dont even show the email part of the from header.
Good email clients should, though.
Isn't it also SPF's role to check that the From domain is allowed for the sender IP ?
No. (If you mean the from header)
SPF (without dmarc) validates the envelope from, not the from header.
When DMARC is present, it changes this to be the normal from header (dmarc requires one of either spf or dkim to match the from header. So if dkim matches then spf doesn't have to)
> 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.
My advice here is pretty standard: If you get an email that requires an action, go to the website directly. Don't click any links.
It adds friction, but does solve the problem. For banking/systems, I'd much rather have the friction.
The author writes:
> "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.
No, you can't expect everyone to know about every subdomain of google.com.
I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).
> I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).
IIRC, this is the main reason GitHub moved Pages to github.io
The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.
This is why your gmail attachments should show up on googleusercontent.com instead of google.com
Many years ago, some naive websites would let users upload images, but wouldn't validate their content; and some browsers would ignore file content type headers if they had a better guess. So an attacker could rename a .html to a .jpg, upload it as your user profile image, then direct people to www.example.com/avatars/eviluser.jpg and they'd get a HTML page and run its javascript.
That's why, to this day, you sometimes see websites sending the header "X-Content-Type-Options: nosniff" which tells Internet Explorer 8 not to guess the content type.
> The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.
This was solved a long time ago by marking such cookies as "HTTP only", preventing client-side scripts from reading their values.
Google does mark their account login cookies as both "Secure" (sent only over HTTPS) and "HttpOnly" (not exposed to client-side scripting). You can see this in the server response headers in the browser dev tools' network tab. Even a piece of first-party JavaScript loaded directly from google.com -- even with SRI -- cannot read these cookies for google.com.
> This was solved a long time ago by marking such cookies as "HTTP only"
That stops the attacker from exfiltrating your cookies with their evil JavaScript - but they can still have their script make http requests, and they’ll be made with your cookies.
Or they can throw up a fake login page, which will fool plenty of users because it’s on the right URL, and do what they like with your inputs. Lots of attack options.
SVGs are also images that can contain scripts if not validated.
It's also relevant that github.io is on the public suffic list, which impacts a bunch of downstream things and isolates the subdomains from each other.
> if not validated
I thought script tags were an official part of SVG? Meaning that a valid SVG can contain embedded JS.
he must have meant to 'sanitize' or 'filter'
The main failure is that dkim still passed even though the email was modified in important ways.
Well there are a few different big failures, from not signing the To: to allowing long arbitrary content in an email sent from a legitimate Google address...
But I think Google sites is the most important one because it makes sites look like they are actually Google wherever one comes from, it could be a pop-under loaded by another site or whatever, I think it's a more universal avenue for phishing than just exploiting DKIM.
The To header was included in the DKIM signature. The reproduction section of the article shows the result of final delivery to the victim which shows the original To header. If that were removed it would invalidate the signature.
The body of the e-mail was not modified whatsoever. Nor were any of the signed headers of the e-mail, including the Subject, From, and To headers.
There have been a few exploits over the years relying on sites.google.com because of the need to use a subdomain to make things work for the exploiters.
I don't think I've ever seen Google advertise Sites either? Why not GoogleSites.com?
This criticism is not for everyone, it’s for us, the audience on HN that want novel stuff that is more hard than this. This is boring.
A red flag for you yes, but your parents?
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'?
All of the alternatives that can actually happen involve handing over full control of the system to one company, and thereby eliminating email's major remaining value, which is that it is a thing not controlled by one company.
The technical problems are challenging but solvable. The human problems are not. Nobody with the resources to truly solve the problem is willing to do it to create an open platform where they don't get effectively all the money and control, but then, the rest of the world is not terribly willing to let them have all the money.
Hence the impasse we are at.
This is the problem you have to solve, not a technical one.
(See also "why the metaverse where we do things like share avatars across all services is a stupid idea that will effectively never happen". It writes well in a novel, but in practice it requires World of Warcraft to accept that someone can run around in it as Mickey Mouse while wielding a Call-of-Duty-branded sniper rifle, and none of the relevant rights holders will ever agree to that, for all kinds of reasons. The technical problems are also formidable but they are nothing next to the fact nobody will ever agree to this.)
Announcing new Thiel-backed startup: Shadowfax
Our secure, centralized and proprietary offering with native AI and blockchain layers will replace the obsolete cruft that is email. Already secured several DoD contracts and expect to fully replace email for all internal and external communications of the federal government by 2027.
The people who found this exploit are very smart, and the phishing is really convincing + would pass most of the strictest corporate filters
They could have just read the RFC. DKIM was made specificly to allow this sort of thing for back compat. Its not a new attack.
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?
"Read the full email before freaking out" would probably be appropriate. This article is deceptive because it does not show the full email and only shows the phishing part. The full email is definitely in the format "scary text here" "actual google message", so something like "Give us all your money or die has been created as a google app", which would raise an eyebrow even in the most non-technical person.
The one-liner is “emails you receive may be forwarded”. Article is really confusing and oversells the attack. See my other comment https://news.ycombinator.com/item?id=44680400.
flag forwarded mails?
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.
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.
The wildest part about this? The phishing URL is still live on Google Sites! This article came out 3 months ago!
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.
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...
TLDR:
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".
Would this be preventable by setting strict alignment for SPF? i.e. aspf=s in the DMARC DNS record.
No, it wouldn't. SPF alignment just verifies that the Envelope From address matches the Header From address, and in this case both are no-reply@accounts.google.com, so SPF is aligned.
Strict vs relaxed just specifies whether a subdomain address is aligned with a different subdomain (or root domain) address.
Note that autoforwarding an email, as is happening in the article, is different from clicking Forward in your mail client. When emails are automatically forwarded, generally all the headers, including Envelope From, are preserved, so to the recipient it looks like it came from the original sender, not the party who forwarded it.
See "Forwarding versus Remailing" here: https://en.wikipedia.org/wiki/Email_forwarding
Ny main gripe with e-mail spam currently is hos difficult mainstream Clients make kt to actually review the headers.
hosting sites under google main domain is for sure a bad decision, I could have easily been caught by that since I wasn't even aware of this feature.
Is Google Sites used for legitimate purposes? I've only seen them used for spam and phishing.
At one point the org I work for used it for internal documentation. They migrated off of it many years ago, though.
Why DKIM signature doesn't include the content of the email too?
It does. It's not obvious from the writing but Google actually sent this email to the attacker (which then redirected it mostly unchanged except for the To: header).
The main content of the email is text used for the "App Name" field of the attacker's OAuth app. This explains why the screenshot of the email actually does look weird, with unlinked URLs and weird formatting.
I'm pretty sure there is a lot more at the end of the email that makes it obvious it's not legitimate. But then I also understand how quite a few people wouldn't even get to the end.
The attacker did not change the To: header. This would invalidate the DKIM signature and result in a DMARC fail and the message landing in Spam (or being rejected).
You can receive e-mail with a To: header saying anything. It doesn't have to be you.
I don’t think the content was modified. If it had been then the signature would have been invalidated. The attacker found a way to send themself an email from Google that the author later replicated using Google workspace + a Google OAuth app. Then they replayed that because Google isn’t signing the “to” field.
> Then they replayed that because Google isn’t signing the “to” field.
Google is signing the To field (at least on all email they send me). The attacker didn't change that either, as displayed in the screenshots in the article. The attacker took an email legitimately sent from Google to them, then redirected it to the victim.
An equivalent real-world mail scenario would be me taking a letter from my bank to me, putting it in a new envelope, then sending it to you. Then your assistant takes it out of the envelope and puts it into your inbox. The letter in your inbox is a completely valid letter from said bank, intended for me.
There's two things in this article Google does badly: Allowing free input of an app name and putting it directly at the top of an email they send without preceding it with an indication what the email is about, and hosting user-managed websites on a subdomain of google.com.
The screenshot looks too real, something is off. Anything hosted on Google Sites has a huge Cookie Banner and an (i)-Info Icon to report abuse.
I guess they edited the screenshot.
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.
[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/
They may have changed the screenshots but I confirm that I received the same kind of email. Same technique and email from Google, the only difference was that it had some spam at the bottom of the email.
I came here to say the opposite.
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.
Technical details aside
>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).
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.
So DKIM,DMARRK,SPF and all that stuff and we still get spam dangerous mail ?
Yeah, I recently started to administer a mail server. Most Spam comes from gmail lists (always newly created) with tons of headers explaining, why this absolutely isn't Spam, sometimes even longer then the content of the message itself.
Edit:
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.
> This means you can just copy a server's signature from a piece of mail it signed onto another piece of mail that it didn't send, and it will still look like it's been signed by the server and coming from that server.
DKIM signs both body and select headers. Unless those match, the signature verification will fail. TFA is about a replay attack.
Edit: thanks for the clarification.
DKIM doesn't decide which headers are signed, the mail server does (in the h= field). Gmail signs both To and From[0], but these don't control the 'real' recipient - the RCPT TO command in SMTP does. The recipient would presumably show wrong in the mail client, but since mailing lists and aliases are a thing, this is not suspicious by default.
[0] h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to;
[dead]