I am [email protected] - DMARC at its finest
A while back, I was contacted by a friend of mine who received an interesting email. It was from a friend’s gmail account, but seemed to be written by Uber. He claimed that he never OAuthed with Google. After quite a bit of investigation, we landed on the conclusion that it was due to gmail’s DMARC policy. Essentially, DMARC has a few options of what to do on failure:
- Reject the email completely
- Quarantine the mail and report it
- Allow it to pass and ignore the failure
Can you see where this is going? Gmail’s DMARC policy is this:
v=DMARC1; p=none; rua=mailto:[email protected]
Which means they selected the 3rd option, to completely ignore DMARC failures. This means that as long as I have a valid SPF pass, like the one sendgrid provides me, I’m able to spoof any email from *@gmail.com to any address. Interestingly, it seems that Google has special filters for their own [email protected] address.
While Google doesn’t consider this a vulnerability, as described here, this misconfiguration spans far past gmail.com. After some testing, countless other domains are affected. Here’s just a few:
apple.com
ebay.com
github.com
slack.com
att.com
authy.com
chromium.org
android.com
firefox.com
stackoverflow.com
All of these sites will allow me to spoof emails from any address on their domain. We’ve reached out to a few of them, but the sentiment was consistently that this is a non-vulnerability.
Regardless, this has interesting implications for spearphishing campaigns. Imagine you received an email from [email protected] telling you about your icloud account or an email from [email protected] notifying you that your payment didn’t go through. The list of attack vectors this opens is endless.
While this misconfiguration isn’t considered a vulnerability, it did lead to some interesting insight on how Google defends against phishing and prioritizes risks. I strongly suggest reading this paper if the topic interests you. Thanks to my friend TJ Horner, who helped discover this.