8 ms·
WordPress Core up to 4.7.4 – Potential Unauthorized Password Reset
- scandox 9y agoI 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.
- deleted 9y ago[deleted]
- anotheryou 9y agoWhy does an "ethical Hacking"¹ site post an 0day instead of responsible disclosure? Am I missing something here? ¹https://legalhackers.com/ https://legalhackers.com/
- bildung 9y agoIsn't the unethical variant selling that 0day at the black market?
- anotheryou 9y agothere are 50 shades of grey...
- enzanki_ars 9y ago"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 9y agothanks, that's what I was missing :) strange to hide that statement under "solution"
- deleted 9y ago[deleted]
- BrainInAJar 9y agoThe unethical variant would be using it. Ethics of disclosure is a long and nuanced debate
- problems 9y agoAt 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.
- Sujan 9y agoIs it normal to just publish such exploits now? Edit: Missed the "reported in 2016" bit :/
- HappyTypist 9y agoThis exploit was reported in 2016 with no progress made.
- deleted 9y ago[deleted]
- kimee 9y agoVulnerability 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 9y agoWell 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 9y agoI 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).
- jonathonf 9y agoI'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 9y agoOne 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 9y agoAlso, 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 9y agoI've never seen an autoreply that's included the original message
- matt_morgan 9y agoIt was always rare, but it used to be more common than it is now.
- atomt 9y agoAnother way to trigger a bounce would be to have the evil domain purposefully having strict SPF and DMARC policy set.
- gondo 9y agothis depends on recipient's (WP admin) server properly validating SPF and DMARC
- zimbatm 9y ago
- burnbabyburn 9y agolikely not working on vhost configurations if the site is not the default one.
- SenpaiSilver 9y agoAt least we can set "UseCanonicalName" to "On" on the virtual host in the meantime.
- tonmoy 9y agoKind 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 9y agoMy experience of WordPress is that the core is now very secure. These days, it's easier to find exploits in the plugins and templates.
- goatherders 9y agoAgreed. 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.
- pbhjpbhj 9y agoOr on shared hosts via a genuine account on the same server?
- dangerboysteve 9y agoVery true! if you every look at http error logs on a WP site it's full of bots trying plugin paths.
- stephenr 9y ago> 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/src/wp-includes/wp-db.php#L1291 https://github.com/WordPress/wordpress-develop/blob/master/s...
- blowski 9y agoDespite it sounding like a terrible idea, I haven't heard of any exploits.
- toadkicker 9y ago"Wordpress is a remote shell with great blogging features"
- h1d 9y agoI'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.
- calibas 9y agoFrom 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.
- ethicalhack3r 9y agoI 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-wordpress-security-advisories.html http://blog.dewhurstsecurity.com/2017/05/04/exploitbox-wordp...
- DougN7 9y agoFor 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 9y agoJesus 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 9y agoSo, I' probably one of two people in the world that run PHP on IIS. Does that mean my website is not vulnerable?
- stephenr 9y agoNot 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.
- simlevesque 9y agoHere 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 9y agoShouldn't it also be removing "http(s)://" regardless of whether or not the domain is prefixed with "www."?
- deleted 9y ago[deleted]
- simlevesque 9y agoYou are right, I fixed it. Thank you !
- pbhjpbhj 9y agoThis 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
- gibrown 9y agoThis looks a lot like a 0day exploit posted to get traffic and exposure for their startup.
- slacka 9y agoNo, 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 9y ago> 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.
- pbhjpbhj 9y agoNaively this seems like a PHP bug, using the UA submitted host? Is that necessary?
- gondo 9y agonot 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 9y agoNot 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.
- edoceo 9y agoNot 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
- TazeTSchnitzel 9y agoSERVER_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.
- hvtuananh 9y agoWill this exploit work if a server is using transactional email service like SendGrid or Mandrill?
- gant 9y agoMost likely not, as you'd be replacing the affected function (wp_mail) with the plugin.
- lbstr_ftw 9y agoI 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.
- newsat13 9y agohttps://httpd.apache.org/docs/current/mod/core.html#usecanonicalname 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."
- leepowers 9y ago1) 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.
- mike503 9y ago2017 and still things like this. WP is a cancer.