Yesterday, May 3rd 2017, a site named ExploitBox released two WordPress advisories discovered by Dawid Golunski. The titles of the two advisories are:

WordPress Core <= 4.7.4 Potential Unauthorized Password Reset (0day)

The first advisory documents a potential unauthorized password reset vulnerability in the latest version of WordPress (4.7.4 at the time of writing) and below.

The issue documented is due to WordPress using the SERVER_NAME PHP variable, which uses the HTTP Host request header by default, to construct the from (or Return-Path) email address when requesting a password reset email. This vulnerability is commonly known as ‘host header injection’. To exploit this vulnerability, in this particular case, an unauthenticated attacker could request a password reset for a particular user (‘admin’ being the obvious choice) while changing the Host HTTP request header value to a domain the attacker controls. Under the right circumstances, a password reset email would then be sent to the victim user with the from email header set to the attacker’s domain.

To successfully exploit this issue, the WordPress user receiving the malicious password reset email would need to somehow reply to the email. The advisory author suggests some scenarios where the password reset email may be replied to:

If attacker knows the email address of the victim user. They can perform a prior DoS attack on the victim’s email account (e.g by sending multiple large files to exceed user’s disk quota, or attacking the DNS server) in order to cause the password reset email to be rejected by the receiving server, or not reach the destination and thus get returned to the account on attacker’s server

Some autoresponders might attach a copy of the email sent in the body of the auto-replied message

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.

Risk

Virtual hosting allows one web server to host multiple domains. For example, somesite.com , anothersite.es and yetanothersite.fr can all be hosted on the same server with the same IP address. To tell the server which domain you want to access you have to supply the domain in the Host HTTP request header. To exploit this issue the attacker must be able to control the Host HTTP request header, but then how does the server know which domain to serve you?

From what we can see, this vulnerability can only be exploited against the default virtual host. The virtual host (domain) the web server will default to. You are vulnerable if your domain running WordPress is the only domain on the server, or, if your domain is the default one. That coupled with the exploitation requirement for the victim to somehow respond to the email, we believe it is pretty unlikely that this will be a major issue affecting WordPress users. Nevertheless, under the correct circumstances, there is a risk here.

Remediation

This vulnerability can be prevented by setting the following directive in the main Apache configuration file UseCanonicalName = On . This will force PHP to use the configured ServerName directive value instead of relying on the HTTP Host request header which can be manipulated by an attacker.

WordPress could patch this issue by not using the SERVER_NAME variable to construct the from email header. This could be achieved by using the siteurl or home WordPress database values which are set at the time of installation.

WordPress Core 4.6 - Unauthenticated Remote Code Execution (RCE) PoC Exploit (default configuration, no plugins, no auth)

The second advisory documents an unauthorized Remote Code Execution (RCE) PoC exploit in WordPress version 4.6 (released August 16th 2016).

This vulnerability is also due to WordPress using the SERVER_NAME PHP variable to set the from email header (which can be set with the Host HTTP request header).

The author of the advisory uses the host header injection vulnerability in WordPress to exploit a vulnerability the author previously discovered in PHPMailer (used by WordPress to send email). Wordfence did a great write up on the PHPMailer vulnerability when the details were first publicly released back in December 2016.

Risk

The risk of this vulnerability compared to the previous one is much higher, as with this one an unauthenticated attacker could achieve Remote Code Execution (RCE), and it does not require any user interaction (user replying to the email, autoresponders or DoS). However, the PHPMailer vulnerability was patched in WordPress version 4.7.1. If you are using the latest version of WordPress, or any of the patched versions, then you are not affected by this issue. Please note that to exploit this vulnerability the Host HTTP request header must also be able to be manipulated, which may be difficult if the target WordPress blog is not the default (or first) virtual host (as discussed previously).

Remediation

The easiest way to mitigate this vulnerability is to update WordPress to the latest version (or any patched version), which you should be doing anyway. If you want to further harden your WordPress installation the remediation information given for the previous vulnerability should also be applied.