WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset | Hacker News Reader

WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset

exploitbox.io

140 pointsrishabhd70 comments

From php.net, about using $_SERVER['SERVER_NAME'] :

    Note: Under Apache 2, you must set UseCanonicalName = On and ServerName. Otherwise, this value reflects the hostname supplied by the client, which can be spoofed. It is not safe to rely on this value in security-dependent contexts.

Why does an "ethical Hacking"¹ site post an 0day instead of responsible disclosure? Am I missing something here?

¹https://legalhackers.com/

Isn't the unethical variant selling that 0day at the black market?

there are 50 shades of grey...

"This issue was first reported to WordPress security team multiple times, with the first report sent in July 2016.

As there has been no progress in this case , this advisory is finally released to the public without an official patch."

thanks, that's what I was missing :) strange to hide that statement under "solution"

The unethical variant would be using it.

Ethics of disclosure is a long and nuanced debate

At some point it becomes unethical not to publish it too, given that the entire time it's exploitable risks someone else running into it and using it.

Here is a patch I just did:

DISCLAMER: Works only if you set WP_HOME explicitely. if you define it dynamically based on $SERVER['HTTP_HOST'] this won't fix it. (using a switch with $SERVER['HTTP_HOST'] is fine, except if you set a default)

  ------[ wp-includes/pluggable.php before ]------

  ...

  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;
  }

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

edit: please test this on your setup before deploying it. edit2: fixed with the help of apstls.

Shouldn't it also be removing "http(s)://" regardless of whether or not the domain is prefixed with "www."?

You are right, I fixed it. Thank you !

This doesn't really seem right, does it handle wp_home being web.example.org ? Or any other subdomain other than www.

Perhaps http://stackoverflow.com/a/37987242/383694 would help.

One could [also] verify the domain resolves to the same IP as the server, it seems

Handles it the same way it did before. I'm just fixing the exploit, I don't have the patience to fix all of WordPress ;)

Isn't there a good (possible) URL parser out there so substr can be avoided? Manual string editing of data in a known format seems dirty and a source of possible bugs to me.

https://secure.php.net/manual/en/function.parse-url.php

You could do this a lot easier:

  if ( !isset( $from_email ) ) {
    $sitename = parse_url( strtolower( WP_HOME ) )['host'];

    if ( substr( $sitename, 0, 4 ) == 'www.' ) {
      $sitename = substr( $sitename, 4 );
    }

    $from_email = 'wordpress@' . $sitename;
  }

Edit: you still need to strip out www. if it exits. Also not compatible with < PHP 5.4

They might have avoided this code for compatibility.

Vulnerability exists only if no from_email is specified. This isn't an issue when using a mailing plugin which specifies from_email like wp stmp mail with correct settings. It can also be fixed by adding a filter for wp_mail_from to specify from_email by hand.

Well the vulnerability is listed as one in WordPress Core so I don't know that it's relevant that a plugin fixes it. The vulnerability still exists in WP Core, and most people are not going to have an SMTP plugin if email works out of the box.

I should've added more background to my earlier comment. Our wordpress sites are hosted on ec2 and by default mails sent from there end up in spam so we use SES. For that we need a plugin like wp smtp. I figured I'd give an ease of mind for similar use cases. I agree that a plugin is not the right solution especially if the provided functionality is not needed(smtp).

"Wordpress is a remote shell with great blogging features"

I'm quite sure agencies like NSA want to keep Wordpress around for this. There will always be unpatched installations around and some they found that will not get disclosed.

Kind of makes me glad the Wordpress has finally become mature enough to have to be exploited in such a convoluted way. Hope they fix the issue soon and show maturity

My experience of WordPress is that the core is now very secure. These days, it's easier to find exploits in the plugins and templates.

Agreed. I tell people often that properly applying updates and using plugins and themes from trusted developers in conjunction with a service like Sucuri or WP Extra Care makes your site as close to impenetrable as is realistically possible.

Or on shared hosts via a genuine account on the same server?

Very true! if you every look at http error logs on a WP site it's full of bots trying plugin paths.

> the core is now very secure

I wouldn't call inventing their own user-land parameterised queries "secure": https://github.com/WordPress/wordpress-develop/blob/master/s...

Despite it sounding like a terrible idea, I haven't heard of any exploits.

Until you do. That's why we still see security fixes to this day.

Funny you praise it instead of trying to dismiss Wordpress as any reliable software.

global $current_user;

This is Wordpress, making it nearly impossible to clearly grasp what's going on leading to unknown amount of vulnerability at any given moment.

It's probably the dumbest code used by the mass.

You should never directly work with the WordPress global variables, and it's bad practice to do so.

Use wp_get_current_user: https://codex.wordpress.org/Function_Reference/wp_get_curren...

The largest attack surface for WP is poorly developed plugins and themes, not WordPress core.

> You should never directly work with the WordPress global variables, and it's bad practice to do so.

It's bad practice to use global variables, but you somehow blame the person who highlights this use, as opposed to the project that is littered with their use.

the reason why so many plugins and templates are insecure is precisely because they have access to that global scope and misuse it

You're missing the point.

You're criticising 'plugins and templates' that make use of the global scope, while giving the WordPress core a free-ride for not just using global scope, but placing objects there that can be exploited.

