Missing DMARC (P5) Needs Moving Inline with Email Spoofing (P3)

[Green-Wolf]

90% of breaches start via Phishing. This is aided if an attacker can successfully spoof a legitimate domain.

Email Spoofing (On the primary email domain) is currently listed as a P3, but missing DMARC is only a P5. As such it seems most of the vendors on Bugcrowd have SPF records, but are missing DMARC or have misconfigured DMARC. If DMARC is missing or set to 'p=none;' it causes SPF to fail open. When a spoofed email is sent, the receiver is checking the SPF, which fails, then looking at DMARC for what to do next, If DMARC doesn't exist then the spoofed email is accepted, effectively invalidating SPF and resulting in email spoofing.

For this reason missing or misconfigured DMARC should be brought inline and changed to a P3, as many customers are downgrading proven email spoofing to P5 because it is due to misconfigured DMARC.

[Green-Wolf]

It would also be interesting to have a discussion on where email spoofing falls when the cause is missing records? Some bounties say don't report DMARC/SPF(P5), but does that imply don't report legitimate proven email spoofing (P3) too? Currently it's a bit confusing.

[Green-Wolf]

https://posts.specterops.io/gathering-open-source-intelligence-bee58de48e05

This may sound like a small thing, but it can be a severe issue when misunderstood. Once, while working with a client, they had to respond to a nasty phishing incident. The attacker was, very convincingly, spoofing their email addresses to employees and other organizations. This simple check for DMARC and SPF records helped them understand what had happened. They thought SPF and vendor-provided email security solutions had spoofing on lockdown, so they moved to the next logical assumption, that the accounts had been compromised. However, they had never setup a DMARC record. Spoofing is a deceitfully difficult thing for many organizations because email security is so frequently misunderstood and so many exceptions are made for marketing, PR, automated alert emails, and other situations where spoofed emails are being used legitimately.

[trimkadriu]

I agree that email spoofing is an issue. Even though generally the SPF record should be enough for email providers to handle the spoofed emails properly, I've noticed cases specifically on Gmail that spoofed emails go through on inbox.

After we discussed this internally, we will have a more thorough research on this and will update this ticked accordingly.

In the meantime, I would appreciate anyone who could point out official docs on how different email providers handle email spoofing and their SPF & DMARC implementation.

[Green-Wolf]

Hi @trimkadriu, it's a funny one because it seems if they use '-all' at the end it's meant to reject just based on SPF. https://wordtothewise.com/2014/06/authenticating-spf/ However that is ignored for all the large providers such as Outlook, Gmail etc and it seems purely based on the DMARC record. This slide shows the secure setting for DMARC: https://youtu.be/w1fNGOKkeSg?t=2215 Basically p=none fails open, p=quarantine causes the email to go to spam and p=reject stops it being delivered. For the best security, i would recommend removing the 'Missing DMARC' P5 finding, and just leaving Email Spoofing, as you can either spoof or not. But there should clearly be a requirement for spoofing to a major provider(gmail,outlook,hotmail etc), not just some random mailserver you own! Currently its a coin toss as i've raised it on a bunch of programs and some stay at P3, others downgrade to P5, apparently just based on the whims of the reviewer on the managed programs.

[Green-Wolf]

Hello, just a little update. I've been in touch with Google about how GMail completely ignores SPF records if there is no DMARC record and they have confirmed this is how they want the service to operate. So unless you have SPF and DMARC, email spoofing will be possible to major providers. Other Email providers appear to have the same policy, that SPF on its own is not valid and will be ignored.

[trimkadriu]

Thanks @Green-Wolf for sharing these details.

I will give a brief update from our research as well. And later on I believe this could be a announced in more detail.

