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.
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.
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. "
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.
This works against domains that have DMARC configured properly. First attack works against any domain that is using O365, regardless of their DMARC settings.
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.
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.
> 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.
Yes, they mention that Fastmail, GMX, Inbox.lv, and Pobox also allow per-user DMARC overrides, including overriding reject policy. But Microsoft is the only one of these using MFEF forwarding which enables the attack to be successful.
I suppose similar attack to the one in 5.1 would work against Fastmail, but the victim would be able to see the original envelope from to detect that the mail is spoofed.
"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."
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.
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.
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.
There's nothing inconsistent with that. Spear fishing techniques that rely on a number of bad practices, where thousands of people know what's wrong, survive as long as high volume spam is largely frustrated by post fact remediation, i.e. forcing some domain to disable open forwarding or suspending some account on too much of it.
Just to be clear for any future readers, they don't mean forwarding the email as in the forward button (which quotes or attaches it), they mean setting up mail forwarding on the entire inbox
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.
>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.
>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.
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.
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.
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.
> 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...
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).
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?
> A well targeted attack that doesn’t trip any training red flags (links, attachments, etc.) for the victim
As I understand it, the victim still has to click on a link in an email for the attack to work. The attack makes the email look like it comes from a legitimate source (like the victim's own company), but it still requires the victim to take an action, it's not completely passive.
Yes indeed. And that's the whole purpose of the domain impersonation -- the mail should look legit to the potential victim, so they follow up with the requested action (like signing up with their password on a phishing login page)
Paper in question: 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.
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?
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 :)
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.
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.
which is hilarious, since both companies are probably using a fax gateway anyhow. You end up with email-> gateway -> real fax -> gateway -> email. This is somehow easier than configuring a dmarc record.
> Microsoft confirmed the vulnerabilities (with
severity “Important”, the highest severity assigned to
email spoofing bugs) and awarded us a bug bounty. They
have partially fixed the issues by rejecting spoofed email
messages purporting to be from domains that have a
DMARC policy of REJECT
However, I could still replicate this on an o365 domain, so this attack would still work if attacker has access to an o365 domain.
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.
> 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.
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.
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.
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.
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.
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.
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://. Problem solved, no?
DMARC is DKIM or SPF so requiring DMARC part of the way to what you are suggesting. There is still a replay possibility with DKIM even if limited to replaying the exact same message (unless providers or email clients track already seen messages until DKIM expiration, which could happen but I don't think is happening at this point). I'm not an expert just someone trying to find a security focused email provider with minimally reasonable privacy policies that doesn't randomly drop email (which unfortunately doesn't seem to exist :( ) so I'm not sure why things are the way they are. Why SPF exists might just be due to being earlier and there not being any strong reason to stop using it.
Even Google and Microsoft aren't able to simply require whatever they want without a long transition period. I'm fairly sure Microsoft would like to make email entirely proprietary (and some of the issues almost only apply to them so they aren't likely to be the ones to improve email security). As best I can tell the people with the most direct financial interest in email are the marketers, which isn't a great situation for real improvement (BIMI seems primarily designed to replace the lost income from browsers dropping EV certificates while having similar issues). And security is a hard sell for anything it seems. So all in all I think we are lucky that Google has been doing as much as they have been. A number of old timers already complain about how it isn't really email any more. If Google did want to eventually require DKIM the path to get there would likely still look like what they have been doing.
There has also been recent activity just this year to improve the S/MIME situation (best practices document) and in a lot of ways requiring email to be signed by the sender rather than the sender's provider would be more helpful than requiring DKIM over SPF (although it isn't ideal to tie email to the CA system). Possibly we will see a push in that direction at some point.
> There is still a replay possibility with DKIM even if limited to replaying the exact same message (unless providers or email clients track already seen messages until DKIM expiration, which could happen but I don't think is happening at this point).
IIRC Gmail deduplicates based on Message-ID. But even if you replay an identical message... the date would still land it next to the original. So worst case you have two copies of the same thing next to each other. Which can (and already does!) happen occasionally when a server resends a message for whatever reason. It's hardly an issue.
Thanks! And good that Google at least likely deals with it ok. Just as a general thing it is a good idea to be very careful about replay possibilities and I think you are a bit too casually dismissive. Not every provider stores email forever (although storing just the DKIM signature could be done without too much trouble) and there are circumstances where receiving the same message as previously to a cleared inbox might not be an obvious duplicate if you don't happen to look at the date (which is not something I usually do when looking at email). Of course, this is already a potential issue today.
It is if the only thing preventing seeing a resent message as new is the recipient looking at the date or message id. Certainly it is arguable that the client and/or provider tracking seen signatures is a reasonable way to prevent it, but this isn't universally the case at this point and SPF if required (which it never is now unless DKIM isn't used at all) would at least prevent most third parties from doing this (at least without IP spoofing which would be disruptive to do bidirectionally). Not that this is necessarily a sufficient reason to justify using SPF over DKIM only just that it is a consideration. I don't know SMTP enough to know if someone between two servers who can block an encrypted connection at just the right point could cause the sending server to resend a delivered message but I would guess that might be possible. MTA-STS seems infrequently used at this point so currently someone between two servers could likely prevent the use of encryption.
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.
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.
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-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/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. "