CVE-2017-8295 - discovered by Dawid Golunski, Medium/High vulnerability still not fixed in 4.8.1. This issue has been reported to WordPress security team multiple times with the first report sent back in July 2016. It was reported both directly via security contact email, as well as via HackerOne website.

WordPress 4.8.1 still vulnerable to Host Header Attack! CVE-2017-8295 - discovered by Dawid Golunski, Medium/High vulnerability still not fixed in 4.8.1. This issue has been reported to WordPress security team multiple times with the first report sent back in July 2016. It was reported both directly via security contact email, as well as via HackerOne website.

How many damage WordPress already did as a ecosystem? Still, year after Dawid Golunski discovered medium/high vulnerability - WordPress 4.8.1 still vulnerable to Host Header Attack.

Introduction

Wordpress has a password reset feature that contains a vulnerability which might in some cases allow attackers to get hold of the password reset link without previous authentication.

Such attack could lead to an attacker gaining unauthorised access to a victim's WordPress account.

Description

The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner's account.

This can be observed in the following code snippet that creates a From email header before calling a PHP mail() function:

wp-includes/pluggable.php if ( !isset( $from_email ) ) { // Get the site domain and get rid of www. $sitename = strtolower( $_SERVER['SERVER_NAME'] ); if ( substr( $sitename, 0, 4 ) == 'www.' ) { $sitename = substr( $sitename, 4 ); } $from_email = 'wordpress@' . $sitename; }

As we can see, Wordpress is using SERVER_NAME variable to get the hostname of the server in order to create a From/Return-Path header of the outgoing password

reset email. However, major web servers such as Apache by default set the SERVER_NAME variable using the hostname supplied by the client (within the HTTP_HOST header):

https://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname

Because SERVER_NAME can be modified, an attacker could set it to an arbitrary domain of his choice e.g: attackers-mxserver.com which would result in Wordpress setting the $from_email to wordpress@attackers-mxserver.com and thus result in an outgoing email with From/Return-Path set to this malicious address.

As to which e-mail header the attacker would be able to modify - From or Return-Path, it depends on the server environment. As can be read on

http://php.net/manual/en/function.mail.php The From header sets also Return-Path under Windows.

Depending on the configuration of the mail server, it may result in an email that gets sent to the victim WordPress user with such malicious From/Return-Path address set in the email headers.This could possibly allow the attacker to intercept the email containing the password reset link in some cases requiring user interaction as well as without user interaction.

3 separate example scenarios

(both the ones that require victim interaction and those that do not) include:

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 Auto-replied message

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)

Please take a look proof of concept here:

https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html

Read more about Host Header Attack: