7 ms·

Scammers can exploit email forwarding flaws to impersonate high-profile domains

204 points by sizzle 3y ago

gumby 3y ago
This feels like an implementation mistake by MS and G, not any kind of inherent design flaw (the latter being strongly implied by the article). It's a problem, and I'm glad it was explored, but c'mon.
- dsr_ 3y ago
  The inherent design flaw is that announcing via SPF "Oh, yes, and Google is allowed to forge email on my behalf" allows Google to forge email on your behalf. All else follows. The enemy of security is convenience, and it's very convenient to hand over mail to Microsoft, Google, etc.
noman-land 3y ago
"The original protocol used to check the authenticity of an email implicitly assumes that each organization operates its own mailing infrastructure, with specific IP addresses not used by other domains. But today, many organizations outsource their email infrastructure to Gmail and Outlook. As a result, thousands of domains have delegated the right to send email on their behalf to the same third party." "For example, state.gov, the email domain for the Department of State, allows Outlook to send emails on their behalf. This means emails claiming to be from state.gov would be considered legitimate if they came from Outlook’s email servers. As a result, an attacker can create a spoofed email–an email with a fake identity–pretending, for example, to come from the Department of State--and then forward it through their personal Outlook account. Once they do this, the spoofed email will now be treated as legitimate by the recipient, as it is coming from an Outlook email server."
- upofadown 3y ago
  >This means emails claiming to be from state.gov would be considered legitimate if they came from Outlook’s email servers. Well they are legitimate. SPF and DKIM are not intended to be used as some sort of authentication of the sender. In this case the server authorized to send mail for that domain is actually sending the mail. I don't see the problem here.
  - deleted 3y ago
    [deleted]
  - function_seven 3y ago
    The very next sentence in parent comment details the problem.
    - upofadown 3y ago
      The next sentence: >As a result, an attacker can create a spoofed email–an email with a fake identity–pretending, for example, to come from the Department of State--and then forward it through their personal Outlook account. That contains the incorrect assumption, that DKIM/SPF is intended and can be used as sender verification. Yes, if the DMARC policy can be and is set to "reject", if the receiving email server actually pays any attention to the DMARC policy, and the server only sends mail for one domain then you will make things harder for those spoofing emails. But DKIM/SPF has only ever been about server reputation. Retconing it without some sort of broad consensus is only going to lead to trouble down the way.
      - hedora 3y ago
        So, the problem is that DKIM/SPF doesn’t check end-to-end invariants, and instead checks a property that few end-users understand, and that zero end-users care about.
      - peanut-walrus 3y ago
        The problem here is that Department of State has set their DMARC policy correctly to reject and the victim is using a server that correctly checks the policy, so sender spoofing should not be possible. However, the Outlook server in between launders the email by 1) not honoring the DMARC policy and 2) rewriting the email headers to originate from Department of State. As DMARC requires that either SPF or DKIM alignment passes, the laundered email will pass the DMARC check on the victim's side who expects to be protected from this kind of spoofing. Really the solution here should be an extension to DMARC where you can set a policy that BOTH SPF and DKIM checks need to pass and be aligned in order for the email to be delivered, rather than just one.
- jiggawatts 3y ago
  But if they forward the email, then it'll look like it's coming from their own personal account. These multi-tenant mail sender orgs generally prohibit sending from domains that haven't been "verified". All of Microsoft 365 and Azure works this way. They don't let their customers spoof each other on shared infrastructure, you have to create TXT records in DNS zones to verify ownership.
  - deathhand 3y ago
    Each Office 365 tenant does not have a personal Exhange server. The sending smtp server is being shared and can be verified with the email headers. That is how this flaw works. I feel like an idiot because I see the same behavior with the variable 'not in my organization' with transport rules and how many false positives I've had. I can clearly see the usage of different exchange servers being used in my environment when my company acquires a bunch of users. It falsely flags them because they are using a different shared exchange resource.
    - jiggawatts 3y ago
      You can't use Office 365 to send email that appears to be from a different org. It is an authenticated mail relay, and it'll just reject your email. You have to verify that you own the domains that you use in the from address to send mail via their service.
  - belorn 3y ago
    The bug being described is that Microsoft will run spam checkers when receiving emails for Microsoft customers, and they will check domain ownership when sending outgoing emails, but they won't run spam checkers or check ownership when email are received to an address which is used for email forwarding. In addition, other major email services such like Gmail will not run spam checkers against Microsoft since they assume that Microsoft has done their due diligence when sending emails.
    - MichaelZuo 3y ago
      This doesn't seem correct, if Microsoft truly does not do so in this scenario then it's impossible for it not to have been known by many many thousands of people well before 2023.
