On 7/30/2024 5:11 PM, Gellner, Oliver via mailop wrote:
Might be interesting for some: The article describes an attack that
abuses weaknesses in Microsofts and Proofpoints email services to send
spoofed emails that pass both SPF and DKIM checks for various domains
like ibm.com or disney.com and others that use both services:
https://labs.guard.io/echospoofing-a-massive-phishing-campaign-exploiting-proofpoints-email-protection-to-dispatch-3dd6b5417db6
Sending spoofed emails that pass SPF alone for domains that use hosted
email services like Office365 is not new and has already been
documented in the past (eg in https://arxiv.org/pdf/2302.07287.pdf).
That’s why some providers like Gmail started to consider only DKIM for
the BIMI verdict / authentication checkmarks and do not rely on SPF
any longer
(https://www.theregister.com/2023/06/09/google_bimi_email_authentication/).
However in this case the attackers managed to take it one step further
and combine two hosted email services to get valid DKIM signatures for
their messages too.
Beside fixing the configuration within the Proofpoint tenant for the
affected domains, I advise to also prefix
„include:spf.protection.outlook.com“ in the SPF record with a question
mark and rely only on DKIM for authentication, as in the end you
cannot control what is being allowed by this broad SPF include.
Unsolicited opinion from $dayjob that is a PP customer; I commented
about this on LinkedIn already, but just sharing it here in more
detailed reply (not limited to 1250 characters) to this since it's
directly relevant.
Disclaimer: I don't work for Proofpoint. These views below are my own,
and they have not been reviewed or approved by my employer.
The part that makes this issue complicated is that every Proofpoint
enterprise customer's mail clusters are separate and distinct, whether
they're on-prem (PPS) or using Proofpoint Hosted on-demand (POD).
For the context of this topic and the exploited configuration in
question, there is no shared environment (outside of VM hosts) or shared
allow relay configuration between customer mail clusters in this aspect
- any configuration done by one mail cluster administrator, has nothing
to do with any other customer's. (i.e. Local policy, rules, and
filtering specific to that cluster and customer)
Generally (and as Oliver noted), this isn't a "new" attack vector; it's
been a known common misconfiguration and heavily suggested step in
Proofpoint's M365 integration guide best practices to mitigate for a
very long time.
As it turns out, potentially a *lot* of Proofpoint's hosted enterprise
customers (.pphosted.com) weren't following these best practices. So,
(from my PoV as a customer cluster mail admin which did mitigate for
this many years ago) I'm not really sure where the blame lies.
Is it the customer mail administrator's fault for not restricting the
MTA's relay configuration correctly? (from either ignorance of the
configuration vulnerability, failure to remediate in a timely fashion,
incompetence, red tape, etc.)
Or is Proofpoint at fault because they hosted the MTAs, but didn't
mitigate this for their hosted customers with this vulnerable
configuration for as many years (which is almost double digits) as it's
been a known configuration issue with M365 integration for allowed relay
IPs?
Arguably, I think there could have been a lot more done in hindsight by
Proofpoint to address this more actively - but this has largely been the
mail cluster administrator's responsibility to mitigate in the past,
which apparently led to and heavily contributed to this incident.
Hopefully that will change soon with improvements to the relay
restriction feature.
Okay, I'll get off my soapbox now.
- Mark Alley
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
