WordPress Plugin Security Review: AspireUpdate
As part of the ongoing situation between Matt Mullenweg and the WordPress community, there has increased concern about various aspects of WordPress. One area of concern is the continued ability to get updates for WordPress software from the WordPress update infrastructure. That led to the release of a new plugin, AspireUpdate, as part of a larger project to provide alternative infrastructure, AspirePress. As part of our focus on supporting efforts to reform WordPress, we decided to do a security review of the plugin.
If you want a security review of plugins you use, when you become a paying customer of our service, you can start suggesting and voting on plugins to get security reviews from us. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our main service.
The review was done of the plugin through updates made to in through January 10. We checked for the following issues during it as part of our standard review:
- Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
- Deserialization of untrusted data
- Security issues with functions accessible through WordPress’ AJAX functionality (those have and continued to be a common source of disclosed vulnerabilities)
- Security issues with functions accessible through WordPress’ REST API (those have started to be a source of disclosed vulnerabilities)
- Persistent cross-site scripting (XSS) vulnerabilities in the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below
- Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
- SQL injection vulnerabilities (the code that handles requests to the database)
- Reflected cross-site scripting (XSS) vulnerabilities
- Security issues with functions accessible through any of the plugin’s shortcodes
- Security issues with functions accessible through any of the plugin’s blocks
- Security issues with functions accessible through the admin_action action
- Security issues with functions accessible through the admin_init action
- Security issues with functions accessible through the admin_post action
- Security issues with import/export functionality
- Security issues with usage of the is_admin() function
- Security issues with usage of the add_option(), delete_option(), and update_option() functions
- Security issues with usage of the update_user_meta() and wp_update_user() functions
- Security with usage of determine_current_user filter
- Security issues with usage of the wp_set_current_user(), wp_set_auth_cookie() and wc_set_customer_auth_cookie() functions
- Security issues with usage of the reset_password() and wp_set_password() functions
- Security issues with usage of the extract() function
- Lack of IP address validation
- Proper usage of sanitize_callback when using register_setting() to register settings
- Existence of register_uninstall_hook or uninstall.php file that removes any WordPress options and database tables added by the plugin
- CSV injection
- Host header injection vulnerabilities
- Lack of protection against unintended direct access of PHP files
- Insecure and unwarranted requests to third-party websites
- Any additional possible issues identified by our Plugin Security Checker
Results
We found two places where security could be improved. After completing the review, we went to report the issues. That is where we found things to be problematic with the project. The GitHub project for that plugin has information on its Security page has this information about contacting them about vulnerabilities:
We sent an email to the email address listed and got back a response that “the email account that you tried to reach does not exist.” It isn’t a great look to have a security contact that hasn’t been set up. We then looked for a method to notify the project of that issue. Their website has a contact page with a contact form, which we used the same day to notify of them that issue. As of now, we haven’t received any response to that.
A week after the first attempt, we tried the security contact email address again, and it still didn’t work. We then filed an issue on GitHub, noting all that. We noted there shouldn’t be a risk just creating an issue with the security issues, but we asked if there was alternate security contact available or if the existing one could be setup. We got back conflicting responses from members of the team developing it. The Security page still tells you to contact that email address. None of the replies suggested it was being set up.
Missing Capability Checks
There are two AJAX accessible functions that are only intended to be accessed by some logged-in users to WordPress, but the functions didn’t include a capability check to restrict access. They did include a nonce check, which usually does the equivalent, but it should not be relied on for that. The relevant functions were clear_log() and read_log() in the file /includes/class-controller.php. The function current_user_can() can be used to implement the capability check.
There was the same issue with two functions registered to run during admin_init, which makes the function accessible to even those not logged in to WordPress. Those functions were reset_settings() and update_settings() in the file /includes/class-admin-settings.php. The function admin_notices() in the same file should also have had a capability check before taking its action.
The capability checks were added after we filed an issue for that.
Lack of Protection Against Direct Access to PHP Files
Some of the plugin’s .php files do not have code at the beginning of the files to restrict direct access to them. We didn’t see anything that could be exploited in the files without the restriction in place, but adding the code the plugin already has in other files would make things more secure.
We didn’t file a report for that, as it seems to minor an issue to do that.
Information Disclosure Issue
Outside of the scope of our current checks for reviews, the plugin has a debug mode that stores potentially sensitive information in a log file at a standardized location. Issues similar to that are something we are interested in checking for and catching during our reviews. The problem is doing that in a way that is effective in catching them. We already have been testing a couple of code checks looking for error reporting being enabled, but debug logging introduces new issues trying to check for that. We could check for new files being created when the plugin is active, but that wouldn’t do anything here, since the debug mode would also have to be turned on. Out of this we are going to be looking for code writing to files either through PHP’s functionality for that or WordPress’ related functionality.