- deleted 3y ago
  [deleted]
comboy 3y ago
http://web.archive.org/web/20230905131755/https://arxiv.org/pdf/2302.07287.pdf http://web.archive.org/web/20230905131755/https://arxiv.org/... Page 9 gives you an idea
rediguanayum 3y ago
Paper in question: https://arxiv.org/pdf/2302.07287.pdf https://arxiv.org/pdf/2302.07287.pdf. Apparently won the Euro Privacy and Privacy best paper. It publishes and draw attention to what in industry has been "known" lore about SPF and ARC vulnerabilities. Kudos to the authors.
eli 3y ago
Forwarding has always been a mess with SPF. The whole thing is a hack.
- tux2bsd 3y ago
  [dead]
- freedude 3y ago
  Yes, SPF makes forwarding suck
jeffbee 3y ago
Some security problems are in fact UX problems. Many of the fine points of this paper boil down to the fact that MUAs do not necessarily bring it to the user's prompt attention when messages are not DKIM authenticated. Some of these UI choices are, based on my personal experience, consequences of the fact that many large customers want features from email providers that are impossible to reconcile with strong authentication (i.e. they want to loop all their mail through some fourth-party system that is a piece of crap). If you suspect you might have received an email from Anthony Blinken, I suggest checking the DKIM signature.
- ale42 3y ago
  > If you suspect you might have received an email from Anthony Blinken, I suggest checking the DKIM signature. Definitely. But I think that the actual attack would rather be that you receive an e-mail (seemingly) from your bank asking to log in on some (phishing) portal, or from your ISP or whatever else urging to to install a (malware) software update...
  - pdonis 3y ago
    More good reasons to not click on links in emails. Use out of band methods instead (for example, if you think an email is from your bank, log on to their website separately, not through an email link, and check that way).
    - sizzle 3y ago
      For us working in tech- yes we can be vigilant, but for less tech savvy folks in large companies or government, good luck!
      - heywoods 3y ago
        I know everyone at my last company had to do compliance training with Kevin Mitnick for hours; not that I minded RIP. Fingers crossed my large company isn’t the outlier and people pay attention to the training. Still, this vulnerability is bad news. A well targeted attack that doesn’t trip any training red flags (links, attachments, etc.) for the victim is still a very real security threat, right?
