
WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset - rishabhd
https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html
======
calibas
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.

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

¹[https://legalhackers.com/](https://legalhackers.com/)

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

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

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

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

~~~
simlevesque
You are right, I fixed it. Thank you !

~~~
pbhjpbhj
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](http://stackoverflow.com/a/37987242/383694)
would help.

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

~~~
simlevesque
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 ;)

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

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

~~~
kimee
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).

------
toadkicker
"Wordpress is a remote shell with great blogging features"

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

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

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

~~~
stephenr
> 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...](https://github.com/WordPress/wordpress-
develop/blob/master/src/wp-includes/wp-db.php#L1291)

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

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

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

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

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

~~~
1_player
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.

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

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

------
newsat13
[https://httpd.apache.org/docs/current/mod/core.html#usecanon...](https://httpd.apache.org/docs/current/mod/core.html#usecanonicalname)
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."

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

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

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

------
ethicalhack3r
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...](http://blog.dewhurstsecurity.com/2017/05/04/exploitbox-wordpress-
security-advisories.html)

~~~
DougN7
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

~~~
stephenr
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)

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

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

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

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

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

------
Sujan
Is it normal to just publish such exploits now?

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

~~~
HappyTypist
This exploit was reported in 2016 with no progress made.

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

~~~
gondo
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):"

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

~~~
m_mueller
How is this behavior ever useful server side?

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

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

~~~
slacka
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).

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

