Version 4.1.0 of WPCloudDeploy has only two new features. In fact, it probably has the least amount of new features of any release we’ve ever done.
But there’s a good reason for that.
Before we talk about that reason, here are the two new features:
- You can now choose a language / locale when installing WordPress
- Automatic updates from our servers are now enabled for new versions (after entering your license keys).
We have more information about these new features in a separate 4.1.0 What’s New article.
However the biggest news in this version – and the reason for the limited new feature set is:
Our Code Security Audit
Earlier this month we contracted with Dewhurst Security and WPScan to conduct a security audit of WPCloudDeploy.
It’s the first external security audit for the plugin.
The WordPress ecosystem has few plugins that have been through a formal stand-alone security audit. Most plugins that go through an audit are paid for by end-users/customers as part of their website penetration testing – which includes dozens of other plugins in the mix, plus the theme and any custom code. As you might expect, those types of customer-sponsored audits might not be exhaustive for a specific plugin.
Which is one reason why we wanted to have our own audit done – to make sure that we had a more exhaustive audit. And, of course, to discover potential issues before they impacted our customers.
About The Process
Getting the audit scheduled was relatively simple. We worked with Ryan Dewhurst at WPScan (and owner of Dewhurst security). He provided a simple quote and a timeline after taking a peek at the plugin. He then scheduled a full week for the review and started the project about three weeks after we signed their audit agreement.
We had one web meeting where we answered questions about the plugin. Other than that they did their thing and provided a full report the weekend following the project start date.
We then made the fixes and resubmitted the plugin to them for verification.
It couldn’t have been simpler or less intrusive for our operations.
Summary of Results
Frankly, we had no idea what to expect from this process. We knew that there would be issues found – that’s just the norm in any software development project and security audit. We just didn’t know if we would be facing one day’s worth of issues or a full month’s worth of issues to be resolved.
As it turns out, there were:
- Zero critical issues
- One high priority issue
- Zero medium priority issues
- Five low priority issues and
- Three informational issues
To say that we were pleasantly surprised is an understatement. Though, to be fair, we did pay a lot of attention to security during development.
Still, having 31,000+ lines of php & js code audited and ending up with only one high priority issue and zero critical or medium priority issues definitely has us ecstatic!
Issues Resolved
All the reported issues have been resolved or addressed in this version of WPCD.
All but one was resolved in the codebase within 12 hours of the report. The highest priority issue was resolved within an hour of the report.
The last item to be resolved took a bit longer because we viewed it as an opportunity to do some slight restructuring of the error logging code.
Over all, it took us one day to make the initial fixes, and one additional day for QA and to resolve minor issues revealed by the QA process.
Then we just had to wait for WPScan to do their thing again and apply any additional fixes they recommended.
Making Things Public
You might be wondering why we’re making this information public. It should be embarrassing, right? And so you probably think we would want to keep it all hidden.
No.
Not. At. All.
The reason is very simple – every time an issue is found, it just makes our product that much more secure.
And by making the information public we hope that it gives you the confidence you need that we’re not going to be hiding anything from you!
Any vendor that tells you that their product has no security issues is blowing smoke – the best they can tell you is that it has no security issues that THEY know about.
As a software publisher we just need to always assume that our code is insecure and approach everything defensively – especially for mission critical applications such as WPCloudDeploy.
So, let’s publicly talk about the issues that were raised in the security audit report.
The Issues
Here is a summary of the issues, straight from the report that we received from WPScan:
High: Unauthenticated Stored Cross-Site Scripting
This was the highest priority item on the list. The issue involved our logs – if a JS script somehow ended up in the logs it would be executed when an admin viewed them. If the JS was malicious then bad things could happen.
It was rated high because, in a worst case scenario, it could allow an un-authenticated attacker to completely compromise a WordPress site.
However, in their (WPScan) words:
The first XSS affected the Command Log, SSH Log and Error Log pages, due
to the pages not encoding output. This vulnerability could be exploited by an unauthenticated attacker, but would require a lot of user interaction, such as an administrator user cat’ing the cloud web server access log file, and then viewing the command’s output on the SSH Log page.
Basically, it would take a lot of cooperation on an admin’s part to exploit the vulnerability.
Low: Authenticated Stored XSS via WordPress Password
With this item it was possible to inject JS code into the site detail screen.
For most users, the admin is the same person that is creating the site so this issue is irrelevant.
But, the site-creation function can be delegated to non-admin users via our TEAMS function. Thus, with this vulnerability a non-admin that was granted limited access could cause malicious JS code to run when the admin viewed the site detail screen.
Low: WordPress Admin Password Exposed in Plaintext
This one is pretty simple to explain – the WP password can be seen in the error log, ssh log and command log tables – until the logs are deleted or rotated. The security researchers didn’t like that.
This is the item that took the longest to remedy because it gave us an opportunity to do some slight refactoring of the logging code that we wanted to do anyway.
If you’re concerned about this, just use the PURGE button at the top of your log screens. Starting in 4.1.0 of WPCD, WP passwords and S3 credentials should not show in the logs.
Low: Authenticated Command Injection via WordPress Password
It turned out that, under certain circumstances one could send server commands via the WP Password field when creating a new WordPress site.
As with one of the other items above, for most users, the admin is the same person that is creating the site so this issue would be irrelevant.
But, as we noted prior, the site-creation function can be delegated to a non-admin user via our TEAMS function. Thus, with this vulnerability a non-admin that was granted limited access could run server level commands that they weren’t authorized to execute.
Low: Default Hard Coded Encryption Key
This is one that we knew about and was by design.
When you first install the plugin a notice is displayed at the top of wp-admin with a warning that an encryption key needs to be set.
If it’s not set then we use a well-known string as the encryption key (which effectively means no encryption).
Thus, the researchers felt the need to flag it as an issue. And it is indeed an issue until the user resolves it.
The WPScan folks provided a sort of in-between recommendation. The suggestion would address the case where the admin/user just blatantly ignored the warning message.
For WPCD 4.1.0, we now create a temporary random key that is stored in the database. Because the key has to be stored in plain-text in the DB, it’s still not as secure as if the admin created one in wp-config.php.
Thus, even with the temporary key, the warning does not go away until the user creates a valid encryption key in wp-config.php. But if the message is ignored, there is now a better default level of encryption that is used to protect sensitive data.
Low: Non Random IV used in Encryption
This particular item related to one of the parameters we passed into the openssl encryption functions. Because of the way the parameter was generated it made it easier to decrypt the data using a brute-force or dictionary attack.
In version 4.1.0 an upgraded encryption method will be used as soon as you click the SAVE button on your settings screen.
INFO: Missing Access Controls in AJAX Calls
Out of all the issues WPScan raised we were most embarrassed by this one. We thought we were very careful about this but it turns out we still missed a few AJAX calls.
The affected calls were still partially protected via Nonces but needed an additional security check to be fully secure from the most aggressive threats.
INFO: Unauthenticated Full Path Disclosure
This item only applies if a web server is configured to display detailed errors to the end user. If the server is configured to display errors, then attempts to directly execute certain php files in the plugin would throw an error that disclosed the full server path of the file.
However, production web servers should never be configured this way (and most aren’t) because of the amount of information that would leak out.
Thus, this item is informational only and resolution depends on a web server being properly configured.
INFO: Example Encryption Key In Documentation
The concern here is that a user might just copy and paste the example code and encryption key from the documentation into the wp-config.php file.
Our resolution here is to detect the use of that example key and post a warning at the top of wp-admin.
Risk Ratings
Some of you might be wondering how the risk ratings are calculated. Here is the matrix that WPScan used to assign them:
And the definitions of the some of the items in the image above:
Wrap Up
If you’re a reader who do not routinely read or encounter security-related articles, this disclosure might completely scare you. It all sounds really bad to the lay person. However, you should know that even the largest companies find issues whenever they do security audits – Apple, for example, just finished up one on their internal networks and found quite a few issues. Microsoft found and fixed a severe level 10 issue in Windows just last month.
The key here is that companies are being proactive about security instead of sitting back and letting bad actors find and exploit them.
So, in reality, this is all very good news for you and WPCD. Why? Consider the following:
- The plugin has had PROFESSIONAL security researchers attempting to find as many holes as possible.
- The issues that were discovered have been fixed.
- The researchers found no critical issues, no medium level issues and only one high priority issue. Which means that you have a level of confidence that our development practices are generally working to prevent the most egregious issues from surfacing in the code in the first place.
An attacker will never be able to use these issues as an attack vector in the future. It would be a far worse situation if we sat back with our heads in the sand, never subjected our code to outside audits, and let an attacker figure out the issues and exploit them.
So, this stuff is really really really good for you as a customer.
Don’t get us wrong here – no software is ever fully 100% secure but we’re doing as much as possible to make sure that we don’t do silly insecure things.
Overall, we believe that this audit makes WPCD the most secure plugin of its kind. And arguable more secure than some SaaS WordPress management panels since you:
- Know that a security audit was done.
- Know WHEN the security audit was done (a security audit that is too old isn’t as useful.)
- Know the results of the security audit.
- Know that any discovered issues were handled and
- Can view the full source-code to verify issues and related fixes.
If you have any questions, please send us a note using either our ticket system or the support email address shown at the very bottom of this page.
Was This Article Useful? Or do you have questions or comments about it (or our products & services)? We'd love to hear from you!
Automatic Notification Of New Articles
Sign up to get automatic notifications of new articles. This is a different list than our standard list - you only get new articles once a week (usually on Mondays). No other emails will be sent unless you sign up for our general list as well.
Follow us on Twitter! We post a lot of cool things there first. To keep up, click the "X" below!