jongjong 3y ago
That seems like a big deal given that most websites rely on email-based authentication.
Zetobal 3y ago
@dang can we fix the title? Scammers can exploit email forwarding flaws to impersonate badly configured high-profile domains.
pdonis 3y ago
TL/DR: The US government and large companies are too incompetent to maintain their own email infrastructure, and instead are opening themselves up to spoofing attacks.
peanut-walrus 3y ago
Hold on, am I reading the paper correctly? In the 5.1 attack, if you use "Add to contacts" in Outlook, this will bypass DMARC protection completely? So by adding someone to contacts you are essentially allowing their email to be spoofed? What the hell Microsoft?
- jabroni_salad 3y ago
  https://support.microsoft.com/en-us/office/add-recipients-of-my-email-messages-to-the-safe-senders-list-be1baea0-beab-4a30-b968-9004332336ce https://support.microsoft.com/en-us/office/add-recipients-of... Yes. Although I will say that ATP runs before safesenders or any other rule applies, and it's been hair trigger lately. Sadly this is the only way to do business sometimes. Every org has to deal with a couple other organizations that absolutely refuse to get their auth game together. Users just want their mail to work and the particulars don't matter to them. The result is that your contacts can be spoofed. If I (the admin) push back on this my boss will get a complaint like "jabroni is interfering with my bazillion dollar sale" and any argument to the contrary is obviously just me playing the blame game. So I whitelist it and now that company we are trading PDFs with can be spoofed by anybody and skips security scanning :)
  - peanut-walrus 3y ago
    I mean, yeah, I've been in that position, I get it for the poorly configured domains. However, if I set a DMARC policy for my domain to reject, I would expect at least Google and Microsoft who control something like 90% of the email market to respect that policy. The realist in me realises that there is probably a non-negative number of domains out there with dmarc set to reject but failing absolutely all spf and dkim checks, but this should be their problem, not the receiver's.
  - MichaelZuo 3y ago
    If the other organization insists on sticking to older methods, then best practice is for all parties involved to revert to the last commonly and unarguably fully agreed-to method of communication, which is most likely fax in the US.
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.
istillwritecode 3y ago
It's surprising that the paper doesn't even mention SRS (Sender Rewrite Scheme).
dataflow 3y ago
Can someone explain why DKIM isn't sufficient? I really don't get the point of SPF/DMARC/ARC everything else when DKIM exists. Why can't everyone just set up DKIM and consider the problem solved?
- teddyh 3y ago
  Well, at least DMARC is also necessary, since if you recieve an email lacking a DKIM signature, you can’t know if the email should have had a DKIM signature unless there is a DMARC record configured for the sender’s domain.
  - dataflow 3y ago
    Why not take the stance that every email should have a DKIM signature? Just like how we moved to "every website should use https". If you don't, your untrusted by default.
    - joveian 3y ago
      Google is slowly moving to reject mail that doesn't pass DMARC no matter the domain settings; it sounds like they are currently rejecting a percentage of messages that fail DMARC. https://support.google.com/mail/answer/81126 https://support.google.com/mail/answer/81126 The issue mentioned in the paper related to SPF is due to adding third parties to the SPF record who then allow spoofing (see table 3 at the top of page 9 in the paper for a summary of the four issues they describe). Hopefully, those third parties will fix that and more mail admins will be aware of the potential negative effects of adding a third party to SPF. It doesn't seem like SPF causes much trouble and if it was possible for DMARC to specify that both SPF and DKIM must validate then that would help in the case of issues with the DKIM signature cryptography. DKIM has a replay issue, although that is not as bad if the to and date fields are signed.
      - dataflow 3y ago
        If they're doing that, that seems like a move intended to prevent forwarding rather than one that's actually necessary for DKIM? Again, I don't see why DKIM isn't enough here. Like you said, replay attacks only work if you don't do DKIM properly, i.e. if you avoid signing some of the initial headers. So how about just... require them to be signed? Sign the message ID, sign the date, sign the addressees, sign the body... sign everything. If you don't, you're assumed to be risky, just like with http:// http://. Problem solved, no?
kgeist 3y ago
Reminded me of a story which happened earlier this year. Our organization has a bunch of servers in the local network which need to send emails. The admins decided that a firewall based on IP filtering is enough and didn't enable any other form of authentication for the email server. I accidentally found out that if I try to send an email directly via SMTP using a Python script, the email server misidentified me as a server (because we're both in the local network). The first thing I did as an experiment was to impersonate our CEO and send an email on his behalf with a fishing link to our chief security officer and other top managers. The link led to my own server hosted on OVH which tracked who opened the link. Basically, only one guy hesitated to open it, everyone else clicked on it (including CSO). DKIM/DMARC for the email were shown as valid in Outlook. If our organization, which is the largest IT company in the region, with a whole department of system admins, cound't set it up correctly, I'm afraid to think what happens in smaller companies.
- LeonM 3y ago
  > If our organization, which is the largest IT company in the region, with a whole department of system admins, cound't set it up correctly, I'm afraid to think what happens in smaller companies. I advice organizations on email infrastructure configuration for a living, and I can tell you from experience that many organizations, and even MSPs, get it wrong. However, the problem is often not technical, but cultural. Many system admins have a hard time accepting, or convincing their boss, that they need external consultancy for something as seemingly simple as email. It also doesn't help that for most MSPs, email is a loss-leader, their clients expect it to cost no more than a few bucks a month. In most organizations I have consulted, email is treated as a simple set and forget service. Admins are expected to whip up an SMTP service in an hour and move on to other tasks. Whereas the reality is that email has become a minefield of subtle configuration mistakes, and requires continuous monitoring.
zeroimpl 3y ago
I recently encountered a similar situation to this. My company uses O365, and I’ve got an application which sends emails to customers. The application just relies on postfix to relay through O365. Apparently we hadn’t added the public IP of this server to our SPF records. The results was O365 adds on some headers saying SPF=fail, but sends to the destination anyways. When the destination was gmail, gmail just ignored those headers and added on some SPF=pass headers since the email it received correctly came from O365. I’m guessing this is the lax validation the article is talking about, since I’d expect the receiving server to search for any FAIL headers in the email to reject.
teddyh 3y ago
It seems that SPF suffers from the same problem which CAA records had, before RFC 8657 fixed it.

