Sending SPF and DMARC passing mail as any Gmail or G Suite customer
ezh.es
ezh.es
After it was not fixed, she publicly disclosed the issue and within 7 hours it was patched.
What broke in the process at Google? This issue allowed GSuite users to impersonate each other to send email. That is very serious.
Because people are afraid of megacorps. They've found the courage to disclose the issue, but they've also felt that the blow needs to be softened by praising Google's security team, despite their negligence in handling this issue.
Yup. Ninety days is fine. More people should choose ninety days up front and not allow themselves to be strung along indefinitely.
Project Zero actually has granted two exceptions to their policy (out of well over a thousand cases), both to rival companies (Apple and Microsoft). On the whole I would say you should resist doing this, just set the policy and reap the consequences whatever they might be. If somebody's $100Bn company burns to the ground because they couldn't get their shit together for three whole months too bad.
The reporter is only to blame if they actively exploit the vulnerability in order to harm users, not if they publish it publicly, with or without advanced notice to the company.
1) 90-day disclosure initially 2) assuming communication, I would agree to extend for another 30 days 3) 15 days more 4) 7 days more 5) 3 days more 6) 1 day more 7) 12 hours 8) 6 hours 9) 3 hours 10) 1 hour 11) publish
More work for me, sure, but it doesn't drag out things indefinitely and i think it would have (at the later stages) created a sense of immediacy to get this fixed.
The author might have a Google account which, if cancelled, would disrupt their life considerably.
Often a researcher will find a bug, report it, and then weeks or months later reply with a follow up that dramatically changes the scope or severity.
Based on all of my interactions with the Google VRP program, I consider it much more likely the researcher isn't giving the whole story about the timeline. They are super responsive, take shit seriously, and push teams to get patches out.
What's especially frustrating is that Fastmail have a special opaque sender header that only they can interpret, and they put a little "verified" icon on email that actually comes from them. So it's a vulnerability if I impersonate them, but not any other Fastmail user. Sigh. I'm a happy FM user, apart from that. But I'm going to keep bringing it up until they do something about it. At least let me blacklist my domain from being used by other accounts jfc.
How recently was this change made? I could still do it in 2018, but I wasn't able to do it just now. As you say, no signature on the message, which makes my DMARC record do something useful. That's really great, a huge relief.
(Wish I could modify my original post now).
It seems shortsighted to say email as a whole is a disaster for security and privacy.
I always wanted to test MS365, but never got around to it. IIRC if you don't configure DKIM, they'll still sign messages using your x.onmicrosoft.com perma-ID. I remember being surprised those signatures show as valid when received in GSuite since the DKIM signing domain is different than the sending domain. Does that have something to do with ARC sealing? It should be impossible, right?
I could be totally out to lunch though since I noticed that when trying to diagnose broken DKIM signatures on a domain.
I'm also skeptical with half the planet having SPF records that point to Microsoft or Google. The dependence on domain validation after that is what makes me think there could be a lot of bugs of this class hanging around.
I bet shared hosting is a massive disaster in this area too.
So anyone can sign for any domain for which they have published DKIM keys, and produce valid DKIM. It's DMARC that requires that a valid DKIM signature match the d= domain with the From domain to consider the message DMARC aligned and be awarded a DMARC pass. [or otherwise pass SPF checks and have SPF domain aligned with From domain]
Edit: typo, clarity
Yet given the nature of SPF and DMARC, they're inherently going to be pretty open to other tenants in the absence of IP-based isolation.
Perhaps each tenant could use a unique outbound IPv6 in future (if it reaches traction on servers), and have a small pool of such personal IPv6s allocated exclusively for their own email, across the other fallback systems?
DKIM is better as it uses cryptographic keys, but you need to give a cloud email host be access to these, or realistically load its own DKIM key into your DNS.
Any other ideas on ways to stop these kinds of cross tenant issues when designing cloud services? I'm assuming nobody will provision infrastructure per tenant due to scale and cost, but this is quite a serious issue underlining the risk of relying on a tenant account with public cloud providers when it comes to isolation.
If I recall correctly, DKIM setup is simply publishing the public key as a txt DNS record under your domain. Whoever has the fitting private key can then sign emails on your behalf. The cloud email host can without problem generate a new pair for every domain. So the "upload it's own DKIM key" is essentially creating a pair for you and telling you to set the public key as a certain DNS text entry. Pretty straightforward. Stopping the cloud provider to sign emails for you is also as simple as removing the DNS entry from your domain.
> I'm assuming nobody will provision infrastructure per tenant due to scale and cost
Actually, these services are available at a premium.
You can have any combination of DMARC, DKIM, and SPF. They are all distinct.
Though with DKIM there is no way for a receiver to know if a message should be signed unless there is also a DMARC policy. SPF on the other hand can be verified without DMARC at all.
If Gmail.com had a DMARC policy that required a correct dkim signature, then the attack would have been much harder.
Also, to be clear, gmail.com DOES have a DMARC and SPF policy and does not have or use DKIM.
As a trivia, there was also ADSP but it didn't really gained adoption: https://tools.ietf.org/html/rfc5617
Can you have a policy like that? I was under the impression that DMARC passes if either SPF or DKIM passes.
No you cannot, like you said: DMARC passes if either SPF or DKIM passes.
But what you can do is use the 'aspf' and 'adkim' settings to force strict alignment on SPF and/or DKIM for DMARC to pass.
We see some of our [0] customers using strict SPF alignment to basically force DMARC SPF alignment to fail most of the time, thus effectively forcing a DKIM requirement for DMARC to pass. We wouldn't recommend doing this though, unless you are already closely monitoring your email traffic, and getting close to 100% DMARC alignment.
Note that none of this would have helped against the vulnerability discovered in the OP though.
Whilst this general choice may not be the gaping security hole it feels like, because G Suite validates domain ownership, it does lead to people setting up G Suite, configuring their MX records (G Suite doesn't make SPF obvious to a new account, when I did it a few months ago for someone), and then people may email back and forth with a personal (likely Gmail) account to test it works.
Then, when they email someone with another mail server, they blame us when their SPF record is configured to block G Suite.
[1] You'd need permissions to enumerate the entire DKIM zone of the domain which you wouldn't have for a random domain and whilst you could by to bruteforce all selector names combinations between 1 and 63 characters long I wouldn't recommend doing so.
https://www.zdnet.com/article/google-fixes-major-gmail-bug-s...
I just go get multiple confirmations I'm talking to the right person now.