WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset(exploitbox.io)
exploitbox.io
WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset
https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html
75 comments
From php.net, about using $_SERVER['SERVER_NAME'] :
Why does an "ethical Hacking"¹ site post an 0day instead of responsible disclosure? Am I missing something here?
¹https://legalhackers.com/
¹https://legalhackers.com/
"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."
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"
[deleted]
The unethical variant would be using it.
Ethics of disclosure is a long and nuanced debate
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.
Isn't the unethical variant selling that 0day at the black market?
there are 50 shades of grey...
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)
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;
}
...
-----------------------------------------
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.
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;
}
They might have avoided this code for compatibility.
Shouldn't it also be removing "http(s)://" regardless of whether or not the domain is prefixed with "www."?
[deleted]
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
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 ;)
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.
> 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...
I wouldn't call inventing their own user-land parameterised queries "secure": https://github.com/WordPress/wordpress-develop/blob/master/s...
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.
Very true! if you every look at http error logs on a WP site it's full of bots trying plugin paths.
Or on shared hosts via a genuine account on the same server?
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.
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.
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.
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.
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:
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.
add_filter("wp_mail_from", function($generated_from) { return "[email protected]"; });
POST /wp/wordpress/wp-login.php?action=lostpassword HTTP/1.1
Host: injected-attackers-mxserver.com
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.
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
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)
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.
[deleted]
Is it normal to just publish such exploits now?
Edit: Missed the "reported in 2016" bit :/
Edit: Missed the "reported in 2016" bit :/
Naively this seems like a PHP bug, using the UA submitted host? Is that necessary?
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.
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.
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
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).
> 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.
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.