WordPress Plugin Developers Don’t Do a Good Job of Making Sure There Plugins Are Free of Vulnerabilities They Know of
Our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins recently caught a good example of an ongoing problem we see when it comes to the developers of WordPress plugins, a failure to make sure that security vulnerabilities that have been in their plugins have been fully removed. In some cases that involves them only fixing one instance of a vulnerability in a plugin and not making sure that there are not any others in the plugin, in others, like this situation, making sure that the vulnerability isn’t in other of their plugins.
Back in October we disclosed a cross-site request forgery (CSRF)/local file inclusion (LFI) vulnerability in the plugin Companion Auto Update. We recently started checking for that type of vulnerability with our proactive monitoring and it quickly lead to us finding that another plugin by the same developer, Companion Sitemap Generator, contains it as well due to the same code that caused the issue with their other plugin.
Clearly relying on developer’s to keep their plugin secure when they fail to make sure to avoid issue they know have been in their plugins leaves a lot to be desired and that is where we come in. Our Plugin Security Checker will alert you if plugins you use possibly contain the same type vulnerable code (and possibly contain more serious vulnerable code). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over that or you can order the same type of review separately.
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.
Technical Details
The issue occurs in a couple of files in the plugin. One of those is /dashboard/sitemap/start.php. In that file if the GET input “tabbed” exists it will be included (through use of the require() function):
21 22 23 24 25 26 27 | if( !isset( $_GET['tabbed'] ) ) { require( 'dashboard.php' ); } else { require( $_GET['tabbed'].'.php' ); |
Through path traversal that code could allow any file with a .php extension to be included, causing the code in the specified file to run.
That file is run when the function csg_dashboard() is run:
224 225 | function csg_dashboard() { require( 'dashboard/sitemap/start.php' ); |
And that in turn runs when accessing the plugin’s Sitemap page, which is accessible to those with “manage_options” capability:
182 | add_submenu_page( 'tools.php', __('Sitemap', 'companion-sitemap-generator'), __('Sitemap', 'companion-sitemap-generator'), 'manage_options', 'csg-sitemap', 'csg_dashboard' ); |
Normally only Administrators have that capability. Seeing as Administrators can normally do whatever they want, them intending to use that to cause a file to be included wouldn’t be a vulnerability since among other things they could normally remove security code that would restrict something like this from being possible or just upload a plugin that runs any code they want already.
But in this case, an attacker can cause this to happen without the Administrator intending it since if the attacker could get the Administrator to visit a URL they specify they can cause the local file inclusion vulnerability to be exploited.
Proof of Concept
The following proof of concept will cause a file named test.php in the root directory of the WordPress installation to be included, when logged in as an Administrator.
Make sure to replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]/wp-admin/tools.php?page=csg-sitemap&tabbed=..%2Ftest