WordPress.org

Ideas

Security - Change plugin directory name on deactivation

  1. cnelsonjeffers
    Inactive

    12345

    This relates to a recent analysis by the team at WordFence indicating that plugins present the greatest security vulnerability to WordPress installations.

    https://www.wordfence.com/blog/2016/03/attackers-gain-access-wordpress-sites/#comment-23495

    Foremost in this of course are poorly-written or old plugins not updated to address the latest exploits.

    It was noted that simply deactivating a plugin does not solve the vulnerability, as the code is still present and accessible in the plugins sub-directory, which has a known URL path.

    Here's the idea: implement functionality that would automatically CHANGE the name of the plugin directory upon deactivation (perhaps to a random string - like /wp-content/plugins/my-plugin/plugin.php, changed to /wp-content/plugins/e54g587$2/plugin.php) - OR (suggested by the WF team) add a .htaccess rule snd/or file that would block access to that plugin directory until the plugin was re-enabled.

    A potential problem might be monitoring and automatically updating plugins contained in re-named or blocked folders, so that would need to be accommodated to enable de-activated plugins to obtain the latest security fixes.

    Posted: 1 year ago #
  2. Ipstenu (Mika Epstein)
    Administrator

    There are two meanings of 'deactivate' here.

    1) You the admin goes in and presses deactivate on a plugin you don't want.

    Awesome ... now you'll never get plugin updates? Also WP would have to store somewhere the old name so you could re-activate. I mention this becuase if that was the case, then someone can still backdoor :/

    2) You mean rename in the plugin repo, and that would break SVN. Literally. So no, we actually can't do that :/ Also keep in mind if we DID, then someone else could snipe the name and push a plugin with even worse code...

    In both cases, we can't do .htaccess either, not everyone's on apache (nginx is on the rise).

    Posted: 1 year ago #
  3. cnelsonjeffers
    Inactive

    12345

    I'm specifically suggesting something that would happen internally to the WordPress installation.

    The idea would be to make it at least more difficult if not impossible for someone on the outside to access php files in a deactivated plugin, by turning the plugin path from something known, to something unpredictable. (since the plugin is deactivated and not being used, there isn't the issue of breaking it due to its reliance on standard WP paths).

    I agree there is an issue then with obtaining updates to that deactivated plugin. I don't know if that could be somehow addressed to allow the WP install to internally "know" where the deactivated plugin is by re-mapping to the modified URL, so that it could continue to update the plugin - or perhaps the plugin under this scheme would have to be temporarily reactivated in order to update it.

    You are correct that the modified path would have to be stored somewhere in the WP database, hopefully in a secure manner.

    As to the potential for discovery of the original path name in the database through a back door, it seems to me that if a hacker has already obtained backdoor access into the WP database, then you've already got a problem far more severe than the ability of an intruder to reverse-engineer the location of a deactivated plugin through the database entries.

    The point is to potentially harden the WP install by addressing the reality that a vulnerable or insecure plugin being deactivated does not reduce the vulnerability of that plugin, since the code is still intact and is in a known location within the WP install.

    Obsfucating that location by exchanging a portion of the path for a random string would at least make accessing a back dooor through a vulnerable deactivated plugin, more difficult if not impossible.

    Of course the best remedy to a vulnerable plugin is to remove it completely, and delete all files and related tables. Not all operators undertake that step however, and mistakenly believe that simple deactivation is sufficient. This is an attempt to address that.

    The point regarding the viability of using .htaccess across all platforms is well taken.

    Perhaps this is an example of functionality that would be better addressed by one of the security plugins as an additional feature.

    Posted: 1 year ago #
  4. Ipstenu (Mika Epstein)
    Administrator

    Ah so #1 from my examples.

    Saving the rename would be interesting. That could be done, though with the current state of the API it wouldn't be possible to update the plugins. They'd be 'unfindable' but still vulnerable.

    Maybe it would be better to alert people to 'Hey you have X inactive plugins/themes'?

    Also this would clash with Multisite, where you may have plugins only active on one or two sites :/

    Posted: 1 year ago #
  5. cnelsonjeffers
    Inactive

    12345

    Possible solution then (as long as it is possible to still identify available updates for disabled and obfucated plugins) might be that the site would go into Maintenance Mode, temporarily restore the path of the deactivated plugin, process the update(s), and then de-activate / re-obsfucate the plugin.

    The process would take only a few seconds so there would be very little window to exploit a vulnerable deactivated plugin during its temporary de-obsfucation. Using a new random string on re-obsfucation would probably be a good idea too.

    A dashboard alert to the number of currently de-activated plugins might not be a bad idea coupled with an advisory that a best practice is to completely delete and removed un-needed plugins. On the other hand I commonly have administrative-type plugins that I use occasionally but deactivate to reduce ongoing server load.

    I can see where the Multisite might have additional challenges, but then it sounds like in that case the plugin would be still be operational for one or more of the sites, so the vulnerability if it exists would be higher profile - not much different than a vulnerable plugin being active on a single site.

    You would not be in quite the same situation where an operator simply deactivated a suspect plugin thinking that would remove any vulnerability presented by the plugin. In Multisite perhaps the obsfucation measure would only occur if the plugin was not in use in ANY of the sites.

    The real trick is keeping up with identifying which specific plugins are vulnerable due to poor coding or new exploits - a task probably better suited to one of the third-party security monitoring services.

    Posted: 1 year ago #
  6. Stefan M.
    Inactive

    create a .htaccess in the plugin directory which block access from web to the plugin when deactivated.

    Whould be very easy and no renaming is needed.

    Posted: 1 year ago #
  7. Ipstenu (Mika Epstein)
    Administrator

    Not every server uses .htaccess

    Posted: 1 year ago #
  8. goldpreis
    Member

    Thank you, nice idea. Here in germany it will work nearly 100%. I donĀ“t know a provider who will not support a .htaccess.

    Posted: 1 year ago #
  9. Ipstenu (Mika Epstein)
    Administrator

    I know a dozen in Germany. More in Canada. Thousands in the US.

    Anyone using Windows Servers.

    Anyone using NGINX.

    I'm sorry, but htaccess is not an acceptable solution.

    Posted: 1 year ago #
  10. Head Goldfish
    Inactive

    Could you not at least use a randomly-named directory for all plugins?

    So you'd have wp-content/plugins/some-random-string/all installed plugins. The string could be defined in wp-config at install, and perhaps even changed periodically by a cron job. And then everywhere that refers to the plugin directory would just have to check wp-config to get the current random string, which would be at least as secure as everything else in the config file.

    Obviously it wouldn't be bulletproof but it'd help, no?

    Posted: 5 months ago #

RSS feed for this topic

Reply

You must log in to post.

  • Rating

    12345
    2 Votes
  • Status

    This is not a core suggestion