WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset (exploitbox.io)

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

¹https://legalhackers.com/

Is it normal to just publish such exploits now?

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

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.

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)?

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

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

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.

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

"Wordpress is a remote shell with great blogging features"

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.

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

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.

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

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

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

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

I tried to replicate this and couldn't. It seems this isn't so much a Wordpress issue as it is a poorly-setup-webserver issue.

If your nginx/apache setup is set to have "Host: * => wordpress", you're doing it wrong and this issue affects you.

But if you setup your server as you were supposed to, i.e. matching on the Host (server_name in nginx) to route to your blog, then obviously SERVER_NAME cannot be overwritten, and any attempts to exploit this will result in 404.

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

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.

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