Cancel

Sarah Gooding

WordPress Security Issue in Password Reset Emails to Be Fixed in Future Release

Security researcher Dawid Golunski of Legal Hackers has published the details of an unauthorized password reset vulnerability in WordPress core. Golunski demonstrated how, under certain circumstances, an attacker could intercept the password reset email and gain access to a user’s account.

His proof of concept takes advantage of WordPress using the 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.

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.

The results of this particular attack would depend on the server environment, the specific configuration of the mail server, and in some cases would require interaction from the user in question. Golunski’s report has a more specific breakdown of the possible methods that could be employed.

After reporting the issue to the WordPress security team in July 2016 and also via the HackerOne website, Golunski saw no progress on it and decided to release the vulnerability details to the public.

Although there is no official patch yet, WordPress Security Czar Aaron Campbell said the issue is not quite as severe as it may seem.

“It’s a lower priority issue, but we are aware of it and it is in our queue to address,” Campbell said. He explained the unique set of conditions that would be required in order for this to be a serious vulnerability.

“In order for the issue to have a security impact, a server needs to allow a user-supplied header to overwrite $_SERVER['SERVER_NAME'],” Campbell said. “We would consider that a poor server configuration (like leaving display_errors on on a production server), which is unfortunately outside our control.”

Campbell tested his personal Apache and nginx servers and none of them allowed for this. In addition to having a poorly configured server, Campbell said one of the following actions also needs to happen:

  • a user needs to reply to a password reset email
  • an auto-reply needs to reply to the E-Mail and include the original
  • an E-Mail server has to be compromised or overloaded and the message returned to sender with content intact

“If your server is susceptible and you don’t have the ability to fix the actual server configuration, you still don’t have to make changes to WordPress files to mitigate the issue,” Campbell said. “A little PHP like this in a plugin will set the from E-Mail to a static E-Mail address of your choice:”

add_filter( 'wp_mail_from', function( $from_email ) { return 'wordpress@mysite.com'; } );

Campbell said any changes WordPress makes to core will likely be done via a ticket that is currently tracking the issue from a non-security perspective. He said a fix is mostly likely not going to be coming in the next security release, but the team is actively working on it. If they find a good mitigation for the issue, Campbell said they will share it once they have worked through all the potential ramifications.

Category:
Tags:
12

