Polish security expert Dawid Golunski has discovered a zero-day in the WordPress password reset mechanism that would allow an attacker to obtain the password reset link, under certain circumstances.
The researcher published his findings yesterday, after reporting the flaw to the WordPress security team last July.
After more than ten months and no progress, Golunski decided to go public and inform WordPress site owners of this issue so they could protect their sites by other means.
Zero-day can alter “From” and “Return Path” parameters
The issue, tracked via the CVE-2017-8295 identifier, affects all WordPress versions and is related to how WordPress sites put together the password reset emails.
According to Golunski, an attacker can craft a malicious HTTP request that triggers a tainted password reset operation by injecting a custom SERVER_NAME variable, such as “attacker-domain.com”.
This means that when the WordPress site puts together the password reset email, the “From” and “Return-Path” values will be in the form of “email@example.com”.
Most users would think this zero-day is useless, as the attacker wouldn’t achieve anything more than sending a password reset email to the legitimate site owner, but from the wrong Sender address.
Zero-day can be weaponized in various ways
In reality, this can be quite dangerous. Golunski details some scenarios in which an attacker could exploit this zero-day.
For example, the attacker could flood the site owner’s email inbox with junk emails. When the corrupted password reset email arrives, because the legitimate user’s inbox would be full, the email server would return the email back to its sender, which in this case would be the tainted “Return-Path” value, meaning the attacker’s email.
Another attack scenario, easier to carry out, would be to watch when a site owner leaves on holiday. If the site admin has enabled an “out-of-office” auto-responder, if the auto-responder includes the original email, then the attacker obtains the password reset email with minimal effort.
Other attack scenarios described by Golunski require social engineering, so there’s a low chance those will succeed with experienced website owners.
These complex exploitation scenarios are most likely the main reason why the WordPress team has not prioritized patching this issue until now.
Some mitigations available
Webmasters managing high-value sites looking for a way to prevent exploitation of this zero-day have some options at their dispossable.
“As a temporary solution users can enable UseCanonicalName to enforce [a] static SERVER_NAME value,” Golunski proposes.
On Reddit, other users also recommended that site owners “create a dummy vhost that catches all requests with unrecognized Host headers.”
Depending on your technical prowess, you can also experiment with other mitigations discussed in this Reddit thread, at least until the WordPress team patches this issue.
Also yesterday, Golunski released details about another method to exploit WordPress sites via a remote-code execution flaw in the PHPMailer library, a library included with the WordPress core source code. This issue came to light earlier in the year, but Golunski only now revealed more details about the exploitation mechanism against WordPress sites.