3 ms·

The diagram demonstrating the attack shows DMARC fails. All they have shown is that everyone should have DMARC configured properly, and use a reject or quaranti

by tric 3y ago

The diagram demonstrating the attack shows DMARC fails. All they have shown is that everyone should have DMARC configured properly, and use a reject or quarantine policy. This has been best practice for a long time now. They use the example of state.gov. That domain's policy is currently set to Reject, which is what all Federal government services have been using for years now. Here's CISA's requirements: https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security https://www.cisa.gov/news-events/directives/bod-18-01-enhanc... Microsoft also uses their own auth mechanism in addition to DMARC. It's called composite authentication. In my experience, comp-auth is more strict than DMARC alone. https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-about?view=o365-worldwide#composite-authentication https://learn.microsoft.com/en-us/microsoft-365/security/off... What am I missing? Why is this noteworthy? EDIT: After reading more of the paper, my conclusion is mentioned in a later reply: "They are demonstrating a problem with managed providers, and their opinionated configuration. You give up a lot of control as an admin when you use 365 as your front-end. This further proves that. "

csharpminor 3y ago
I completely agree. As an aside, for .gov domains, the DMARC offenders are primarily at the state, county, and local level. I would personally be in favor of extending CISA’s DMARC requirements to anyone with a .gov domain (and revoking domains that are non-compliant). Another misconception among many CIO/CISOs is that securing your individual subdomain with DMARC is enough. For example, dmv.ca.gov might have DMARC on its subdomain but not on the root, allowing a scammer to make up their own subdomain like “vehicles.ca.gov” and scam people into paying for fake vehicle registration. Of course there are other mechanisms inbox providers use to protect recipients, but without a DMARC policy on the root domain the door is left open. This is especially prevalent at the state level where no one wants to own DMARC centrally.
- tric 3y ago
  > the DMARC offenders are primarily at the state, county, and local level. This has been my experience as well. Likely due to their systems being managed by lowest-bidder MSPs. Someone once shared their own analysis of each state's configuration a few years ago: https://old.reddit.com/r/sysadmin/comments/cawch1/united_states_dmarc_status_script/ https://old.reddit.com/r/sysadmin/comments/cawch1/united_sta... I wonder how it looks today.
  - hhh 3y ago
    https://gist.github.com/nicewrld/5aed533257f7469d6439f6a4646fdc3c https://gist.github.com/nicewrld/5aed533257f7469d6439f6a4646... output from the script as of today.
- Symbiote 3y ago
  The British government has specific advice (applicable to everyone) for securing domains that aren't used for email. https://www.gov.uk/guidance/protect-domains-that-dont-send-email https://www.gov.uk/guidance/protect-domains-that-dont-send-e...
peanut-walrus 3y ago
This works against domains that have DMARC configured properly. First attack works against any domain that is using O365, regardless of their DMARC settings.
- tric 3y ago
  Your domain may have a policy of reject or quarantine, but does the receiving host correctly act on that policy? I can understand if free email providers are more permissive with narrow authentication scenarios. Users aren't usually able to contact support. As someone suggested in this thread, this is a UX problem. Policies need to appease a large number of users. A gov/corp org receiving these messages can be more strict. Even in these orgs, people complain about not receiving an email that was appropriately rejected.
  - peanut-walrus 3y ago
    The attack works for spoofing email from domains that have DMARC configured with reject policy against receiving servers that validate DMARC and act correctly according to policy. Only requirement is that the domain the attacker is spoofing is using O365. This is not a UX problem. This is a Microsoft problem.
    - tric 3y ago
      > Only requirement is that the domain the attacker is spoofing is using O365. This is not true. The paper mentions multiple service providers using more relaxed validation. Table 3, section 5 in the paper shows which policies need to be in place on the domain they are piggy-backing on. They reference Postfix: "Additionally, we note that mailing list software such as Listserv and Mailman require a backend MTA. In our experiments we used Postfix with DMARC turned on, a configuration which follows good security practice. However, in practice many organizations might not use this configuration because many MTAs (including Postfix) do not enforce DMARC by default. In these cases, the attacker can spoof email from any target domain, regard- less of its DMARC policy, much like the attack against Gaggle." I read this to mean that if you actually enable DMARC in Postfix, piggy-backing on another domain's policies results in rejection. No mention of results for receiving at ProofPoint, Mimecast, Trellix, or Cisco's email appliance. > This is not a UX problem. They are demonstrating a problem with managed providers, and their opinionated configuration. You give up a lot of control as an admin when you use 365 as your front-end. This further proves that.