204 points by sizzle 3y ago

This feels like an implementation mistake by MS and G, not any kind of inherent design flaw (the latter being strongly implied by the article). It's a problem, and I'm glad it was explored, but c'mon.

dsr_ 3y ago
The inherent design flaw is that announcing via SPF "Oh, yes, and Google is allowed to forge email on my behalf" allows Google to forge email on your behalf. All else follows. The enemy of security is convenience, and it's very convenient to hand over mail to Microsoft, Google, etc.

noman-land 3y ago

"The original protocol used to check the authenticity of an email implicitly assumes that each organization operates its own mailing infrastructure, with specific IP addresses not used by other domains. But today, many organizations outsource their email infrastructure to Gmail and Outlook. As a result, thousands of domains have delegated the right to send email on their behalf to the same third party." "For example, state.gov, the email domain for the Department of State, allows Outlook to send emails on their behalf. This means emails claiming to be from state.gov would be considered legitimate if they came from Outlook’s email servers. As a result, an attacker can create a spoofed email–an email with a fake identity–pretending, for example, to come from the Department of State--and then forward it through their personal Outlook account. Once they do this, the spoofed email will now be treated as legitimate by the recipient, as it is coming from an Outlook email server."

upofadown 3y ago
>This means emails claiming to be from state.gov would be considered legitimate if they came from Outlook’s email servers. Well they are legitimate. SPF and DKIM are not intended to be used as some sort of authentication of the sender. In this case the server authorized to send mail for that domain is actually sending the mail. I don't see the problem here.
- deleted 3y ago
  [deleted]
- function_seven 3y ago
  The very next sentence in parent comment details the problem.
  - upofadown 3y ago
    The next sentence: >As a result, an attacker can create a spoofed email–an email with a fake identity–pretending, for example, to come from the Department of State--and then forward it through their personal Outlook account. That contains the incorrect assumption, that DKIM/SPF is intended and can be used as sender verification. Yes, if the DMARC policy can be and is set to "reject", if the receiving email server actually pays any attention to the DMARC policy, and the server only sends mail for one domain then you will make things harder for those spoofing emails. But DKIM/SPF has only ever been about server reputation. Retconing it without some sort of broad consensus is only going to lead to trouble down the way.
    - hedora 3y ago
      So, the problem is that DKIM/SPF doesn’t check end-to-end invariants, and instead checks a property that few end-users understand, and that zero end-users care about.
    - peanut-walrus 3y ago
      The problem here is that Department of State has set their DMARC policy correctly to reject and the victim is using a server that correctly checks the policy, so sender spoofing should not be possible. However, the Outlook server in between launders the email by 1) not honoring the DMARC policy and 2) rewriting the email headers to originate from Department of State. As DMARC requires that either SPF or DKIM alignment passes, the laundered email will pass the DMARC check on the victim's side who expects to be protected from this kind of spoofing. Really the solution here should be an extension to DMARC where you can set a policy that BOTH SPF and DKIM checks need to pass and be aligned in order for the email to be delivered, rather than just one.
jiggawatts 3y ago
But if they forward the email, then it'll look like it's coming from their own personal account. These multi-tenant mail sender orgs generally prohibit sending from domains that haven't been "verified". All of Microsoft 365 and Azure works this way. They don't let their customers spoof each other on shared infrastructure, you have to create TXT records in DNS zones to verify ownership.
- deathhand 3y ago
  Each Office 365 tenant does not have a personal Exhange server. The sending smtp server is being shared and can be verified with the email headers. That is how this flaw works. I feel like an idiot because I see the same behavior with the variable 'not in my organization' with transport rules and how many false positives I've had. I can clearly see the usage of different exchange servers being used in my environment when my company acquires a bunch of users. It falsely flags them because they are using a different shared exchange resource.
  - jiggawatts 3y ago
    You can't use Office 365 to send email that appears to be from a different org. It is an authenticated mail relay, and it'll just reject your email. You have to verify that you own the domains that you use in the from address to send mail via their service.
- belorn 3y ago
  The bug being described is that Microsoft will run spam checkers when receiving emails for Microsoft customers, and they will check domain ownership when sending outgoing emails, but they won't run spam checkers or check ownership when email are received to an address which is used for email forwarding. In addition, other major email services such like Gmail will not run spam checkers against Microsoft since they assume that Microsoft has done their due diligence when sending emails.
  - MichaelZuo 3y ago
    This doesn't seem correct, if Microsoft truly does not do so in this scenario then it's impossible for it not to have been known by many many thousands of people well before 2023.
