MTA-STS versus DANE

As part of NCSCs recommendations to harden mail across the public sector, the authority released a “loosely” followed mandate to adopt MTA-STS (Message Transport Strict Transport Security) Its worth considering there are some less acknowledged vulnerabilities which can me mitigate by adopting DANE (DNS Auth for Named Entities)

It has been published that the U.S. (UK) Government’s selection of MTA-STS is driven by the desire to leverage cloud-hosted E-Mail solutions coupled with a perception that cloud E-Mail hosting providers can largely support only MTA-STS and not DANE-SMTP with DNSSEC.

DANE-SMTP

DANE-SMTP (RFC7672) uses DNSSEC to ensure:

  • The integrity of the MX records of the receiving domain, preventing DNS cache poisoning or other MiTM attacks from redirecting E-Mail to rogue servers.

  • Downgrade-resistant publication of DANE TLSA records that make it possible for SMTP clients to properly authenticate the TLS certificate of the MX hosts they are sending mail to, thereby ensuring that network-layer attacks (BGP hijacks, …) cannot hijack SMTP traffic. SMTP’s STARTTLS feature alone cannot prevent these attacks.

MTA-STS (RFC8461) is a less secure E-Mail protection mechanism,per its own specification description, than DANE-SMTP. It is useful only for domains that are for some reason unable to deploy DNSSEC. Its weaknesses are also documented in its specification in Section 10 of RFC8461.

Security weaknesses of MTA-STS mitigated by DANE-SMTP

MTA-STS, as RFC8461 itself acknowledges, is less secure than its DANE-SMTP counterpart. Specifically:

  • Discovery of MTA-STS policy relies on unprotected DNS TXT lookups, which can be blocked or forged by active attacks. When these lookups fail due to attacks or from operational issues, MTA-STS falls back to unauthenticated opportunistic STARTTLS which is vulnerable to active attacks.

    Fallback to insecure SMTP delivery on an SMTP client’s failure to look up the MTA-STS TXT record happens even when a domain is protected by DNSSEC, and thus DNSSEC itself is not a sufficient solution to this problem. MTA-STS policy discovery is designed to effectively be “best-effort” by falling back to insecure delivery.

  • MTA-STS SMTP clients must unavoidably trust the full set of WebPKI public Certification Authorities when validating the SMTP server’s X.509 certificates they connect to. In order to ensure E-Mail delivery around the world, the list of trusted CAs necessarily includes CAs operated by nation states potentially hostile to the USG.

    In contrast, DANE-SMTP trusts only the DNS keys leading from the root zone to the E-mail recipient’s domain and to the domain of the E-Mail hosting provider (if the domain’s SMTP server is not self-hosted). Unlike with WebPKI, the keys of unrelated TLDs and parent domains are not trusted when delivering to a given (e.g. a subdomain of .GOV) recipient domain.

The MTA-STS specification acknowledges these weaknesses in section 10 and section 2 which notes (last paragraph) that in order to avoid downgraded security MTA-STS success must not preempt DANE-SMTP policy failure.

It should be highlighted that DANE is a recent addition to Exchange online - moreover it remains our recommendation that to provide best in class mail protection standards, both MTA-STS and DANE are implemented.

Its worth noting that despite many third party MTA providers (Proofpoint / Mimecast / Fortra SEG - the list goes on...) - not one of them provides correct and proper guidance how to interop correctly with EOP enhanced filtering - which is critical to a securely configured EXO tenant with MX records resolving to a hosted mail gateway service.

With Enhanced filtering disabled (by default) MTA providers do not typically advise enabling it, this is problematic.

In a disabled state EOP will expect the last hop to orginate from a legitamate source published in the senders SPF. Obviously this is never going to be the case - as the last hop is the receiving MTA. Therefore SPF will fail - for EVERYTHING.

The simple way to resolve this in EXO is to enable enhanced filtering with the flag "ignore last IP" - which removes the hosted MTA service from the SPF chain. Therefore SPF pass - all good!

OR IT ISNT.

As enhanced filtering is more strict and and all P1 / P2 header mismatches will be seen by Defender as spoofed senders.

To clarify:


As P1/ /P2 header mismatch wont rely on SPF to authenticate the mail, the answer lies in a well configured DKIM signing policy on the senders side additionally ARC sealer auth.

This ofcourse further complicates things as the onus is on sending org, in summary Microsoft arent there yet - nor are the 3rd partys. We can secure receive, but if the sender isnt well configured then we will continue to see these types of problems.

How to get the bad stuff in, and some ideas how to prevent it

So last week I had a nasty email delivered to the Inbox of my test E5 EXOL tenant, originating from <sender>.onmicrosoft.com, with a URL pointing to a particularly nasty script - that likely would have done some serious damage if I had clicked on it. This mail was formatted well - and a less technically astute recipient may very well have clicked on it.

So why didnt EOP find it? and at least drop it into SPAM (at a minimum) - this is the core business case for MS Defender.

I subsequently forwarded to email in question to a corporate E5 estate with Mimecast in front of EXOL, again it was let through - no URL re-write / no alert.

IF Ransomware is so easy to get into EXOL there is little wonder that there are over 4000 attacks daily, CISOs need to get to grips with cross domain and zero trust as a matter of urgency.

How to get the bad sh!t in?

- message encryption, this can be a good feature to employ to secure data exchange between trusted partner organisations, and also to encrypt for example sensitive customer data to the end recipient. However IF any organisation permits ANY encrypted messages IN to the core messaging estate - the MTA is never going to inspect the content (link / attachment etc etc), furthermore portal based encryption can dangerous.

With portal based encryption the recipient receives a notification with a standard HTML pointer to fetch the mail (usually with some kind of MFA) - the recipients endpoint has not received anything "bad" - just a link. However when accessing the portal the senders data could affectively be bad or compromised in some way - again a malicious link could be inserted, recipient clicks on that and its game over. Ransomware outbreak.

-how to mitigate this risk:

* on the MTA, quarantine portal based encryption notifications - and release on demand

* employ a browse across solution for accessing links - such as Garrison, all embedded HTML hyperlinks in messages will by default open in an isolated browser session (ie not connected to the corporate network)

* employ AI driven message content inspect tooling - such as Darktrace Antigena

* in the case of receiving encrypted packets from other trusted 3rd parties, ensure a rigorous inspection mechanism is deployed on the sending side prior to encryption - this is a difficult one as the honus is on THEM, but the potential damage is on YOU