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();
to
$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.
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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.