Vulnerable Plugins
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.
WordPress Updated
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.
wpDirAuth Updated
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-list.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.

I will mention briefly that I sat in a couple of sessions over the course of the weekend where presenters gave bad advice, security-wise. I didn’t say anything at the time because I didn’t want to be “that guy” who interrupts and contradicts a speaker. I don’t particularly like it when I’m presenting and not every speaker is confident enough to handle an interruption. Just remember that nothing from the client is safe, nothing from the client-side can be relied upon. If you didn’t generate it in your code, the data is tainted and you need to treat it as untrusted. If you have to use the data, verify the data is what you expect it to be and escape it before you send it back to the user. PLEASE.
As I mentioned in 
From there I jumped back over to the Learning Javascript Deeply track which was what I had been looking forward to diving into. First session I attended was
Interestingly, the next speaker never arrived. I have no idea what happened. I was bummed too because I really was interested in learning more about the 







Friday night was the speaker dinner. I had a wonderful time hanging out with 


Next up was Mike Herchel’s presentation on WordCamp & Drupal: Community and Contribution Differences and Lessons. As I had suspected, there are many more similarities between the two camps than I think most people are willing to admit. Ended up eating lunch with Mike and Kyle where discussed some of the challenges organization face in trying to keep their tech stacks up-to-date.
After lunch was
I spent the remainder of the day hanging out in the Sucuri booth and in the happiness bar. I helped several people with issues on their sites ranging from simple CSS issues to a site that had been compromised. It was my experience that afternoon (and a few sessions on Sunday) that made me realize that those of us in the infosec space still have a long way to go in terms of educating everyone on proper site security. I’m not throwing shade at any person, and especially not anyone that I assisted in the happiness bar. On the contrary. Everyone has to be new at some point, and we can’t expect everyone to be knowledgable on security right from the beginning. What we need to do is make sure securing their site is intuitive and easy. We need to make sure that we make products that are secure to begin with and stay secure with little-to-no-effort on the part of the end user. And we need to make sure there are plenty of talks, sessions, articles, etc. for anyone who has questions or wants to dig in deeper.
The after party was fun. David orchestrated a game of trivia via