deleted 3y ago
[deleted]

comboy 3y ago

http://web.archive.org/web/20230905131755/https://arxiv.org/pdf/2302.07287.pdf http://web.archive.org/web/20230905131755/https://arxiv.org/... Page 9 gives you an idea

rediguanayum 3y ago

Paper in question: https://arxiv.org/pdf/2302.07287.pdf https://arxiv.org/pdf/2302.07287.pdf. Apparently won the Euro Privacy and Privacy best paper. It publishes and draw attention to what in industry has been "known" lore about SPF and ARC vulnerabilities. Kudos to the authors.

eli 3y ago

Forwarding has always been a mess with SPF. The whole thing is a hack.

tux2bsd 3y ago
[dead]
freedude 3y ago
Yes, SPF makes forwarding suck

jeffbee 3y ago

Some security problems are in fact UX problems. Many of the fine points of this paper boil down to the fact that MUAs do not necessarily bring it to the user's prompt attention when messages are not DKIM authenticated. Some of these UI choices are, based on my personal experience, consequences of the fact that many large customers want features from email providers that are impossible to reconcile with strong authentication (i.e. they want to loop all their mail through some fourth-party system that is a piece of crap). If you suspect you might have received an email from Anthony Blinken, I suggest checking the DKIM signature.

ale42 3y ago
> If you suspect you might have received an email from Anthony Blinken, I suggest checking the DKIM signature. Definitely. But I think that the actual attack would rather be that you receive an e-mail (seemingly) from your bank asking to log in on some (phishing) portal, or from your ISP or whatever else urging to to install a (malware) software update...
- pdonis 3y ago
  More good reasons to not click on links in emails. Use out of band methods instead (for example, if you think an email is from your bank, log on to their website separately, not through an email link, and check that way).
  - sizzle 3y ago
    For us working in tech- yes we can be vigilant, but for less tech savvy folks in large companies or government, good luck!
    - heywoods 3y ago
      I know everyone at my last company had to do compliance training with Kevin Mitnick for hours; not that I minded RIP. Fingers crossed my large company isn’t the outlier and people pay attention to the training. Still, this vulnerability is bad news. A well targeted attack that doesn’t trip any training red flags (links, attachments, etc.) for the victim is still a very real security threat, right?

jongjong 3y ago

That seems like a big deal given that most websites rely on email-based authentication.

Zetobal 3y ago

@dang can we fix the title? Scammers can exploit email forwarding flaws to impersonate badly configured high-profile domains.

pdonis 3y ago

TL/DR: The US government and large companies are too incompetent to maintain their own email infrastructure, and instead are opening themselves up to spoofing attacks.

peanut-walrus 3y ago

Hold on, am I reading the paper correctly? In the 5.1 attack, if you use "Add to contacts" in Outlook, this will bypass DMARC protection completely? So by adding someone to contacts you are essentially allowing their email to be spoofed? What the hell Microsoft?

jabroni_salad 3y ago
https://support.microsoft.com/en-us/office/add-recipients-of-my-email-messages-to-the-safe-senders-list-be1baea0-beab-4a30-b968-9004332336ce https://support.microsoft.com/en-us/office/add-recipients-of... Yes. Although I will say that ATP runs before safesenders or any other rule applies, and it's been hair trigger lately. Sadly this is the only way to do business sometimes. Every org has to deal with a couple other organizations that absolutely refuse to get their auth game together. Users just want their mail to work and the particulars don't matter to them. The result is that your contacts can be spoofed. If I (the admin) push back on this my boss will get a complaint like "jabroni is interfering with my bazillion dollar sale" and any argument to the contrary is obviously just me playing the blame game. So I whitelist it and now that company we are trading PDFs with can be spoofed by anybody and skips security scanning :)
- peanut-walrus 3y ago
  I mean, yeah, I've been in that position, I get it for the poorly configured domains. However, if I set a DMARC policy for my domain to reject, I would expect at least Google and Microsoft who control something like 90% of the email market to respect that policy. The realist in me realises that there is probably a non-negative number of domains out there with dmarc set to reject but failing absolutely all spf and dkim checks, but this should be their problem, not the receiver's.
