Almost 3 years ago, Dawid Golunski released a detailed advisory for CVE-2017-8295: a Host header injection in the From field of the password reset email in WordPress below 4.7.4.

This was a nice vulnerability, successfully used for ages, and now that:

1. the cat is out of the bag;
2. the mourn over public disclosure is long gone;
3. everyone and their dog had time to think about it;

it's time to burn one of my favourite interview question: "How would you exploit CVE-2017-8295?".

The advisory suggests three different venues:

1. Attacker can perform a prior DoS attack on the victim's email account/server (e.g by sending multiple large files to exceed user's disk quota, attacking the DNS server etc) in order to prevent the password reset email from reaching the victim's account and bounce back to the malicous sender address that is pointed at the attacker (no user interaction required)
2. Some autoresponders might attach a copy of the email sent in the body of the auto-replied message (no user interaction required)
3. Sending multiple password reset emails to force the user to reply to the message to enquiry explanation for endless password reset emails. The reply containing the password link would then be sent to attacker. (user interaction required)

But those vectors are noisy, unreliable, or even unrealistic: if you can attack the DNS, you don't need this vulnerability (♫ WordPress updates can be MITM'ed ♫ ), or if the target email is hosted on gmail, good luck reaching the 15GB quota without being noticed.

So what are the better solutions?

One might think about using the From: field to inject more headers, like a Bcc: one, but it's not possible (can you guess why?).

The crux here is to understand that what we want to do is to force the email to bounce back to us; and that this can be achieved in several ways.

Some email blacklists (like spamcop) are accepting user-provided evidences, so it's just a matter for forging some spam originating from the WordPress instance that you want to compromise to get it on a spamlist; making password recovering emails bounce back to you. You could also register a dodgy domain, like freeviagra4u.biz or paypall.com and use it to trigger anti-spam systems.

But this is also a bit noisy and/or unreliable, we can do better: What about… SPF and DMARC?

The way this works is that when you're receiving an email, it'll ask the domain in the Form: if the host that sent the email is authorized to do so; if not, the email is bounced back to the address specified by the aforementioned domain.

The exploitation process simply boils down to serving a strict SPF+DMARC policy to make every single usage of your domain as an email sender bounce, to harvest recovery links.

Thanks to nextgens and an anonymous friend for the discussions around this vulnerability that sparkled this blogpost.