Initially, I would like to mention that as specified by the RFC 7208 - the SPF protocol it is mainly implemented to authenticate the allowed email senders (IP's) of a mail server rather than authenticate the person as where the email is coming from. So this was done intentionally to fight against SPAM'ers who sent emails by claiming they are legitimate senders of a specific email server. An example would be someone sending email from their IP address and tampering the mail from to be under a server with high reputation eg. microsoft.com. This would allow their emails to not be filtered in the email receiver server based on IP reputation. As mentioned by RFC 7208, SPF is only checking the mail from header value for authentication (a value which is never seen to the end user - different from the from value). That would be suitable for disabling SPAM. That is because, with SPF in place, email receivers can see if the IP of the sender is in the list of allowed IP's for that mail sender. Therefore, only implementing SPF by itself it seems that is not enough to be protected against email spoofing.

Still, different email providers regardless that they fully implement such protocols, they also add some of their own. As specified by Outlook docs, they also check the from value to be as a permitted sender regardless that SPF protocol does not require that. And that was also reflected during our tests (spoofing emails on Outlook was failing more than the others). However, on the other hand, Gmail seems to be embracing the standard protocols more, which would "allow" spoofed emails when the domain is missing DMARC. That was also mentioned on their public document here and here.

Without trying to go in more detail on this, below are the results of when emails can be spoofed on cases if the sender domain does not/have the SPF, DKIM & DMARC values specified (assuming correct configuration).

SPF	DKIM	DMARC	SPOOFABLE?
no	no	no	yes
no	no	yes	no
no	yes	no	yes*
no	yes	yes	no
yes	no	no	yes*
yes	no	yes	no
yes	yes	no	yes*
yes	yes	yes	no

* Generally it can be spoofed, but also depends on different email vendors.

As you can notice, all the rows where email results as spoof-able, it does not have DMARC set. So, I agree with what you initially suggested here and I propose to make a change on VRT to properly reflect this.

My suggestion is that we change the following entry:

Server Security Misconfiguration > Mail Server Misconfiguration > Missing DKIM/DMARC

to the one below:

Server Security Misconfiguration > Mail Server Misconfiguration > Missing DKIM/SPF

Because it seems that SPF & DKIM are questionable on protection against spoofing, while DMARC is definitive. While we leave the entry below as it is without specifying the case why the email is spoof-able:

Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofing on Email Domain

As always, would like to hear other opinions as well!

[plr0man]

Good research @trimkadriu. We've been seeing how SPF is becoming disregarded lately by some major email providers. As always we want to stay up to date so now seems to be a good chance to revise our baselines. Those could take effect in VRT v1.6 preceded by an appropriate announcement so everyone has a chance to catch up.

Based on the results provided above let's consider replacing all current variants of Server Security Misconfiguration > Mail Server Misconfiguration with:

P3 - Server Security Misconfiguration > Mail Server Misconfiguration > No Spoofing Protection on Email Domain

P4 - Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofing due to Missing or Misconfigured DMARC on Email Domain

P5 - Server Security Misconfiguration > Mail Server Misconfiguration > Missing or Misconfigured SPF and/or DKIM

The P4 variant has a lowered baseline due to spoofing indicators like a question mark thumbnail and others being presented to the recipient despite the spoofed email landing in the inbox.

Please take your time to point out any loopholes in the proposed classification.

[Green-Wolf]

Hey guys, thanks very much for having a look into this, i hope these steps will make companies take the issues a bit more seriously. My personal recommendation for the taxonomy me would this:

P3 - Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofing on Email Domain (This would be when the email lands in the inbox)

P4 - Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofing to Spam Folder on Email Domain (This would be when the email lands in the junk/spam folder)

P5 - Get rid of this, if spoofing isn't possible then it's no risk/not worth a bounty. We also shouldn't be giving off the impression that email spoofing is ever an informational issue, it shouldn't an easy option to just write it off and label it a P5.

My thinking on this is that we should be linking the taxonomy not to specific technologies or standards (SPF/DKIM/DMARC/Whatever comes next!), but we should be linking them to actual effect and impact.

By keeping P3 for Inbox and and P4 for Junk folder, it covers all of the edge cases. For example: What if they have DMARC p=quarantine, that's still going to show up in the Junk folder with the spoofed address, so P4. What if they have DMARC p=reject, but they have sendgrid in their SPF record, thats a valid DMARC, but if the attacker registers on sendgrid, they can spoof so P3. Then the standard case of missing DMARC or p=none will be spoofable to the inbox so P3.

[plr0man]

After further discussion with the team we've decided on implementing the following classification, which is inline with how we view security risk around email spoofing and includes updates to the DMARC baseline rating:

P3 - Server Security Misconfiguration > Mail Server Misconfiguration > No Spoofing Protection on Email Domain

P4 - Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofing to Inbox due to Missing or Misconfigured DMARC on Email Domain

P5 - Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofing to Spam Folder

P5 - Server Security Misconfiguration > Mail Server Misconfiguration > Missing or Misconfigured SPF and/or DKIM

Thanks all for your input!

[Green-Wolf]

Hi, no problem, glad to hear this is being addressed! Any chance I can get sent a Bugcrowd 'My other computer is your computer' T shirt for raising the issue/submission? 😄 (Don't ask don't get!)

[barnett]

Hey @Green-Wolf,

With a great contribution like this we are happy to send ya some swag! Mind sending an email to ~@bugcrowd.com~ with the email we can reach out to, to coordinate?

[anonhunter]

Hello everyone I've been watching the full conversation on your on Email spoofing. I have a question here, like yes When then spoofed email lands in the inbox thats an issue and has already been updated In the VRT 1.5 then what is Server Security Misconfiguration > Mail Server Misconfiguration > SPF Uses a Soft Fail? that is still remains in the VRT as P5 even after email lands in inbox.

On Thu, 1 Nov 2018 at 4:37 AM, Barnett Klane notifications@github.com wrote:

Hey @Green-Wolf https://github.com/Green-Wolf,

With a great contribution like this we are happy to send ya some swag, mind sending an email to vrt@bugcrowd.com with the email we can reach out to to coordinate?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues/195#issuecomment-434877913, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae46tizaQMQQ2PEmADwUiEQnd_3FtzjJks5uqi1EgaJpZM4XGUG1 .

[FatihEgbatan]

Hello @anonhunter

Thank you for your comment. "Server Security Misconfiguration > Mail Server Misconfiguration > SPF Uses a Soft Fail" still remains as P5 as you can see "P5 - Server Security Misconfiguration > Mail Server Misconfiguration > Missing or Misconfigured SPF and/or DKIM" will remain as P5 with next release.

[Green-Wolf]

Out of interested, where does the case of a shared email provider like sendgrid in the SPF policy come up on the VRT now? It's an issue with SPF (P5) but with the result of email spoofing the same as missing DMARC (P4)?