- MichaelZuo 3y ago
  If the other organization insists on sticking to older methods, then best practice is for all parties involved to revert to the last commonly and unarguably fully agreed-to method of communication, which is most likely fax in the US.

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.

istillwritecode 3y ago

It's surprising that the paper doesn't even mention SRS (Sender Rewrite Scheme).

dataflow 3y ago

Can someone explain why DKIM isn't sufficient? I really don't get the point of SPF/DMARC/ARC everything else when DKIM exists. Why can't everyone just set up DKIM and consider the problem solved?

teddyh 3y ago
Well, at least DMARC is also necessary, since if you recieve an email lacking a DKIM signature, you can’t know if the email should have had a DKIM signature unless there is a DMARC record configured for the sender’s domain.
- dataflow 3y ago
  Why not take the stance that every email should have a DKIM signature? Just like how we moved to "every website should use https". If you don't, your untrusted by default.
  - joveian 3y ago
    Google is slowly moving to reject mail that doesn't pass DMARC no matter the domain settings; it sounds like they are currently rejecting a percentage of messages that fail DMARC. https://support.google.com/mail/answer/81126 https://support.google.com/mail/answer/81126 The issue mentioned in the paper related to SPF is due to adding third parties to the SPF record who then allow spoofing (see table 3 at the top of page 9 in the paper for a summary of the four issues they describe). Hopefully, those third parties will fix that and more mail admins will be aware of the potential negative effects of adding a third party to SPF. It doesn't seem like SPF causes much trouble and if it was possible for DMARC to specify that both SPF and DKIM must validate then that would help in the case of issues with the DKIM signature cryptography. DKIM has a replay issue, although that is not as bad if the to and date fields are signed.
    - dataflow 3y ago
      If they're doing that, that seems like a move intended to prevent forwarding rather than one that's actually necessary for DKIM? Again, I don't see why DKIM isn't enough here. Like you said, replay attacks only work if you don't do DKIM properly, i.e. if you avoid signing some of the initial headers. So how about just... require them to be signed? Sign the message ID, sign the date, sign the addressees, sign the body... sign everything. If you don't, you're assumed to be risky, just like with http:// http://. Problem solved, no?

kgeist 3y ago

Reminded me of a story which happened earlier this year. Our organization has a bunch of servers in the local network which need to send emails. The admins decided that a firewall based on IP filtering is enough and didn't enable any other form of authentication for the email server. I accidentally found out that if I try to send an email directly via SMTP using a Python script, the email server misidentified me as a server (because we're both in the local network). The first thing I did as an experiment was to impersonate our CEO and send an email on his behalf with a fishing link to our chief security officer and other top managers. The link led to my own server hosted on OVH which tracked who opened the link. Basically, only one guy hesitated to open it, everyone else clicked on it (including CSO). DKIM/DMARC for the email were shown as valid in Outlook. If our organization, which is the largest IT company in the region, with a whole department of system admins, cound't set it up correctly, I'm afraid to think what happens in smaller companies.

LeonM 3y ago
> If our organization, which is the largest IT company in the region, with a whole department of system admins, cound't set it up correctly, I'm afraid to think what happens in smaller companies. I advice organizations on email infrastructure configuration for a living, and I can tell you from experience that many organizations, and even MSPs, get it wrong. However, the problem is often not technical, but cultural. Many system admins have a hard time accepting, or convincing their boss, that they need external consultancy for something as seemingly simple as email. It also doesn't help that for most MSPs, email is a loss-leader, their clients expect it to cost no more than a few bucks a month. In most organizations I have consulted, email is treated as a simple set and forget service. Admins are expected to whip up an SMTP service in an hour and move on to other tasks. Whereas the reality is that email has become a minefield of subtle configuration mistakes, and requires continuous monitoring.

zeroimpl 3y ago

I recently encountered a similar situation to this. My company uses O365, and I’ve got an application which sends emails to customers. The application just relies on postfix to relay through O365. Apparently we hadn’t added the public IP of this server to our SPF records. The results was O365 adds on some headers saying SPF=fail, but sends to the destination anyways. When the destination was gmail, gmail just ignored those headers and added on some SPF=pass headers since the email it received correctly came from O365. I’m guessing this is the lax validation the article is talking about, since I’d expect the receiving server to search for any FAIL headers in the email to reject.

teddyh 3y ago

It seems that SPF suffers from the same problem which CAA records had, before RFC 8657 fixed it.