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.
There actually was no e-mail, I just re-checked. I did a search for:
- usernotice@google.com
- Legal Investigations Support
- Google received and responded to legal process
Nothing from any of those =( It's been years, but there were two search warrants executed and both are in my discovery, but I was not notified of either via Google directly.
CFAA. Grand jury indicted because of the claims I created Bitcoin and BitTorrent, which are sort of presented as the same thing! Also maybe something something Comcast because he works there?
Firstly, BitTorrent and Bitcoin are two completely different technologies, neither of which I created or have committed code to. Nothing related to Comcast was involved and I never have worked there or any other company like that.
I had a great legal team. Very dedicated. Some areas offer great public defenders because the case load is much lighter than others.
Also it's kind of fun to see MD5 hashes used as evidence! I didn't know that was still a thing and I was curious of the legal grounds for the fact that any forensics expert could walk in and provide an equivalent of md5.gif proving it could be fabricated. I explained to my legal team that I could go home and create a version of my hard drive that is filled with repeating copies of the bible that matches all of those MD5 hashes. In legal battles you have to pick things best with your overall strategy.
I can say it was an interesting ride. I watched people overdose daily during COVID in Federal Prison among all kinds of other insanity. I never had any kind of security issues as I was in a lower security facility and many of them, even the "gang banger" ones, were relatively business minded and interested in how the darknet was changing the global drug trade and genuinely happy to have someone they viewed as talented willing to drop knowledge on it. They also loved the fact I could look "street check" other claimed hackers and fraudsters. If they couldn't answer a few basic questions from me they likely were never in any kind of "game" more complex than physically stealing peoples cards. Combine that with the infinite amount of Android rooting related work that needs done to keep the behind-the-bars mobile network functioning LMAO and I was doing fine.
My first cell-mate type person thing was a doctor. His name was Kumar. His friend came over, who also was a doctor, and someone said "Oh hey Kumar" to him as well. At this point I was starting to assume they just call all Indian people Kumar, because I had witnessed similar things. However, they both happened to be named Kumar. Also, they delivered his mail to me wrongly one time on accident. No envelope, etc. just a piece of paper. It was a bill for tens of millions of dollars and most of it had been paid. At this point I had became conditioned to strange paperwork that attempted to tell me I was screwed, so at first I was like "Oh, yeah? The computers I hacked were $20+ million?" before realizing it was his mail. IIRC he was there because he was scamming Medicare for cosmetic surgery like boob jobs and stuff.
Normally in Federal Prison even if you are a terrible baby murdering criminal, you get a little time outside, etc. During COVID things were fucked and it was 24-0 in the same 4 rooms for 6 months for me. Thankfully I had a good DnD campaign to run and worked up to being able to do some physical challenges like 100 push-ups in a single set, which when starting at 30 is impressive.
Ah yes, and I had you guys! I forgot, as I have mentioned this a few times in passing, but I setup a Puppeteer script that would scrape a few sites like HN that I enjoy and would put them into a PDF. It ran the same thing that would happen if you clicked reader mode so that the page was easy to read and it put 4 on a single page and sent it to a friend who would print it and mail it for me weekly. I could have used an API to do this, but the mailing rules are specific and I didn't want to risk it. My friend helped out and mailed that stuff for me and I received the front page of HN along with the articles in a weekly digest format. Originally I didn't know what the mail rules were so it had all kinds of weird search/replace regexes to avoid OCR or something weird, so articles about "HACKER FINDS BLAH" would turn into "WACKER FINDS BLAH" to avoid my mail getting turned away. (This would not have mattered AFAIK)
About those TRULINCS computers. I had decided not to fuck with them much in terms of hacking them. I did get curious a few times and navigate through their boot menus and check a few things out and there were some demons there. Some of the boot was locked down, but PXE boot attacks would work. And before you think "how the fuck would you...", just know you can pay two fine-running Hispanic gentlemen to bring anything inside at 2X cost and mostly it's by weight because they run outside and grab it and run back inside! It can be done with a Raspberry Pi to simply spoof the PXE. Why would someone hack the TRULINCS computer if they have an Rpi? Well, you can basically sit at those computers and use them without concern from a staff member, whereas using a contraband device requires stashing it, hiding, etc.
The guards didn't go inside the building during COVID. Those guys came in a few times dressed head to toe in bullshit-ass-made Amazon hazmat suits for a few days, then stopped coming all together, then eventually would come through with gas masks on a bit here and there. My time was very short as my case took a long time to reach a plea as there were very low damages and various statutes need damages to trigger IIRC.
One time when they came to check my living quarters while waiting for trial they found a bin of old parts. One of them was a power supply unit (PSU). They spent a considerable amount of time trying to determine "how much data it had" and asked me many questions about it. I was not allowed to have a phone at the time, so I could not simply take the product code on the side of it and show them the online retailer specs, etc. Those guys were genuinely trying to decipher the fucking mystery of how many gigabytes were inside that power supply. I will never forget that, and neither should you!
The FBI got tired of talking to me pretty quickly. Most of my answers created more questions that were of no value to anyone. "Do you remember any passwords used?" - "No" - "You don't remember one of them?" - "I'm not sure I remember which passwords I remember, do you remember which ones you've forgotten?" - "Try to think of one" - Closes eyes "I have thought of passwords" - "Can you remember one now?" - "Remember which ones I forgot?"
I remember when the FBI started taking me to the wrong building accidentally because they missed their turn I specifically said I didn't mind because we can stop at McDonalds before we get back on the highway to the US Marshals.
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 have some Google Takeout of my account but I have never searched through it yet. The only e-mails I know about are the ones between FBI <-> Google to get my entire account, which Google gave them.
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.
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.
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.
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 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.
> 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.
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.
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.
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.
This is true, but additionally, the HttpOnly flag is now mostly a relic, because so much web app logic runs in JS in the browser and makes API calls. That code generally needs access to tbe cookies, or something equivalent, like a bearer token.
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.
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?
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.
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.
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".
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.
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 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.
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.
>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).
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.
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/
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...
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?
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.
At what point do we rip it all off and restart?
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.
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.
- usernotice@google.com - Legal Investigations Support - Google received and responded to legal process
Nothing from any of those =( It's been years, but there were two search warrants executed and both are in my discovery, but I was not notified of either via Google directly.
Firstly, BitTorrent and Bitcoin are two completely different technologies, neither of which I created or have committed code to. Nothing related to Comcast was involved and I never have worked there or any other company like that.
I had a great legal team. Very dedicated. Some areas offer great public defenders because the case load is much lighter than others.
Also it's kind of fun to see MD5 hashes used as evidence! I didn't know that was still a thing and I was curious of the legal grounds for the fact that any forensics expert could walk in and provide an equivalent of md5.gif proving it could be fabricated. I explained to my legal team that I could go home and create a version of my hard drive that is filled with repeating copies of the bible that matches all of those MD5 hashes. In legal battles you have to pick things best with your overall strategy.
I can say it was an interesting ride. I watched people overdose daily during COVID in Federal Prison among all kinds of other insanity. I never had any kind of security issues as I was in a lower security facility and many of them, even the "gang banger" ones, were relatively business minded and interested in how the darknet was changing the global drug trade and genuinely happy to have someone they viewed as talented willing to drop knowledge on it. They also loved the fact I could look "street check" other claimed hackers and fraudsters. If they couldn't answer a few basic questions from me they likely were never in any kind of "game" more complex than physically stealing peoples cards. Combine that with the infinite amount of Android rooting related work that needs done to keep the behind-the-bars mobile network functioning LMAO and I was doing fine.
My first cell-mate type person thing was a doctor. His name was Kumar. His friend came over, who also was a doctor, and someone said "Oh hey Kumar" to him as well. At this point I was starting to assume they just call all Indian people Kumar, because I had witnessed similar things. However, they both happened to be named Kumar. Also, they delivered his mail to me wrongly one time on accident. No envelope, etc. just a piece of paper. It was a bill for tens of millions of dollars and most of it had been paid. At this point I had became conditioned to strange paperwork that attempted to tell me I was screwed, so at first I was like "Oh, yeah? The computers I hacked were $20+ million?" before realizing it was his mail. IIRC he was there because he was scamming Medicare for cosmetic surgery like boob jobs and stuff.
Normally in Federal Prison even if you are a terrible baby murdering criminal, you get a little time outside, etc. During COVID things were fucked and it was 24-0 in the same 4 rooms for 6 months for me. Thankfully I had a good DnD campaign to run and worked up to being able to do some physical challenges like 100 push-ups in a single set, which when starting at 30 is impressive.
Ah yes, and I had you guys! I forgot, as I have mentioned this a few times in passing, but I setup a Puppeteer script that would scrape a few sites like HN that I enjoy and would put them into a PDF. It ran the same thing that would happen if you clicked reader mode so that the page was easy to read and it put 4 on a single page and sent it to a friend who would print it and mail it for me weekly. I could have used an API to do this, but the mailing rules are specific and I didn't want to risk it. My friend helped out and mailed that stuff for me and I received the front page of HN along with the articles in a weekly digest format. Originally I didn't know what the mail rules were so it had all kinds of weird search/replace regexes to avoid OCR or something weird, so articles about "HACKER FINDS BLAH" would turn into "WACKER FINDS BLAH" to avoid my mail getting turned away. (This would not have mattered AFAIK)
About those TRULINCS computers. I had decided not to fuck with them much in terms of hacking them. I did get curious a few times and navigate through their boot menus and check a few things out and there were some demons there. Some of the boot was locked down, but PXE boot attacks would work. And before you think "how the fuck would you...", just know you can pay two fine-running Hispanic gentlemen to bring anything inside at 2X cost and mostly it's by weight because they run outside and grab it and run back inside! It can be done with a Raspberry Pi to simply spoof the PXE. Why would someone hack the TRULINCS computer if they have an Rpi? Well, you can basically sit at those computers and use them without concern from a staff member, whereas using a contraband device requires stashing it, hiding, etc.
The guards didn't go inside the building during COVID. Those guys came in a few times dressed head to toe in bullshit-ass-made Amazon hazmat suits for a few days, then stopped coming all together, then eventually would come through with gas masks on a bit here and there. My time was very short as my case took a long time to reach a plea as there were very low damages and various statutes need damages to trigger IIRC.
One time when they came to check my living quarters while waiting for trial they found a bin of old parts. One of them was a power supply unit (PSU). They spent a considerable amount of time trying to determine "how much data it had" and asked me many questions about it. I was not allowed to have a phone at the time, so I could not simply take the product code on the side of it and show them the online retailer specs, etc. Those guys were genuinely trying to decipher the fucking mystery of how many gigabytes were inside that power supply. I will never forget that, and neither should you!
The FBI got tired of talking to me pretty quickly. Most of my answers created more questions that were of no value to anyone. "Do you remember any passwords used?" - "No" - "You don't remember one of them?" - "I'm not sure I remember which passwords I remember, do you remember which ones you've forgotten?" - "Try to think of one" - Closes eyes "I have thought of passwords" - "Can you remember one now?" - "Remember which ones I forgot?"
I remember when the FBI started taking me to the wrong building accidentally because they missed their turn I specifically said I didn't mind because we can stop at McDonalds before we get back on the highway to the US Marshals.
Happy Saturday!
Hope you lawyered up and came out okay.
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.
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.
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.
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.
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.
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.
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 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 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.
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?
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.
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 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.
It doesnt really matter because email clients usually dont even show the email part of the from header.
Good email clients should, though.
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 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.
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.
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.
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.
> "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.
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
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.
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.
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.
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.
I thought script tags were an official part of SVG? Meaning that a valid SVG can contain embedded JS.
I don't think I've ever seen Google advertise Sites either? Why not GoogleSites.com?
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 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.
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.
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.
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".
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.
You can receive e-mail with a To: header saying anything. It doesn't have to be you.
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 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.
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
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.
DKIM signs both body and select headers. Unless those match, the signature verification will fail. TFA is about a replay attack.
[0] h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to;
>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).