This week’s report.
This week’s report isn’t too bad, though there is one critical vulnerability in the plugin WooCommerce Catalog Enquiry that you’ll want to address immediately. You’ll also notice my plugin (wpDirAuth) is included. Read below to find out what was fixed.
In case you didn’t notice, the 4.7.4 update was released yesterday. The update addresses 47 bug fixes and improvements to the REST API. If interested, you can look through all the changes. If you have updates enabled, your system has probably already updated. If you don’t have them enabled for some reason, make sure to visit the Dashboard –> Updates in your site and run the update.
Cross-Site Request Forgery in WordPress Core
A Cross-Site Request Forgery vulnerability in WordPress Core was disclosed today. Specifically, it affects the request_filesystem_credentials() function in /wp-admin/includes/file.php. This affects versions 4.5.3 up to and including 4.7.4.
The FTP/SSH form functionality of WordPress was found to be vulnerable to Cross-Site Request Forgery. This vulnerability can be used to overwrite the FTP or SSH connection settings of the affected WordPress site. An attacker can use this issue to trick an Administrator into logging into the attacker’s FTP or SSH server, disclosing his/her login credentials to the attacker. In order to exploit this vulnerability, the attacker has to lure/force a logged on WordPress Administrator into opening a malicious website.
In addition, the WordPress installation must not be able to write to the wp-content folder so that it falls back to trying to use the internal FTP/SSH functionality. Apparently, this was discovered back last summer during The Summer of Pwnage event and still hasn’t been corrected.
While there is no fix yet, standard best practices should help mitigate the risk:
- Don’t log into your site with an account that has administrative privileges unless you’re doing something that requires administrative privileges
- If you do need to some administrator tasks, don’t browse to other sites in the same browser as you’re using to perform those administrative tasks
- Once you’re finished with the administrative tasks, log out of that account
Hopefully now that the vulnerability has been disclosed, the WordPress core team will get a fix out for it.
As you have noticed, my wpDirAuth plugin was listed in this week’s report. I was in the process of making some changes to it and decided to go back to some of the code that is still around from when I inherited it to see if there were other quick changes I could implement to improve it. In the function, `wpDirAuth_loginFormExtra()` it was using `$_SERVER[‘HTTP_HOST’]` to rebuild a redirection. Specifically, the code was checking to see if Require SSL login had been enabled in the plugin, but the request for wp-login.php was not over https. If so, then it rebuilt the request and attempted to redirect the user to the https version in a multitude of ways. Unfortunately, HTTP_HOST is set via the Host header sent from the client, making it unsafe to use. So if a site using wpDirAuth had Require SSL enabled in the plugin, but did not have FORCE_SSL_ADMIN defined in wp-config.php nor was enforcing ssl via the web server, and If an attacker was able to trick a victim into clicking on a link from a site they controlled, they could have injected the Host header and sent the victim to the non-http version of wp-login on a site using wpDirAuth. From there they could have redirected the user to yet another site, or launched a Cross-Site Scripting attack. Version 1.8.0 requests the domain from WordPress directly, removing the reliance on HTTP_HOST.
Introducing Super Simple Account Enumeration Blocker
After speaking at WordCamp St. Louis, I had several people ask me if I could package the code I demonstrate in the account enumeration part of my talk into a single plugin they could install. I finally had a few minutes to do so (honestly, the longest part is remembering how to use Subversion when I use Git in my day-to-day duties and personal projects). The result is Super Simple Account Enumeration Blocker. As its name implies, there isn’t much to it. It blocks the most common methods of account enumeration, including the User slug from the users endpoint in the REST API, and the overly informative error message upon a failed login attempt. I probably won’t add much to it beyond edits/additions to match what happens in core. Hopefully some of you will find it useful.