In the vast landscape of online communication, mailing lists have been a staple for collaboration and information exchange. Google Groups, an evolution of traditional mailing lists, offers a platform where users can share messages, documents, and discussions. However, as the digital landscape evolves, so do the threats. Let’s delve into the history of mailing lists, the security vulnerabilities associated with Google Groups, and the compelling reasons for organizations to exercise caution when using them.
History of Mailing Lists and Google Groups
Mailing lists have a rich history dating back to the early days of the Internet, providing a structured means for group communication. Over time, Google Groups emerged as a popular platform, integrating email and web-based discussions seamlessly. However, with the conveniences came unforeseen security challenges.
Issues with Legitimate Emails and Mailing Lists
Legitimate emails sent from domains with enforced DMARC policies (p=quarantine or p=reject) were flagged as suspicious or blocked when routed through mailing lists. The enforcement mechanism intended to protect against phishing inadvertently categorized these genuine communications as potential threats.
To mitigate these challenges and ensure the uninterrupted functioning of mailing lists, providers, including Google Groups, implemented a crucial adjustment. When an email from a domain with an enforced DMARC policy reached a mailing list, the provider would rewrite the “From:” address. This rewriting process ensured that the email appeared to come from the mailing list itself, overcoming the DMARC policy constraints imposed by the sender’s domain.
The Security Hole: DMARC Exploitation
Targeting Google Group Addresses
Cybercriminals cleverly used the re-writing process of the “From:” address to their advantage by specifically targeting setups that allowed anyone on the web to contact the group. Exploiting this opening, hackers carried out attacks by deftly manipulating how Google handled the “From:” address, especially when the sender’s domain enforced a DMARC policy of either p=quarantine or p=reject. This sly manipulation allowed them to launch attacks and navigate through the established security measures.
The Exploit Unfolded
- Acquisition of a New Domain: Hackers acquire a new domain and enforce a DMARC policy of either quarantine or reject.
- Sending Spoofed Emails: Attackers send emails from their domain to Google Group addresses.
- Google’s Address Rewriting: Upon receipt, Google rewrites the “From:” address to match the domain of the Google Group recipient.
- Deceptive Reply-To Address: The Reply-To address reflects the original sender’s domain, i.e., the hacker’s email domain.
- Authentication Success: SPF and DKIM processes pass successfully for the Google Group address.
- BIMI Impact: In cases where the targeted domain has Brand Indicators for Message Identification (BIMI) in place, visual indicators are automatically displayed.
In the above example, we did research on our domain by trying out this loophole to show you the outcome.
1. We created a public Google Group address named [email protected]
2. We sent an email from a personal email ([email protected]) to [email protected]
Note: khatchoian.com got an enforced DMARC policy of p=reject
3. Upon email arrival, we saw how Google Groups rewrote the address to one of the Google Group addresses, by additionally adding the Display Name
4. We saw how SPF and DKIM were passed with the Group Google address domain, even though it was sent by another person
5. We saw how BIMI was also showing, even though it was not sent by someone within EasyDMARC
Why Organizations Should Exercise Caution with Google Groups
Public Mailing Lists and Security Implications
Maintaining a public mailing list where anyone can send an email poses inherent security risks. The exploit discussed reveals the potential for malicious actors to manipulate the communication channel, posing threats to organizational security.
Avoiding Critical Email Channels as Google Group Addresses
Organizations are strongly advised to refrain from using critical email channels, such as Sales, Support, Billing, or any other important communication channels as Google Group addresses. This proactive measure mitigates the risk of exploitation and safeguards crucial communication channels from malicious activities.
Conclusion
It’s important for organizations to grasp the background of mailing lists and be aware of the security risks linked to platforms such as Google Groups as they navigate the intricate realm of online communication. Taking careful steps, enforcing strict access controls, and avoiding the exposure of vital email channels can help organizations strengthen their defenses against ever-changing cyber threats.
We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.
You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us
So basically, those organizations who use Google Groups are the ones who need to do something about this.
I have a question…
(?) If your company is Not using Google Groups, is it possible for an illigitimate 3rd party to sign up a google groups account using your domain without anything stopping them?
(!!!) If they can, this poses a threat to all organizations, not just ones that are actively using Google Groups.
(>) In this case, we would need to preemptively sign up for and then lock down Google Groups.
That’s right!
As for your question, that’s only possible if that person has obtained your credentials. In the event that they have, they don’t even need to use Google Groups to impersonate you 😉
This is fascinating and of course very disconcerting. The whole point of DKIM is to authenticate the sender, end-to-end. Google’s method has completely circumvented this mechanism.
It would appear that Microsoft 365 groups do not process emails in this manner – can we confirm that comparison?
Mike, that’s true! The whole mailing list scenario and how it sends the email to the list was a huge blocker with DMARC, and the re-writing option with From: address fixed it but opened a hole for hackers.
We’re on the same page about checking out Microsoft 365. Our team’s planning a test to see how it handles that scenario. Stay tuned for updates – your insights are spot-on!
Possibly I’m dense, but I don’t see the hole here. If I subscribe to a group to which anyone can post, why would I assume that every posting I read on this group comes from a group administrator? That would be like assuming that every posting on Twitter/X was written by Elon Musk.
Henry, this is primarily targeted at organizations using Google Groups as their sales or support channel due to its cost-effectiveness. In other words, when someone outside the organization sends emails to sales@ or support@, it triggers an incoming email to everyone in that specific group. If the sender is subject to an enforced DMARC policy and cleverly modifies the Display Name, an unsuspecting employee may easily fall into the trap.
What is googles response to this exploit? The problem here is that Google charges each new email account as a new license seat, so Groups is the only cost effective way to create email lists for generic things like sales@ that need to go to many users at once.
As of now, there hasn’t been any update from Google in response to this exploit. While using Google Groups for cost-effective email lists is a common practice due to the licensing structure, it does pose security concerns, as highlighted in the article.
To address this, consider the following options:
1. For a cost-effective approach, explore Google’s Default Routing setup. This feature allows you to route incoming emails directed to a single recipient to other users.
2. Alternatively, explore dedicated platforms (Hubspot, Zendesk, etc.) designed to handle tickets and sales requests securely.
thanks for sharing. What do you see the ideal alternative for group email address distribution lists (e.g. sales, customerservice, etc.?
1. For a cost-effective approach, explore Google’s Default Routing setup. This feature allows you to route incoming emails directed to a single recipient to other users.
2. Alternatively, explore dedicated platforms (Hubspot, Zendesk, etc.) designed to handle tickets and sales requests securely.
ok what I am confused about here is why the sender rewriting was required in the first place?
why do legit emails sent to a mailing list get flagged as dangerous if they have a dmarc policy?
The default behaviour of a mailing list is:-
sender emails the list address ([email protected])
this should not fail any tests
the list then sends out the email to all members from the list address.
this also should not fail any tests
the only point that any issue should arise is if the mailing list tried to forward the email to list members form the original senders own address. But lists do not work this way, as this would defeat the point.
Sender address rewriting has been introduced by the majority of mailing lists to comply with domains that have enforced DMARC policies, ensuring their emails are not blocked. You can find more information on this topic at https://www.lsoft.com/manuals/17.0/advancedtopics/133HowdoesLISTSERVcomplywithDMAR.html
I wish email clients like Outlook or Gmail would flag email with a different From and Return-Path value. I haven’t found any extensions, experimental features or tools to use. This would solve the phishing problem once and for all. But it would flag all news and sales letters and MS/Google don’t want that.
Flagging emails with different From and Return-Path values could stir up trouble with legit emails. It’s not a one-size-fits-all fix. Many platforms (think Mailchimp, ConvertKit, Constant Contact) keep their own address in the Return-Path section for handling bounces. Sorting this out on their end first would make filters work way smoother 🙂
Very interesting and useful advice. But it is missing a critical piece to put into practice: what is the alternative to groups for Google Workspace users when needing a generic, multi-recipient mail address like [email protected] ?
1. For a cost-effective approach, explore Google’s Default Routing setup. This feature allows you to route incoming emails directed to a single recipient to other users.
2. Alternatively, explore dedicated platforms (Hubspot, Zendesk, etc.) designed to handle tickets and sales requests securely.
Would a Secure Email Gateway like Mimecast prevent this from happening by preforming these checks?
Not really, Winston.
very well done article. thanks.
Thanks, Michael!
Hello, today I tried to reproduce this issue with our test public Google group.
I created group testgroup@v*******n.com.
Then I send email from my foreign email address (@gmail.com) to the group testgroup@v*******n.com.
Member of that public group received message:
from: Viktor
to: testgroup@v*******n.com
date: Nov 23, 2023, 4:04 PM
subject: my test message
mailing list: testgroup@v*******n.com Filter messages from this mailing list
mailed-by: v*******n.com
signed-by: v*******n.com
unsubscribe: Unsubscribe from this mailing list
security: Standard encryption (TLS) Learn more
I dont see that Google changed “From” header.
At the same time, the message is signed by our domain key.
So, maybe Google fixed the issue already?
Victor, Google hasn’t altered the ‘From’ header because gmail.com got a DMARC p=none policy.
Try sending from a different address (e.g., @yahoo.com) or a test domain with an enforced DMARC policy, and you’ll see the change in the ‘From’ address.