That's exactly my point - the core is at fault for handing over global exec to the plugins and templates. It's a horrible design, and it appears there is little motivation to fix it but rather pass blame onto plugins.

Wordpress shouldn't be using any globals at all. That code doesn't just smell, it reeks.

1) Note, you can patch this in a theme or plugin of your own by explicitly setting a sender email address:

    add_filter("wp_mail_from", function($generated_from) { return "mysender@mydomain.com"; });

2) The thing I'm not understanding - wouldn't setting a "Host:" header change the directory being served in most virtual host configurations? For instance:

    POST /wp/wordpress/wp-login.php?action=lostpassword HTTP/1.1
    Host: injected-attackers-mxserver.com

In most configurations the web server would look for a virtual host configuration matching "injected-attackers-mxserver.com" - and when not found would just return a 404 or error page, or possibly the default Apache/nginx directory? So to be vulnerable the WordPress install would need to be accessible via either A) a default config or B) an IP address.

3) It's odd there isn't a patch for this. WordPress already creates and stores a canonical "siteurl" on install, and this setting is not changed by any "$_SERVER" variable.

I'm missing something - how can this be exploited? AFAICT it's only if a user replies to the email (and thereby includes the reset token)?

One given example is that – in the case of the Return-Path header being maliciously set – the attacker could perform a DoS attack on the victim's mailbox so that the password reset email would be sent as part of a non-delivery receipt.

Also, if the victim has an auto-responder enabled, the attacker will receive an out of office reply, with the password reset link quoted in the email.

I've never seen an autoreply that's included the original message

It was always rare, but it used to be more common than it is now.

Another way to trigger a bounce would be to have the evil domain purposefully having strict SPF and DMARC policy set.

this depends on recipient's (WP admin) server properly validating SPF and DMARC

It has to be combined with another attack. If the victim's mail server bounces the email it will be sent back to the attacker's mail server. One possible approach to do that is to fill the target email so they reach their quota.

https://httpd.apache.org/docs/current/mod/core.html#usecanon... does say this: "If CGIs make assumptions about the values of SERVER_NAME, they may be broken by this option. The client is essentially free to give whatever value they want as a hostname. But if the CGI is only using SERVER_NAME to construct self-referential URLs, then it should be just fine."

I think the third scenario outlined is actually very realistic. A lot of people will default to seeking information or assistance by replying directly to the email that they're uncertain about.

likely not working on vhost configurations if the site is not the default one.

2017 and still things like this. WP is a cancer.

I did a quick write up on the two issues here while I was going through them to further understand the risk http://blog.dewhurstsecurity.com/2017/05/04/exploitbox-wordp...

For a none PHP guy, does that mean I can put the following in my PHP.ini file (I guess at the top is as good as anywhere) and be safe?

UseCanonicalName = On ServerName = www.mydomain.com

Jesus shit on a stick.

That's two Apache directives, nothing to do with PHP directly. You likely already have the ServerName entry, as 99.9% of apache installs would be using Vhosts these days.

The `UseCanonicalName = On` should be added to your vhost config file, or your global apache config file (e.g. /etc/apache2/apache2.conf on Debian)

So, I' probably one of two people in the world that run PHP on IIS. Does that mean my website is not vulnerable?

Not necessarily. It depends how IIS is configured, I believe it will exhibit the same behaviour (SERVER_NAME is taken from the Host request header) in at least some circumstances, if not all.

At least we can set "UseCanonicalName" to "On" on the virtual host in the meantime.

Will this exploit work if a server is using transactional email service like SendGrid or Mandrill?

Most likely not, as you'd be replacing the affected function (wp_mail) with the plugin.

Is it normal to just publish such exploits now?

Edit: Missed the "reported in 2016" bit :/

This exploit was reported in 2016 with no progress made.

Naively this seems like a PHP bug, using the UA submitted host? Is that necessary?

not PHP bug, but Apache bug: "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):"

Not an Apache bug but Wordpress trusting client-supplied data where it shouldn't. SERVER_NAME coming from the HTTP Host header is intentional and documented behavior, ergo not a bug.

How is this behavior ever useful server side?

I dunno. My best guess would be that it's there for legacy reasons.

Not even an Apache bug, it's a config parameter where one case is dangerous but still maybe useful (but I can't think of example). The recommendation, if followed, mitigates

SERVER_NAME isn't part of PHP so much as part of CGI. That's where PHP's $_SERVER keys come from. And the values are set by the web server.

This looks a lot like a 0day exploit posted to get traffic and exposure for their startup.

No, this was because WP security team ignored this issue. From the article:

> 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.

> As there has been no progress in this case , this advisory is finally released to the public without an official patch (0day).

> ignored this issue

I'm not sure the author would necessarily know that this is true. The author also didn't say whether they informed WP Core that they were going to publish it.

Per the "revision history" the notes about a report sent in 2016 was added after initial publication ("Updated 'solution' section to clarify and highlight numerous resolution attempts"). So it isn't clear to me that communicating the exploit to the team was the top priority.

Regardless of the circumstances though, publishing it seems quite clearly tied to the promotion of their business. That's not necessarily bad assuming they were responsible in how they communicated the issue. I am admittedly reading tea leaves and just questioning whether this is the full story.

Reply on news.ycombinator.com