12 responses to “WordPress Security Issue in Password Reset Emails to Be Fixed in Future Release”

  1. Very misleading coverage in this article, it imputes that there was a single contact from the security researcher to WordPress, when in fact:
    Golunski said he reported the issue to WordPress’s security team multiple times, initially more than 10 months ago in July 2016. The researcher told Threatpost that WordPress never outright rejected his claim – he says WordPress told him it was working on the issue – but acknowledged that too much time has passed without a clear resolution, something which prompted him to release details on the bug on Wednesday.
    Another black eye for the so-called “security” team at WordPress Core. Supposedly it is not a security issue according to this account, since it will be fixed as a non-security bug report. What a load of horse manure from WordPress.

    Create forum topic from comment

  3. The security issue (non sanitized value being used) is know for more then 4 years, so what are two or three more months or years … :(

    The hack itself would not have been able to do any damage at all if wordpress would have kept user names confidential. So two old sins coming back together to bite someones ass.

    Create forum topic from comment

    • I tested this and still the problem exists (WP-Mail-SMTP). I think however it’s not so easy to exploit when using it. This is because the only thing you can fake here is the ‘received’ domain in the mail headers. The return-path and other headers are set by the smtp plugin / provider.

      It’s something that should be fixed a long time ago though.

      Create forum topic from comment

  5. To my mind, the WP team’s response in the article is concerning.

    Email addresses which no longer exists, which will result in a bounce-back are missing from the list of situations in which it can be exploited. i.e. All WP users everywhere that are registered with a defunct email address. Or forgotten mailboxes that are full. This set of people, plus those with an auto-response on their mailbox, is hardly a small number in absolute terms, given the number of WP installs out there.

    And as the advisory notes, if the attacker attacks a particular individual, he can “prime the pump” by sending the intended victim enough mails to fill his mail quota, and thus guarantee a bounce-back “over quota” message. i.e. It’s under his control. The WordPress security contact in the article above doesn’t list this in his list of scenarios, even though the advisory does.

    All servers that are dedicated to a single website, or which have a default, and which will respond with that website regardless of the host header, are vulnerable. That is also a significant number, and it would be reasonable to believe that it is disproportionately skewed towards large websites likely to have large numbers of users (because larger websites are more likely to have a dedicated webserver), and hence more likely to have more of the people in the previous paragraph.

    The information that one developer checked whether he could reproduce this on two personal servers is more alarming than reassuring. The choice of “none of them” instead of “neither of them” to describe this reads like over-eagerness to spin, whether or not it was intended (rather than just poor grammar).

    That he calls having a default host (which, as I say, is common when the server is only serving a single host) something which “We would consider that a poor server configuration” reads like an ad-hoc, post-facto response. There’s no technical reason I can think of (and none given in the extract above) as to why that should be considered poor, and nowhere in wordpress.org’s documentation where they document this. Can the WP security team document any webserver vendor saying this? Is it advice given in anyone’s documentation anywhere, for that matter? As I say, it appears ad-hoc.

    Create forum topic from comment

  6. Moreover…

    If an attacker identifies a vulnerable server with large numbers of users, he can just do a username enumeration, and try them all. It then doesn’t really matter whether the percentage of requests that will generate usable bounce-backs is large or small; he only wants one to succeed.

    On PHP versions, the WP developer team’s view is that WP should/cannot bump up the minimum PHP version from 5.2, and/or should not display a notice urging the user to ask their host to upgrade, because users don’t know about or understand these things, and it’s unhelpful to display something potentially confusing. Compare that with the WP security team’s view, on this issue, that if you are vulnerable to the issue, then you’re at fault because your server is badly configured, and, you shouldn’t be expecting the WP security team to prioritise a fix because of that. These two viewpoints are contrary.

    Create forum topic from comment

    • Hey David,

      Thought I’d try to address a few of your concerns.

      And as the advisory notes, if the attacker attacks a particular individual, he can “prime the pump” by sending the intended victim enough mails to fill his mail quota, and thus guarantee a bounce-back “over quota” message. i.e. It’s under his control. The WordPress security contact in the article above doesn’t list this in his list of scenarios, even though the advisory does.

      I did in fact mention that the E-Mail box could be “compromised or overloaded”. The overloading (or over-filling) would be what you’re mentioning here. While it’s possible, most modern E-Mail services make this incredibly hard to do. Massive floods of E-Mails are generally rejected and don’t fill the mailbox. A successful attack here would have to be a very distributed way of sending “valid” E-Mail (or at least that the systems in place think are valid). It also means you have to know the E-Mail address of the user before you attack, and while this probably isn’t difficult in most cases (E-Mail addresses aren’t generally private), it does mean simple enumeration isn’t as viable of a vector.

      All servers that are dedicated to a single website, or which have a default, and which will respond with that website regardless of the host header, are vulnerable. That is also a significant number…

      I would generally disagree with this, although it obviously very much depends on your definition of “significant number”. Talking with a decent number of hosts, it seems highly unlikely that any shared hosts are affected. As for dedicated boxes, they need to be running Apache not nGinx (and more and more large sites are moving to the latter) and not have a virtualhost directive set up for the site, which is definitely best practice for configuring Apache. I’d say that these larger sites on dedicated Apache boxes are also more likely to know how to properly configure things. While this may potentially still be thousands of sites, which may sound like a “significant number”, that is only somewhere in the neighborhood of <0.01% of WordPress site (extremely rough estimate).

      The choice of “none of them” instead of “neither of them” to describe this reads like over-eagerness to spin, whether or not it was intended (rather than just poor grammar).

      It was not an intentional attempt to “spin” things, nor was it poor grammar (although I’m certainly not a grammar expert). While all the servers I checked ran either Apache or nGinx, the number of servers was greater than two (it was actually seven of my own servers that I had checked). I was referring to the servers not the webserver software, which is why I chose “none” over “neither”. Sorry if it caused confusion.

      Also, when asked by Sarah I chose to speak to my own personal tests instead of those of hosts and others that I spoke with simply because it was personal first hand knowledge and it seemed like those hosts would be better positioned to speak to their own setups if asked. That doesn’t mean that those were the only data points that the team used when triaging the issue.

      Can the WP security team document any webserver vendor saying this? Is it advice given in anyone’s documentation anywhere, for that matter?

      I don’t readily have any documentation around this, but I think having our new hosting-community group include this in what they’re building is a great idea.

      if you are vulnerable to the issue, then you’re at fault because your server is badly configured, and, you shouldn’t be expecting the WP security team to prioritise a fix because of that

      As a team we need to prioritize the most severe and far reaching issues to the top of our list. That’s not to the exclusion of other issues like this. In a perfect world we’d have enough people and resources to easily handle all issues, no matter their severity, when they are first reported. Unfortunately this isn’t the case. Instead, I think we’d be doing a disservice to our users if we didn’t take the time to prioritize the way that we do. It’s unfortunate that this issue had to be pushed down the list and it’s unfortunate that it was made public before it was fixed, but I also think it was accurately prioritized by the security team.

      Create forum topic from comment

      • Hi Aaron,
        Thanks for taking the time to reply. I think the most substantive issue (I appreciate your replies on all points) is whether or not it’s really the case that using a virtual host is promoted as best practice (and if so, if that promotion is something anyone’s aware of), or that its absence is poor configuration, even on single-site servers.
        Concerning its prevalance, you say that you talked to shared hosts, but that excludes the single-site-on-a-server case by definition. I think (intuitively – i.e. no hard figures) that it’s disproportionately going to be larger sites, mass-readership sites, and enterprise sites, things in that territory, that are having one site only on the server, and likely to be vulnerable. You say that using VirtualHost directives in Apache is “definitely best practice” even if you are only hosting a single site, which is equivalent to the previous statement that failing to do so is a poor configuration, but I’m very curious as to where this comes from. I’ve been working with Apache for 20 years, and I cannot recall ever seeing this suggested. As phrased, it appears to have been critical to the determination that this issue is of relatively low importance. It’s not a viewpoint reflected anywhere in the Apache documentation, AFAICT.
        Note that WPTavern – owned by Matt Mullenwegg – doesn’t care about the HTTP host header, so apparently isn’t using virtual hosting in the way you’re saying everyone should; the line below will return you the site:
        curl -H ‘Host: anything.at.all’ https://wptavern.com
        So, if allowing requests not coming via a specific virtual host indicates a poor setup – well, even Matt has trouble with this, by the looks of it.
        I am somewhat interested in how the PHP 5.2 thing plays out. On the PHP 5.2 support issue, WP core devs have taken the view that users can’t be held responsible for their hosting setup, and so therefore it’s the duty of WP to work with that and support that antique. You’ve said what seems to be the opposite – “We would consider that a poor server configuration … which is unfortunately outside our control.” – i.e. if users are lumbered with a sub-optimal server setup, then no extra responsibility devolves upon WP devs because of that. It would seem reasonable if in security issues, more onus came onto WP devs, rather than less, though.
        I suppose it’ll be interesting to see what actually now happens in the real world – if attackers go for this. I can prattle about theory all night! ?
        David

        Create forum topic from comment

  7. I just wanted to add that changing the WordPress login page may help, especially for beginners who know nothing about WordPress security. This can be a solution for regular blogs, but for membership websites, that needs extra work. There are some plugins that can help in that case. I hope that WordPress can fix that in the next update of June or later.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.