Are Your Websites Up to Date?You can keep track of what versions of concrete5, Drupal, Joomla, Magento, MediaWiki, Moodle, PrestaShop, Revive Adserver, TYPO3, SPIP, WordPress, and Zen Cart are running on all of the websites you manage with our Up to Date? Chrome app.
Search This Blog
- Hacking Team Failed To Take Basic Security Measure With Their Website
- Security Company with WordPress Security Plugin Doesn’t Keep Their Own WordPress Installation Up to Date
- Magento Still Failing To Take Basic and Important Security Measure with Their Software
- Behind the Scenes of a Hack That Causes a Website to Redirect on Mobile Devices
- Sucuri Security Uses Bad Data to Try to Scare People into Using Their Service
Web Software Updates
WordPress VersionWe are running WordPress 4.3.1 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Bad Security
For years we have discussed the fact that in many cases with publicly disclosed security vulnerabilities in WordPress plugins, no one bothers to notify the developer or WordPress.org about them (that includes organizations selling WordPress security services like WordFence and WPScan). In many cases if this was done that would be enough to get them fixed. In other cases, when the vulnerability does not get fixed, the plugin will be pulled from the WordPress.org Plugin Directory and that will prevent more websites from adding the vulnerable plugins (alerting people that they are using plugins that have been removed from the directory is something we have been pushing for for years).
We have more than enough time taken up looking into to security issues in plugins, so we rarely look into security issues with themes, but we happened upon one last week that shows the lack of reporting extends to theme issues. Back on February 13 an authenticated arbitrary file upload vulnerability was disclosed in the current version of the Fusion theme, which was available on the WordPress.org Theme Directory. After confirming that the vulnerability existed we reported it to WordPress.org and then within an hour it was pulled from the directory.
What was troubling is that we don’t appear to have been the only people that had taken a look. Here is a screenshot of the graph of downloads from right before the theme was taken down from the Theme Directory:
We are pretty sure that spike in downloads shortly after the disclosure is related to people looking into the vulnerability and yet no one else looking at the issue bothered to report it. That includes the people at WPScan, who again included a vulnerability in their vulnerability database, but didn’t report it.
On March 8 an arbitrary file upload vulnerability, which would allow anyone to upload any kind of files to a website, was disclosed in the Reflex Gallery plugin. This type of vulnerability is probably the most serious vulnerability for a website since, unlike many types of vulnerabilities that rarely get exploited, it is question of when, not if, it will be exploited on websites. This is due to the fact that a hacker can use the vulnerability to upload a .php backdoor script, which will give them remote access to the website without having to interact with the software already running on the website. The only good news in this case it that the plugin is not very popular, the WordPress Plugin Directory lists as having 2,000+ active installs.
When we started to take a look at the vulnerability report to include it in our plugin that notifies of known security vulnerabilities in WordPress plugins we noticed that this plugin had previously had another arbitrary file upload vulnerability that existed in versions 1.0-3.0. The proof of concept for the previous vulnerability looked similar to the new one, both of them targeted the file /admin/scripts/FileUploader/php.php in the plugin. The main difference between them was that second included a couple of URLS parameters in the request, ?Year=2015&Month=03. Our first thought was that new vulnerability might somehow be related those URL parameters, though as we dug in we found what was really going on.
In version 3.0.1 the first vulnerability was fixed by changing the line
$allowedExtensions = array();
$allowedExtensions = array(“jpeg”, “gif”, “png”);
in the file /admin/scripts/FileUploader/php.php.
That restricted what file extensions could be uploaded, so that .php files could not be uploaded. While this provided basic protection, it was less than should have been done. Since the front-end of the plugin’s upload functionality is only accessible admin users the underlying upload function should have also been restricted to admin users. That way if there were some other vulnerability in it only admins would be able to exploit it, which really isn’t much of a problem. There are a couple of other potential issues that come from allowing anyone to upload files. First, you have the chance for denial of service (DOS) attack from someone filling up all of the websites disk space with uploaded files. Second, since only the file extension is limited, it is still possible to upload files with PHP code, which could be combined with a local file inclusion (LFI) vulnerability to exploit a website.
We then looked at what changes were made in the most recent version, 3.1.3, and that showed what happened with the second vulnerability. In the file /admin/scripts/FileUploader/php.php the line
$allowedExtensions = array(“jpeg”, “gif”, “png”);
was changed to
$allowedExtensions = array();
So for some reason the fix that was put in place before was removed, which re-opened the vulnerability. What makes this seems odder is that the changelog for 3.1.3 list only two changes made:
- Fixed issue of gallery info not updating on Edit Gallery page
- Additional security fixes
Last Monday, after looking into the vulnerability we attempted to notify the developer of the plugin about the disclosure of the vulnerability and the underlying cause. Were not sure if they got because when we submitted a message on their website’s contact form it didn’t provide any indication that message had been successfully sent. If we can’t reach a developer or they don’t respond our next step with a vulnerability that exist in a plugin that is available in the WordPress Plugin Directory is to report to the people running it. We originally planned to do that on Friday as that would have give the developer four days to deal with it first, but then on Thursday while reviewing our log files to see what WordPress plugin vulnerabilities there had been recent exploit attempts for we saw that there was attempt to exploit this vulnerability. It was done during a series of requests (shown below) that included trying to exploit some rather old vulnerabilities so it is likely that was not an attempt based on the recent disclosure, but the previous one.
188.8.131.52 – – [12/Mar/2015:02:07:37 -0400] “GET /blog/2010/11/19/oscommerce-2-3-includes-fixes-for-security-vulnerabilities-and-security-enhancements//xmlrpc.php HTTP/1.1” 301 567 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
184.108.40.206 – – [12/Mar/2015:02:07:38 -0400] “GET /blog/2010/11/19/oscommerce-2-3-includes-fixes-for-security-vulnerabilities-and-security-enhancements/xmlrpc.php HTTP/1.1” 404 6349 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
220.127.116.11 – – [12/Mar/2015:02:07:41 -0400] “GET //xmlrpc.php HTTP/1.1” 200 439 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
18.104.22.168 – – [12/Mar/2015:02:07:42 -0400] “GET / HTTP/1.1” 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
22.214.171.124 – – [12/Mar/2015:02:07:52 -0400] “GET //wp-content/themes/vip/includes/uploadify/upload_settings_image.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
126.96.36.199 – – [12/Mar/2015:02:07:58 -0400] “GET / HTTP/1.1” 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
188.8.131.52 – – [12/Mar/2015:02:08:07 -0400] “GET /wp-content/themes//timthumb.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
184.108.40.206 – – [12/Mar/2015:02:08:10 -0400] “GET / HTTP/1.1” 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
220.127.116.11 – – [12/Mar/2015:02:08:19 -0400] “GET /wp-content/themes//thumb.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
18.104.22.168 – – [12/Mar/2015:02:08:23 -0400] “GET /wp-content/plugins/woopra/inc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
22.214.171.124 – – [12/Mar/2015:02:08:25 -0400] “GET /wp-content/plugins/wp-seo-spy-google/ofc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
126.96.36.199 – – [12/Mar/2015:02:08:27 -0400] “GET /wp-content/plugins/invit0r/lib/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
188.8.131.52 – – [12/Mar/2015:02:08:29 -0400] “GET /wp-content/plugins/chart/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
184.108.40.206 – – [12/Mar/2015:02:08:31 -0400] “GET /wp-content/plugins/wp-slimstat-ex/lib/ofc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
220.127.116.11 – – [12/Mar/2015:02:08:33 -0400] “GET /wp-content/themes/cameleon/includes/fileuploader/upload_handler.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
18.104.22.168 – – [12/Mar/2015:02:08:36 -0400] “GET /wp-content/themes/switchblade/framework/_scripts/valums_uploader/php.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
22.214.171.124 – – [12/Mar/2015:02:08:41 -0400] “GET /wp-content/plugins/reflex-gallery/admin/scripts/FileUploader/php.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
126.96.36.199 – – [12/Mar/2015:02:08:45 -0400] “GET /wp-content/themes/elemin/themify/themify-ajax.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
188.8.131.52 – – [12/Mar/2015:02:08:49 -0400] “GET /wp-content/plugins/front-file-manager/upload.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
184.108.40.206 – – [12/Mar/2015:02:08:52 -0400] “GET /wp-content/plugins/complete-gallery-manager/frames/upload-images.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
220.127.116.11 – – [12/Mar/2015:02:08:56 -0400] “GET /wp-content/plugins/is-human/engine.php?action=log-reset&type=ih_options();eval(base64_decode(JHM9cGhwX3VuYW1lKCk7CmVjaG8gJzxicj4nLiRzOwoKZWNobyAnPGJyPic7CnBhc3N0aHJ1KGlkKTsK));error HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
18.104.22.168 – – [12/Mar/2015:02:09:00 -0400] “POST /wp-content/plugins/radykal-fancy-gallery/admin/image-upload.php HTTP/1.1” 404 5864 “-” “libwww-perl/6.08”
22.214.171.124 – – [12/Mar/2015:02:09:02 -0400] “POST /wp-content/plugins/mm-forms-community/includes/doajaxfileupload.php HTTP/1.1” 404 5864 “-” “libwww-perl/6.08”
126.96.36.199 – – [12/Mar/2015:02:09:05 -0400] “POST /wp-content/plugins/html5avmanager/lib/uploadify/custom.php HTTP/1.1” 404 5864 “-” “libwww-perl/6.08”
At that point we immediately sent an email to the people running the Plugin Directory alerting to the vulnerability and the fact that it was currently being exploited (along with details on three other vulnerabilities). In most cases in the past when we having reported vulnerabilities to them in this way they have quickly responding by taken the plugin down until a fix was released, so that no additional websites would made vulnerable. Unfortunately, as of posting this on Monday morning the plugin has not been updated or pulled from the plugin directory.
Improving The Handling of Plugin Vulnerabilities
This situation highlights a couple of serious problem that come with the current handling vulnerabilities in WordPress plugins, but also points to where improvements can be made.
Making it Easier to Report Vulnerabilities
The current methods for reporting security vulnerabilities are lacking. You can try to contact the developer through their website, but isn’t also easy to find an email address or contact to do that. Some plugins have email addresses they specifically suggest you use to contact them about security issues, but they also can be hard to locate on their websites. You can try contacting the developer through the plugin’s support forum in the Plugin Directory, but not every developer monitors that closely and it is public so that can limit ability to safely disclose information. From what we have seen it appears that many people that are discovering vulnerabilities don’t know that the can also contact the Plugin Directory about the issue, which isn’t too surprising since it isn’t prominent displayed.
One possible solution for this would be to provide a mechanism on the plugin’s page on the Plugin Directory for security vulnerabilities to be reported, which would then send it along to the developer and the people running the Plugin Directory.
Checking on Fixes
What we see fairly often is that when developers attempt to fix publicly disclosed vulnerabilities they either only partially fix it or don’t fix it at all. In other cases the disclosed vulnerability is only part of a wider security issue. Putting a place a process where a review by someone with a better understanding of security is done after the developer thinks they have fixed the vulnerability could go a long way to improving the security of plugins. We already have a good idea of who could provide the financial supports this (in the meantime our checks during the process of adding the vulnerability to our Plugin Vulnerabilities plugin have lead to a number of these situation getting resolved).
In this case if the file uploading had been restricted to admins, then even with the undoing of the file extension restriction the security vulnerability would not have opened back up.
Auttomattic Sponsored WordPress Plugin Pods Still Hasn’t Fixed Publicly Known Security Vulnerability After Two Months
In discussing how the security of WordPress plugins could be improved we have put forward that Automattic, the company closely connected with WordPress, should have some responsibility for that. With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility. Shortly after putting forward that idea that we came across a security advisory for multiple vulnerabilities in Pods, a plugin that Automattic sponsors.
When we checked on the vulnerabilities to add them to Plugin Vulnerabilities plugin we found that despite the advisory saying that they were fixed in version 2.5, that in fact two reflective cross-site scripting (XSS) vulnerabilities listed still existed. Three days after the advisory was put out, January 15, we notified the Pods developers that vulnerabilities still existed. We promptly received a reply from them, but it didn’t seem like they really understood the situation.
A week later versions 2.5.1 and 188.8.131.52 were released, neither of which addressed the security vulnerabilities.
On February 5 and 9 we received emails from the developers that the vulnerabilities would be fixed in version 2.5.2. That version has yet to be released and it has now been two months that they have knowingly left the vulnerabilities in the plugin. Maybe this will be a wake-up call to Automattic that plugin security needs to be taken more seriously and that they can start playing a constructive role by improving the security of plugins they sponsor.
Back in September we looked at the fact that a website we were doing an upgrade of Magento on had a security seal from SiteLock claiming that the website was secure, despite the fact that it wasn’t since the website was running outdated software with known security issues. Fast forward six months and SiteLock is still labeling websites as secure when they are running outdated and insecure software.
Today’s case involves a website that we are doing an upgrade from Zen Cart 1.3.8a. That version is nearly five years out of date and there have been numerous releases with security improvements since then (due to its age, it isn’t clear exactly how many of those fix issues that existed in 1.3.8a). Despite that the website is labeled as being secure by SiteLock:
Not only does falsely claiming the website is secure mislead those visiting the website, but it also gives webmaster a false sense of security, which a security service shouldn’t do.
If SiteLock was actually interested in security it would quite easy for them to make sure the software on websites is up to date. Our Zen Cart Version Check extension for chrome is able to correctly detect the version in use from outside the website in this case:
With access to the website’s file, as Sitelock does, it is even easier to do and more accurate. For Zen Cart the version number is listed in the file /includes/version.php, so all you would need to do is to check files matching that for the following lines and you would know whether an outdated version of Zen Cart is in use:
define(‘PROJECT_VERSION_NAME’, ‘Zen Cart’);
In a previous post we looked at the fact that MOJO Marketplace distributes outdated software with known security vulnerabilities. Their lack of concern for security doesn’t end there; they have not kept their WordPress installation up to date:
If they actually used their own service they could be up to date, because unlike other software they offer they actually provide the latest version of WordPress:
Not only have they not updated to the latest major release of WordPress, 4.1, they haven’t applied the “critical security release” for 4.0 that was released on November 20. That would have normally have happened automatically, so either they disabled automatic updates, which is bad idea if you are not going to be on top of updating WordPress, or they have some problem blocking that from happening. If there was a problem and they actually cared about WordPress security getting to the bottom problem would have been the right thing to do as it could possible help others as well. Their lack of concern for the security of WordPress on their own website hasn’t stopped them from feeling it is appropriate for them to sell a WordPress security service to others though.
If you are looking to improve the security of your WordPress website you should check out our free Plugin Vulnerabilities plugin, which warns if you are using WordPress plugins with known security vulnerabilities.
Last week we noted that web hosts should stop providing the SimpleScripts software installation service to their users since it hasn’t been supported for some time, leaving people with outdated and insecure software on their websites. As part of that we noted that it looks like their service was replaced with the MOJO Marketplace. We decided to take a quick look at that service to see if they were keeping the software provided though it up to date and the results show that they have some problems, though nowhere near as bad as we found with GoDaddy last November.
To start with, they are still offering Joomla 2.5, despite support for that version having ended in December:
Somewhat oddly they provide the latest version of Drupal 7, but they don’t provide the latest version Drupal 6, despite those being released together in November. That version of Drupal 6, 6.34, fixed a session hijacking vulnerability.
For Zen Cart they have missed version 1.5.3, which includes security improvements and was released last July, and 1.5.4, which was released at the end of last year.
Last Wednesday we discussed an ongoing issues where security journalist conflate WordPress plugin’s download count at WordPress.org with how many websites are using the plugin, making a vulnerability seem like it has much larger impact than it actual it does. In the case last week the headlines proclaimed things like “More than 1 million WordPress websites imperiled by critical plugin bug” about a security vulnerability that existed in older versions of WP Slimstat, beyond explaining the fact that the security vulnerability in question was unlikely to be widely exploited, we pointed out that the website count used was way off base. The journalist were taking the 1.3 million downloads the plugin had and using that to back up their claim on over 1 million websites impacted, which they shouldn’t have since it isn’t close to being appropriate substitute for an actual count of use.
Over the weekend WordPress.org made a change that should stop this, as they started displaying a count of Active Installs in addition to download counts for WordPress plugins. In the case of the WP Slimstat plugin the actual number of websites using it is much less than a million, with the Active Installs listed at 100,000+:
Hopefully this will be a wake-up call to some of those journalist that they need to stop taking so many liberties when reporting on WordPress plugin security issues, since this isn’t the only problem that there has been with their coverage of the issue (which could use more quality coverage).
When it comes to what needs to be done to improve the security of websites there are so many things that could and should be done, but certain of them stand out for various reasons. One of the issues that stands out for us is web hosts who are distributing outdated web software. Web hosts are quick to blame many hacks on outdated web software – usually without evidence to support the claim – so you would think they would be careful about making sure that when they distribute web software through one-click installers and other similar mechanism that they are keeping the version available up to date. Too often that isn’t the case, back in November we looked at GoDaddy’s distribution of quite old versions of various software. The other day we ran across another example worth highlighting involving the one-click installer SimpleScripts.
While doing a cleanup of a hacked WordPress website we logged into the web host’s control panel for the website and got a pop up that the WordPress installation needed to be updated. Following the link in that brought up the SimpleScripts upgrade page and on that there was obvious problem, it listed the current version of WordPress as 3.9:
Version 3.9 hasn’t been the current version since 3.9.1 was released on May 8, 2014. A quick look at the list of the software versions provided by SimpleScripts showed that WordPress wasn’t alone in having a very out of date version provided. As best we can tell SimpleScripts is not being supported anymore. The SimpleScripts website makes no mention of it, but it appears that the service might have been replaced with another one-click installer MOJO Marketplace.
If you use a web host that is still using SimpleScripts please let know that it is no longer being updated and should be replaced.
We would love to see more quality press attention to the issue of WordPress plugin security because there certainly is much discuss, unfortunately, as with security journalism in general, when it does get discussed these days the reporting is mostly awful. Take for instance the Ars Technica article More than 1 million WordPress websites imperiled by critical plugin bug (written by the same person who last year wrote an article that we found to be completely baseless).
The words imperiled and critical are probably not appropriate, considering that the vulnerability in WP Slimstat was fixed in an update last week (you can turn of WordPress ability to automatically updates plugins with one of our plugins) and due to the type of vulnerability. The vulnerability is a blind SQL injection vulnerability, which can allow data to be read out of the database. While this has the potential to be rather serious if you store sensitive data on the website, this type of vulnerability isn’t often exploited by hackers that are not targeting specific websites (most hacks are not targeted). So the chances of it being exploited are rather small in comparison to say a vulnerability that allows PHP files to be uploaded to a website, which we can almost guarantee is going to be exploited, most likely sooner rather than later. The chances of this plugins vulnerability being exploited are even slimmer because it requires a fair amount computing being done before you can exploit it, unlike plenty of other blind SQL injections that have been found in WordPress plugins.
The big problem with the article comes from the claim in the title that “more than 1 million WordPress websites imperiled”. Over a million websites impacted make this sounds like a major issue, the problem is that it isn’t close to being true. If you read through the article nothing is provided that backs that number up, instead only the download count of the plugin is mentioned:
WP-Slimstat is an analytics tool. Its listing on WordPress shows it has been downloaded more than 1.3 million times. People who operate websites that use the plugin should update immediately.
Downloads of software obviously are not the same as how many websites are using software, so treating them the same is something a journalist concerned about accuracy wouldn’t be doing. But what makes it so bad for WordPress plugins is that each time a plugin gets updated through the WordPress admin area that counts as new download, so the actual user count is going to be much smaller than the download count, especially if the plugin is updated frequently. The download graph for one of our plugins dramatically shows how updates impact the download count:
You see that huge spike that on the graph, that is when we updated the plugin. On that day there were 148 downloads and the next day there 47 the next day. That compares to 9 downloads a day we averaged over the last week. Those two days work out to 13 percent of total downloads so far.
WP Slimstat is updated more often so there are lots of spikes on the graph, of which, most if not all are due to updates:
Ars Technica isn’t alone in this, a quick search pulled up more articles on this vulnerability with the same highly inflated website use count:
- Help Net Security: Over a million WP sites at risk of hijacking due to plugin bug
- ITProPortal: CRitical bug puts millions of WordPress sites in danger
- PCWorld: Million-plus WordPress sites may be vulnerable due to flaw in popular plug-in
- Threatpost: More than 1 Million WordPress Sites Open to SQL Injection Attacks
- ZDNet: Over 1 million WordPress websites at risk from SQL injection
It also worth mentioning that this type of article has the potential to be somewhat harmful to security since you need to being keeping your WordPress plugins update to date all the time instead of trying to be on the lookout for mentions of fixed security issues since security fixes often are not even mentioned in plugins’ changelogs.
One of the biggest problems we see with improving the security of websites is the amount of bad information out there, as it is hard to start to address the underlying problems when so much of what is being said is wrong. What surprised us when we started dealing with security issues is how much of that bad information comes from security companies. We don’t have the time to go through every instance of this since it is so widespread, but it is worth looking at an example of a company putting out bad information from time to time when a larger security issue is also raised.
On February 11, security researcher Claudio Viviani publicly disclosed a SQL injection vulnerability in the WordPress plugin WORDPRESS VIDEO GALLERY. According to his advisory he had notified the developer of the plugin about the issue two days before that. The next Tuesday we added the vulnerability to our Plugin Vulnerabilities plugin and on Friday, after waiting a few days to give time to the developer to release the fix, we notified the people running the WordPress.org Plugin Directory of that the vulnerability existed and had not been fixed. Following that the plugin was pulled from the directory. Earlier today they let us know the plugin had been removed and that the fixed version should be available soon. While checking to confirm that issue was fixed in the new version, which it was, we came across a forum thread that linked to a WordFence, which sells a WordPress security service, blog post entitled Zero Day SQL Injection Vulnerability in WordPress Video Gallery.
The problems with their blog post start with the title. This vulnerability wasn’t a zero day vulnerability since that involves a vulnerability being exploited before the developer or the public knows about the vulnerability. That wasn’t the case here as the vulnerability was publicly disclosed a week before and it appears the developer knew about it before that. The implications of a zero day vulnerability are much different than what this actually is, so the distinction is important. Zero day vulnerabilities do get more press coverage, so you might ask if they characterized it that way to try to get them attention.
That wasn’t the end of the problems, it continues into the content of the post:
There is currently a zero day SQL injection vulnerability in the WordPress Video Gallery plugin. Our researchers are seeing exploits in the wild for this and the exploits claim the vendor has been notified on the 9th of February.
If you click the “exploits in the wild” link what you get is not anything to do with exploits of the vulnerability in the wild, instead it is a copy of Claudio Viviani’s advisory on the Exploit Database website. The advisory itself doesn’t provide any code to exploit vulnerability. The proof of concept (POC) given simply shows where the SQL injection code would go:
It doesn’t include any malicious SQL code and providing the POC doesn’t really make much difference in exploiting the vulnerability since with the details of the vulnerability someone should be able to recreated the provided POC quite easily.
You really have to wonder about the competency of the WordFence researchers when they are claiming that a security advisory is somehow evidence of “exploits in the wild”.
Also in that section they half acknowledge the developer was notified of the vulnerability ahead of the exploitation, which would mean that this isn’t a zero day vulnerability as they are claiming.
The plugin still has not been updated by the vendor. Because this is being exploited actively and the vendor has been notified, we are now publicly disclosing the existence of this vulnerability.
WordFence isn’t actually publicly disclosing anything since the person that discovered the vulnerability already did that, it isn’t clear if they don’t know what public disclosure actually is or if they are intentionally trying to take credit for something they didn’t do.
A ‘googledork’ is also available in the exploit which allows attackers to use Google to find sites which suffer from this vulnerability in order to exploit them.
While this might sound ominous it doesn’t really mean much, the “googledork” in this case is simply a search query that shows URLs in Google’s index that are from RSS feature of this plugin. Here it is from the advisory:
# Dork Google: inurl:/wp-admin/admin-ajax.php?action=rss
Again this doesn’t actually matter much since all the search query does is show indexed URLs that contain the start of the path that is exploited:
Protecting Against Unfixed Vulnerabilities in WordPress Plugins
The situation with this plugin does get to a real problem, how do we protect against websites being hacked when known vulnerabilities in WordPress plugins are not fixed. WordFence’s solution beyond reporting the issue to the Plugin Directory, seems to be more effective at promoting their website then dealing with this type of situation:
Please share/tweet/mail this to your fellow WordPress administrators to help create awareness about this serious issue.
We have been pushing for a better approach to handling than this type of situation for years, which would involve WordPress warning admins when an installed plugin has been removed from the Plugin Directory (if you would like to see that happen please vote for it on the WordPress Ideas website). Until that happens you can use our No Longer in Directory plugin that provides a more limited version of that functionality. For this type of situation though one of our other plugins, Plugin Vulnerabilities, is more useful. This plugin warns when installed plugins have known security issue and also provides information on vulnerabilities that existed in other versions, which is useful when cleaning up a hacked WordPress website. Last Tuesday we updated the plugin to warn about this security vulnerability, so if you had our plugin installed and you had version 2.7 of the WORDPRESS VIDEO GALLERY plugin installed you would have then seen the following warning on the Installed Plugins page: