7 ms·

Google spoofed via DKIM replay attack: A technical breakdown

305 points by frasermarlow 1y ago

userbinator 1y ago
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.
- emsixteen 1y ago
  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?
  - tharkun__ 1y ago
    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.
  - userbinator 1y ago
    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.
- KevinMS 1y ago
  You cant spoof the header of the last trusted server, that's it.
logifail 1y ago
The author writes: > "Here is the URL from that email [..] https://sites.google.com 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.
- seszett 1y ago
  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).
  - asimpletune 1y ago
    The main failure is that dkim still passed even though the email was modified in important ways.
    - seszett 1y ago
      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.
      - aaronmdjones 1y ago
        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.
    - aaronmdjones 1y ago
      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.
shenbomo 1y ago
Why DKIM signature doesn't include the content of the email too?
- asimpletune 1y ago
  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.
  - jorams 1y ago
    > 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.
- seszett 1y ago
  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.
  - 1y ago
asimpletune 1y ago
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.
- JoshTriplett 1y ago
  > 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`.
  - globular-toast 1y ago
    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.
    - bawolff 1y ago
      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.
      - 1y ago
rvnx 1y ago
The people who found this exploit are very smart, and the phishing is really convincing + would pass most of the strictest corporate filters
- bawolff 1y ago
  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.
logicallee 1y ago
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.
- mzajc 1y ago
  > 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.
  - logicallee 1y ago
    Edit: thanks for the clarification.
    - mzajc 1y ago
      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;
- brongondwana 1y ago
  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.
judge123 1y ago
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?
- oefrha 1y ago
  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 https://news.ycombinator.com/item?id=44680400.
- monospacegames 1y ago
  "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.
- nicman23 1y ago
  flag forwarded mails?
oefrha 1y ago
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.
- monospacegames 1y ago
  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.
  - notepad0x90 1y ago
    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.
moongoose 1y ago
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.
- sksrbWgbfK 1y ago
  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.
- jeroenhd 1y ago
  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_sites_examples/ https://www.reddit.com/r/GoogleSites/comments/1ffz1a5/google... ; see websites like https://www.woofiepie.me/ https://www.woofiepie.me/ https://www.manuelfally.com/home https://www.manuelfally.com/home https://www.wedding-whisperer.com/ https://www.wedding-whisperer.com/
- onehair 1y ago
  I came here to say the opposite. Is this the screenshot you're mentioning? https://easydmarc.com/blog/wp-content/webp-express/webp-images/doc-root/wp-content/uploads/2025/04/1744359709180-767x1024.png.webp 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.
charcircuit 1y ago
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.
sandos 1y ago
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!
rkerno 1y ago
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'?
- monospacegames 1y ago
  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.
- jerf 1y ago
  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.)
arianvanp 1y ago
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.
- slig 1y ago
  I've been getting those for weeks, makes me think Google has given up email.
h1fra 1y ago
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.
detourdog 1y ago
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 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.
ddtaylor 1y ago
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.
- NitpickLawyer 1y ago
  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?
  - ddtaylor 1y ago
    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.
- zOneLetter 1y ago
  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...
  - ddtaylor 1y ago
    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. Happy Saturday!
upofadown 1y 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.
btown 1y ago
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.
artee_49 1y ago
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".
gunalx 1y ago
Ny main gripe with e-mail spam currently is hos difficult mainstream Clients make kt to actually review the headers.
brongondwana 1y ago
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-motivation/ 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/wg/dkim/documents/
- brongondwana 1y ago
  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-chuang-dkim2-dns/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header... https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi... https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce-processing/ https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce... https://datatracker.ietf.org/doc/draft-robinson-dkim2-message-examples/ https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...
- btown 1y ago
  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?
  - brongondwana 1y ago
    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.
igtztorrero 1y ago
So DKIM,DMARRK,SPF and all that stuff and we still get spam dangerous mail ?
- 1718627440 1y ago
  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.
guluarte 1y ago
Is Google Sites used for legitimate purposes? I've only seen them used for spam and phishing.
- Fishkins 1y ago
  At one point the org I work for used it for internal documentation. They migrated off of it many years ago, though.
happyopossum 1y ago
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).
happyopossum 1y ago
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...
dajonker 1y ago
Would this be preventable by setting strict alignment for SPF? i.e. aspf=s in the DMARC DNS record.
- justusthane 1y ago
  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 https://en.wikipedia.org/wiki/Email_forwarding
micahel00 1y ago
[dead]
anxman 1y ago
The wildest part about this? The phishing URL is still live on Google Sites! This article came out 3 months ago!

305 points by frasermarlow 1y ago

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.

emsixteen 1y ago
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?
- tharkun__ 1y ago
  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.
- userbinator 1y ago
  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.
KevinMS 1y ago
You cant spoof the header of the last trusted server, that's it.

logifail 1y ago

The author writes: > "Here is the URL from that email [..] https://sites.google.com 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.

seszett 1y ago
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).
- asimpletune 1y ago
  The main failure is that dkim still passed even though the email was modified in important ways.
  - seszett 1y ago
    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.
    - aaronmdjones 1y ago
      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.
  - aaronmdjones 1y ago
    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.

shenbomo 1y ago

Why DKIM signature doesn't include the content of the email too?

asimpletune 1y ago
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.
- jorams 1y ago
  > 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.
seszett 1y ago
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.
- 1y ago

asimpletune 1y ago

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.

JoshTriplett 1y ago
> 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`.
- globular-toast 1y ago
  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.
  - bawolff 1y ago
    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.
    - 1y ago

rvnx 1y ago

The people who found this exploit are very smart, and the phishing is really convincing + would pass most of the strictest corporate filters

bawolff 1y ago
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.

logicallee 1y ago

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.

mzajc 1y ago
> 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.
- logicallee 1y ago
  Edit: thanks for the clarification.
  - mzajc 1y ago
    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;
brongondwana 1y ago
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.

judge123 1y ago

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?

oefrha 1y ago
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 https://news.ycombinator.com/item?id=44680400.
monospacegames 1y ago
"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.
nicman23 1y ago
flag forwarded mails?

oefrha 1y ago

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.

monospacegames 1y ago
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.
- notepad0x90 1y ago
  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.

moongoose 1y ago

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.

sksrbWgbfK 1y ago
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.
jeroenhd 1y ago
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_sites_examples/ https://www.reddit.com/r/GoogleSites/comments/1ffz1a5/google... ; see websites like https://www.woofiepie.me/ https://www.woofiepie.me/ https://www.manuelfally.com/home https://www.manuelfally.com/home https://www.wedding-whisperer.com/ https://www.wedding-whisperer.com/
onehair 1y ago
I came here to say the opposite. Is this the screenshot you're mentioning? https://easydmarc.com/blog/wp-content/webp-express/webp-images/doc-root/wp-content/uploads/2025/04/1744359709180-767x1024.png.webp 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.

charcircuit 1y ago

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.

sandos 1y ago

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!

rkerno 1y ago

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'?

monospacegames 1y ago
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.
jerf 1y ago
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.)

arianvanp 1y ago

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.

slig 1y ago
I've been getting those for weeks, makes me think Google has given up email.

h1fra 1y ago

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.

detourdog 1y ago

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 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.

ddtaylor 1y ago

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.

NitpickLawyer 1y ago
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?
- ddtaylor 1y ago
  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.
zOneLetter 1y ago
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...
- ddtaylor 1y ago
  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. Happy Saturday!

upofadown 1y 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.

btown 1y ago

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.

artee_49 1y ago

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".

gunalx 1y ago

Ny main gripe with e-mail spam currently is hos difficult mainstream Clients make kt to actually review the headers.

brongondwana 1y ago

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-motivation/ 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/wg/dkim/documents/

brongondwana 1y ago
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-chuang-dkim2-dns/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header... https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi... https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce-processing/ https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce... https://datatracker.ietf.org/doc/draft-robinson-dkim2-message-examples/ https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...
btown 1y ago
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?
- brongondwana 1y ago
  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.

igtztorrero 1y ago

So DKIM,DMARRK,SPF and all that stuff and we still get spam dangerous mail ?

1718627440 1y ago
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.

guluarte 1y ago

Is Google Sites used for legitimate purposes? I've only seen them used for spam and phishing.

Fishkins 1y ago
At one point the org I work for used it for internal documentation. They migrated off of it many years ago, though.

happyopossum 1y ago

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).

happyopossum 1y ago

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...

dajonker 1y ago

Would this be preventable by setting strict alignment for SPF? i.e. aspf=s in the DMARC DNS record.

justusthane 1y ago
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 https://en.wikipedia.org/wiki/Email_forwarding

micahel00 1y ago

[dead]

anxman 1y ago

The wildest part about this? The phishing URL is still live on Google Sites! This article came out 3 months ago!