Title: Some notes about the exploitation of CVE-2017-8295
Date: 2019-11-09 13:00

Almost 3 years ago, [Dawid Golunski](https://twitter.com/dawid_golunski) released a
[detailed advisory](https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html)
for [CVE-2017-8295](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8295): a [Host
header injection](https://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html)
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](https://github.com/WordPress/WordPress/blob/5.2-branch/wp-admin/includes/class-wp-upgrader.php#L736)
♫ ), or
if the target email is hosted on gmail, good luck reaching the
[15GB quota](https://support.google.com/drive/answer/2375123) 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](https://en.wikipedia.org/wiki/Bounce_message) back to us; and that
this can be achieved in several ways. 

Some email blacklists (like [spamcop]( https://www.spamcop.net/fom-serve/cache/166.html ))
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](http://www.openspf.org/)
and [DMARC](https://en.wikipedia.org/wiki/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](http://florent.daigniere.com/) and an *anonymous friend* for
the discussions around this vulnerability that sparkled this blogpost.