Comment by noman-land | Hacker News Reader

Comment by noman-land | Hacker News Reader

"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.

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.

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.

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

>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.

The very next sentence in parent comment details the problem.

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.

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.

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.

Reply on news.ycombinator.com