As WordPress site owners, securing our data is a top concern. We want to do everything in our capacity to protect our site, its visitors and our customers against any harm.
There are many reasons to why our WordPress sites are vulnerable – bad hosting, poorly coded plugins and themes, or weak passwords. WordPress experts suggest standard practices like picking strong passwords, keeping WordPress updated, removing unused themes/ plugins, etc to improve security. However, majority of users rely on security plugins to safeguard their sites from attacks. But how effective are these security plugins? Do they really protect our sites from all possible attacks? Or do they just create a false sense of security in our minds?
Almost all the WordPress security plugins focus mainly on login security. But statistics indicate that brute force login attacks make up a very small percentage of attacks. The plugins do little to prevent exploits in plugins and themes. To prove our point, we analyzed four different hacks in recent times and tested it with some of the popular security plugins. The plugins have been chosen based on their rating in the WordPress repository and their evident popularity on various WordPress forums. The plugins are –
Here is a gist of settings we enabled for each plugin. We went through the detailed description of the plugins in the WordPress repository. All the important features highlighted by the plugin team have been enabled by us as part of this experiment.
BulletProof Security (BPS)
The plugin has mainly focuses on .htaccess protection and login security.
- Backed up the current .htaccess files using Backup & Restore
- Activated the .htaccess files in root and admin folders
- Went with the defaults, didn’t change any setting here.
The plugin provides support for caching, cell-phone sign-in (two factor authentication), malware scanning, IP/ country blocking, and a host of firewall options.
- Caching – Enabled Wordfence Falcon Engine
- Two Factor Authentication – Enabled cell-phone sign-in
- Malware Scanning – Went with the default i.e. Wordfence’s automatic scheduled scans
- Firewall Options – Went with the defaults, didn’t change any setting here.
Apart from the default options, we enabled the following in the Settings section –
- 404 detection
- File change detection
- Hide backend feature
- Malware scanning
- Protect system files
- Disable directory browsing
- Filter request methods
- Filter long URL strings
- Remove file writing permissions
- Disable PHP in uploads
- Display random WordPress version
- Completely disable XMLRPC
The plugin classifies its features into different sections and each section has a score associated. We have enabled features such that the maximum score is hit for a given section.
- User Accounts – No change was needed here as we didn’t use the default admin username
- User Login – Went with the defaults, no changes here
- User Registration – Enabled CAPTCHA on the registration page
- Filesystem Security – Set recommended permissions for all folders
- Firewall – Enabled basic firewall and pingback protection
- SPAM Prevention – Enabled CAPTCHA on comment forms and block spambots from posting comments
- Copy Protection – Enable copy protection
With that, the security plugins were set up and ready for testing. We picked up four major exploits that have been discovered to check how far these plugins were successful in preventing them. The vulnerabilities belonged to different categories – remote code execution, SQL Injection, etc. That way we could also gauge the coverage that the plugins provide in mitigating the attacks.
Remote Code Execution – Timthumb Vulnerability
Remote Code Execution is a type of vulnerability where attackers upload scripts to writeable folders within your site and execute them remotely. The attacker can do anything from posting ads to creating a new admin user by exploiting this vulnerability. Many WordPress plugins and themes store files within local folders for later use. One such example is the cache folder. This folder is often used by cache plugins to improve the performance of a site. The files are stored in the cache folder and then accessed repeatedly instead of fetching them from the original source. However, when this isn’t implemented correctly with appropriate checks in place, it can spell a lot of trouble. The recent TimThumb vulnerability is an example of such a case.
TimThumb is a simple PHP script that resizes images. Many website designs have image areas that have a specific size. TimThumb can make the images fit these spaces without having to manually create multiple copies of the image in an image editor. It used the (writeable) cache folder within the current theme directory to achieve this. A lot themes and plugins include this script to resize images.
A vulnerability was found, not too long ago, in the TimThumb script that allowed attackers to upload and execute malicious PHP code on your site. The script, by design, permitted a specific set of domains to upload files to the site. These included popular media sites like flickr, picasa, photobucket etc. But there was an issue with checking if the incoming domain (where the image resided) matched with the predefined domain list. For example,
The above request was allowed in by the script. Moreover, the script wouldn’t delete source files from the cache directory even when the file failed to meet requirements. This allowed attackers to upload any file to the cache directory. Once uploaded, the attacker could then execute the malicious script directly from the cache directory. All he needed was the MD5 equivalent of the file name.
Let us now check if the security plugins can prevent this problem. We enabled the plugins one by one and recreated the issue.
BulletProof Security – The .htaccess file added by the plugin in the root folder includes a timthumb specific rule. However, we were still able to upload and execute the script remotely. The plugin failed to prevent this issue on our site.
Wordfence Security – We couldn’t find any way of preventing the issue using this plugin.
iThemes Security – There is no clear way to prevent the attack with this plugin. The plugin provides an option to rename the wp-content folder. This way the attacker may not be able to execute the script remotely. However, this doesn’t solve the core problem involving write/ execute permissions and only provides security through obscurity.
All In One WP Security – We couldn’t find any way of preventing the issue using this plugin.
Remote Code Execution via Comments – WP Super Cache vulnerability
We already discussed remote code execution in the first vulnerability. But scripts don’t always have to be uploaded onto the site for attackers to execute them remotely. A vulnerability was recently discovered in the very popular W3 Total Cache and WP Super Cache plugins that allowed remote users execute arbitrary code using comments.
A cache plugin supports special tags to denote dynamic content within a page. Such dynamic snippets within a page will not be cached by the plugin. When these tags are used within your post comments, they too get interpreted and executed on the server.
We repeated this test with the security plugins enabled. Unfortunately, none of the plugins were able to prevent this attack.
SQL Injection – Firestorm Real Estate plugin vulnerability
SQL injection is one of the most effective and far-reaching attacks in database driven systems like WordPress. It is a technique wherein malicious SQL statements are used to attack databases. The exploit can vary from dumping your database content to creating users in the wp_users table. One such example is the Firestorm Real Estate plugin. This plugin became vulnerable to a SQL injection attack due to improper input sanitization.
The FireStorm Professional Real Estate Plugin helps users search for real estate based on a province or country. The plugin uses either ProvinceID or CountryID to index into the database. However, in both cases, the values are retrieved directly from the GET parameter without any validation. This opens up the plugin for SQL injection attacks and lets intruders to select arbitrary data from the database. An example of such a URI is –
Plugin time! Let’s see what the security plugins do to prevent SQL injection attacks. We used the following URL for our tests –
BulletProof Security – The plugin prevents the query from execution by adding appropriate rules in the .htaccess file. This is blocked only when you activate the master .htaccess file created by the plugin. Besides, the solution only works on exploits using GET parameters. POST parameters, on the other hand, would be let through. Another key point is that the htaccess restrictions of keywords seems to be extremely strict and can hamper with normal working of the site in many cases.
Wordfence Security – We couldn’t block the attack with this plugin.
iThemes Security – The plugin provides a Filter long URLs setting to prevent this attack. It isn’t enabled by default and must be done explicitly. Unfortunately, we found a way to circumvent this easily. By adding &infinity=scrolling&action=infinite_scroll to the end of the SQL query, the URL length check is skipped.
All In One WP Security – We couldn’t find any setting in the plugin that’d help us prevent this attack.
SQL Injection using HTTP POST requests – Custom Contact Forms plugin vulnerability
In the previous case, we saw how URL strings were being used to attack your database. Another vulnerability was discovered in the Custom Contact Forms plugin that allowed attackers to execute arbitrary SQL statements remotely. Hackerscan exploit it to create new administrative users or modify database contents. All the hacker needs to do is to add the SQL statements in a file and then send it using a HTTP POST request. The plugin take this SQL file and runs it, thereby providing the hacker with unrestricted access to your database.
Contents of the SQL file, test.sql:
INSERT INTO wp_options(option_name, option_value) VALUES (‘bvkey1′,’val1’);
The POST request sent:
The new row created in wp_options table:
Since this issue is exploited using a code snippet that’s deep within the vulnerable plugin, it is extremely tough to prevent it. Unfortunately, none of the plugins could rise to the challenge.
In summary, most attacks seem to be slipping past the security measures that we have in place. Should we remove security plugins from our site? Not really. The security plugins bring a lot of value add through the many features they support. However, a lot more work is required in this area to plug all the holes and keep the evil-doers at bay. More than anything, they must prevent the vulnerabilities that are already discovered. This is the least we can expect as users. Compare this situation to buying an anti-virus software that doesn’t protect your computer from the latest viruses. Would you even consider using that software? If your site hasn’t been hacked so far, the credit may not necessarily go to the security plugin. You could just have been lucky!