Vulnerabilities in SPF

I mentioned in a previous post that DKIM and SPF have known vulnerabilities. SPF has two that are currently being exploited.

The first one exploits over-broad include mechanisms and what constitutes SPF being considered to pass. For example if the SPF record for domain.victim looked like this:

v=spf1 +include:_spf.google.com +include:hosting.provider ~all

If you can control an IP within the range covered by hosting.provider then you can do something like this:

SMTP HELO/EHLO address: kflynn@domain.hacker

Envelope address: nobody@nonexistant.domain.victim

5322.From address: “Your Invoice” <nonexistant.domain.victim>

While there is a non-existent envelope domain there is a valid HELO/EHLO one. The sending IP is listed in the SPF record of domain.hacker. The vulnerability being exploited here is that SPF protocol will “fall-back” to checking the domain in the HELO/EHLO if there is a problem checking the envelope domain. That means that there is a non-zero chance of this message registering as a PASS for SPF depending on how SPF is evaluated by the receiver. This vulnerability was researched at scale for the BreakSPF paper¹.

There is a second related vulnerability that is more to do with poorly configured infrastructure and loose authentication checks than a weakness in the protocol itself. It is commonly referred to as an SPF Upgrade Attack and is being activity exploited.

The risk of over-broad SPF include mechanisms was understood by the authors of the original RFC but back then most organizations hosted their email on-site and the include mechanism was intended to capture edge cases, not be the norm. The latest revision to the DMARC specification includes a policy for handling non-existent domains along with a clarification that DMARC only considers SPF to pass if it is on the envelope domain.