by tric 3y ago

csharpminor 3y ago

I completely agree. As an aside, for .gov domains, the DMARC offenders are primarily at the state, county, and local level. I would personally be in favor of extending CISA’s DMARC requirements to anyone with a .gov domain (and revoking domains that are non-compliant). Another misconception among many CIO/CISOs is that securing your individual subdomain with DMARC is enough. For example, dmv.ca.gov might have DMARC on its subdomain but not on the root, allowing a scammer to make up their own subdomain like “vehicles.ca.gov” and scam people into paying for fake vehicle registration. Of course there are other mechanisms inbox providers use to protect recipients, but without a DMARC policy on the root domain the door is left open. This is especially prevalent at the state level where no one wants to own DMARC centrally.

tric 3y ago
> the DMARC offenders are primarily at the state, county, and local level. This has been my experience as well. Likely due to their systems being managed by lowest-bidder MSPs. Someone once shared their own analysis of each state's configuration a few years ago: https://old.reddit.com/r/sysadmin/comments/cawch1/united_states_dmarc_status_script/ https://old.reddit.com/r/sysadmin/comments/cawch1/united_sta... I wonder how it looks today.
- hhh 3y ago
  https://gist.github.com/nicewrld/5aed533257f7469d6439f6a4646fdc3c https://gist.github.com/nicewrld/5aed533257f7469d6439f6a4646... output from the script as of today.
Symbiote 3y ago
The British government has specific advice (applicable to everyone) for securing domains that aren't used for email. https://www.gov.uk/guidance/protect-domains-that-dont-send-email https://www.gov.uk/guidance/protect-domains-that-dont-send-e...

peanut-walrus 3y ago

This works against domains that have DMARC configured properly. First attack works against any domain that is using O365, regardless of their DMARC settings.

tric 3y ago
Your domain may have a policy of reject or quarantine, but does the receiving host correctly act on that policy? I can understand if free email providers are more permissive with narrow authentication scenarios. Users aren't usually able to contact support. As someone suggested in this thread, this is a UX problem. Policies need to appease a large number of users. A gov/corp org receiving these messages can be more strict. Even in these orgs, people complain about not receiving an email that was appropriately rejected.
- peanut-walrus 3y ago
  The attack works for spoofing email from domains that have DMARC configured with reject policy against receiving servers that validate DMARC and act correctly according to policy. Only requirement is that the domain the attacker is spoofing is using O365. This is not a UX problem. This is a Microsoft problem.
  - tric 3y ago
    > Only requirement is that the domain the attacker is spoofing is using O365. This is not true. The paper mentions multiple service providers using more relaxed validation. Table 3, section 5 in the paper shows which policies need to be in place on the domain they are piggy-backing on. They reference Postfix: "Additionally, we note that mailing list software such as Listserv and Mailman require a backend MTA. In our experiments we used Postfix with DMARC turned on, a configuration which follows good security practice. However, in practice many organizations might not use this configuration because many MTAs (including Postfix) do not enforce DMARC by default. In these cases, the attacker can spoof email from any target domain, regard- less of its DMARC policy, much like the attack against Gaggle." I read this to mean that if you actually enable DMARC in Postfix, piggy-backing on another domain's policies results in rejection. No mention of results for receiving at ProofPoint, Mimecast, Trellix, or Cisco's email appliance. > This is not a UX problem. They are demonstrating a problem with managed providers, and their opinionated configuration. You give up a lot of control as an admin when you use 365 as your front-end. This further proves that.