On Tue, Jul 30, 2024 at 4:53 PM Mark Alley via mailop <[email protected]> wrote:
> 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. > $dayjob is Proofpoint -- I have been heavily involved with this. We have gone to great lengths to raise awareness with customers and get them to correctly configure their systems. Ultimately up to them though, despite our warnings of potential consequences for not doing this. Our response to Guardio's article: https://www.proofpoint.com/us/blog/threat-insight/scammer-abuses-microsoft-365-tenants-relaying-through-proofpoint-servers-deliver --Jaren
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
