Thread by @retr0reg

Interesting Gmail Prv-Esc Exploit you can exploit most organization that use @GoogleWorkspace, and won't be fixed indicated by Google.

I found this unintentional when working on SMTP/ DMARC, and accidentally forged my head-of-school's gmail account, bypassed access-control, and sent a trolling mail to all student of the school.

To being with, Properly set DMARC/SPF Protection will disable this exploitation. However, the DMARC/SPF Protection is NOT on by default for every Workspace (It's hard to configure and even if SPF on 90% of the DMARC will be set to none, which make no use), making 95% vulnerable!

Before we actually start, it's better if we know what dmarc/spf is; dmarc and spf are both mechanisms aimed at email authentication, but they tackle the problem in different ways and for different reasons. Think of SPF as the first line of defense—it allows the domain owner to specify which servers are authorized to send emails on behalf of their domain. When a receiving server gets an email, it checks if the email came from an authorized IP. If not, it can be flagged as suspicious or rejected. This helps prevent attackers from spoofing the sender’s email domain, which is huge for brand protection. dmarc builds on top of spf (and DKIM, another email authentication protocol). It allows the domain owner to set a policy for what to do if an email fails SPF or DKIM checks, whether to quarantine, reject, or allow it with a warning. Plus, DMARC provides reporting, giving insights into who’s trying to impersonate the domain. Both are needed because they strengthen email authenticity and protect recipients from phishing and spoofing attacks. Without them, anyone could send emails using sender address as your domain

However, as we mentioned, spf records do not work without dmarc; And here's the very first issue of Google workspace - even though all workspace configuration are defaulted with spf; However, the dmarc is null, even though your smtp server detects the issue; it does nothing.

But this not-defaulted-set behavior itself isn't severe enough for me to write a post about (since at the meantime, Gmail displace a 'via' next to the sender address when the mail isn't sent by original smtp server), this serve rather as the start of our exploitations;

Although that Google implements 'via' checks when the sender is from a different smtp source; However, all of these changed when the target of forgery exists in the Google Workspace! The via will be hidden, you will be displayed as exactly as the target, but most importantly ...

You obtained the target of forgery's workspace-group-access-control-settings at the meantime! This means that, for sensitive workspace group that might have strict settings on "who-can-send-to-group", "who-can-see", "who-can-reply" etc

This is what I wrote to Google:

"This is what you can abuse with this:"

1. NO DMARC/SPF Protections are set by default for any Google Workspace.
2. If the user exist in Google Workspace, this is what going to happen:Sender with only sender's address forged in Gmail Client will be displayed exactly as the forging user. The Avatar, Username etc

Google will Hide Previous Warnings regarding SMTP such as 'via' (stand for detected different source of SMTP Server) (This is a bypass on current mitigations).
Sender with only sender's address forged will be able gain the corresponded group privilege of the actual user. This means that can post a mail to a sensitive/protected group whatever they want

If this is not a abuse risk, I am certainly not sure what is. Imaging the impact this can bring to large, basic organization / facilities where not everyone is lucky enough to learn about these professional DMARC / SPF Spoofing Protection and have no idea they should even configure it, a single attacker can such easy pull this attack and send a mail of fire-alert/cc'ing to every user in a Group to download a malware, being exactly looking as the user with exact id, icon, no 'via' warning, no external warnings. (You have no way to identify the user is actually using a sender address from different SMTP Server). I can't tell you more what consequences this can bought not only to Google but everyone.
A fix will be so simply that you the 'via' tag even if the user-exist and do a very simple extent of verification of the SMTP Server (attacks use very not common SMTP Server address that can be verified by simply looking at them). Please treat this importantly, not only for me but for the basic security guideline.

For exploitations with, by simply changing the SMTP "Sender Address" using arbitrary SMTP client, Gmail / G-Workspace will entire believe that you are the exact sender with corresponded group-access privilege.

As I want to mention: Do not try exploit anything before asking for permissions! The wish for disclosing this is
a wish that everyone treat their dmarc/spf records seriously; severe exploitation / apts can based on a very simple smtp spoofing!
apps.google.com/supportwidget/…