We are seeing a lot of noise again regarding the Uploadify script vulnerabilities affecting some WordPress themes/plugins. If you are not familiar, Uploadify allows anyone to upload anything they want to your site without any authentication.
Very very useful, no? Maybe, but at what cost? If a bad guy/gal knows that you have the Uploadify script, they can upload anything they want too (backdoors) and hack your site.
First, Uploadify is nothing new. When we were reporting on the TimThumb vulnerabilities, we were also notifying everyone about the issues with uploadify.
- In October of 2011 we warned everyone to remove and check for Uploadify: Remove Unused/Testing/Debug Software From Your Site
- We put out a post in August of 2011 listing themes affected by TimThumb, we also listed the ones Using uploadify as unsafe: Timthumb Security Vulnerability – List of Themes
- An oldie but goodie, TimThumb (Tip of the Iceberg), Uploadify was also included
This is definitely an issue, but it’s just the tip of the iceberg. TimThumb is just one of various scripts that are being added to themes/plugins without further vetting, or even incorrectly. Take Uploadify for example, which we’ve recently seen being exploited in very old versions of a popular WordPress theme.
When this was all confirmed months ago, we started automatically removing the Uploadify vulnerability for all our customers. However, it is still an issue for everyone else. Here are some of the latest reports of Uploadify related vulnerabilities:
2012-06-13 WordPress plugin Foxypress uploadify.php Arbitrary Code Execution
2012-06-11 ClanSuite 2.9 Arbitrary File Upload Vulnerability
2012-06-05 Wordpress Foxypress Plugin 0.4.1.1 – 0.4.2.1 Arbitrary File Upload
2012-06-05 Wordpress HTML5 AV Manager Plugin 0.2.7 Arbitrary File Upload
2012-06-05 Wordpress WP Marketplace Plugin 1.5.0 – 1.6.1 Arbitrary File Upload Sammy FORGIT
2012-06-05 Wordpress WP-Property Plugin 1.35.0 Arbitrary File Upload
2012-05-25 appRain CMF Arbitrary PHP File Upload Vulnerability
2012-05-25 cPassMan v1.82 Remote Command Execution Exploit
2012-05-23 Wordpress Kish Guest Posting Plugin 1.0 Arbitrary File Upload
2012-01-19 appRain CMF <= 0.1.5 (uploadify.php) Unrestricted File Upload Exploit
There are many more themes/plugins out there using it, and many sites that can easily get compromised through it. This is a small list of the ones being scanned in the wild:
Note: The list below does not conclude that these plugins and themes are vulnerable. The list outlines active scans seen looking for the script in various plugins and themes.
What to do
Yes, we are seeing many Uploadify scans in the wild and sites getting compromised to it. If you have any of the themes/plugins we mentioned, we recommend deleting or disabling the uploadify script immediately. We also recommend doing a garage cleaning of your websites and servers, and delete any unused themes/plugins, since they can be compromised even if not in use.
Scans in the wild
Some of the Uploadify scans we are seeing in the wild:
Know if any other plugins, themes, web software using Uploadify? Leave us a comment.
Uploadify isn’t included in Pods by default, I wonder if someone hacked core and added it on their own site? We don’t even have a /js/ folder in the root of our plugin folder either, so that’s a big tell too.
Hey Scott, a note has been added to the post to clarify. Those are active scans for the script we’re seeing. That does not mean those plugins or themes are vulnerable or contain the script. Thanks for the clarification on your end!!!
To update, we actually used to have a /js/ folder in the root of our plugin folder a few years ago. Someone must have hacked core, added uploadify.php and the script
The vulnerability isn’t in Uploadify itself, but in the way it is implemented. Uploadify was created with customization in mind, but there are several ways the script should be secured when implementing in a production environment. The Uploadify site has articles regarding security in the docs section of the site.
At the very least, the Uploadify.php script should have a filetype check before saving files to the server. If executable files are allowed, then other security measures should be put in place.
I created Uploadify. I think it’s wrong to put the blame on the Uploadify script for these vulnerabilities. If that’s the case, we should all blame McDonalds for making us fat, right?
You’re correct in that the problem isn’t with uploadify itself, but in the implementation.
The problem is that what a lot of authors do when including a third party library is simply to include the whole of the library into the theme/plugin, instead of just the parts they need. Thus, the contents of the whole uploadify.zip file are frequently to be found in something like a theme, as is.
Take the Pronto theme, for example. It hasn’t contained uploadify for many versions, but when it did, it contained an exact copy of the uploadify.zip contents in an /uploadify folder. The version was 2.1.0, and the uploadify.php script contained therein basically allowed for arbitrary file uploading without any form of checking at all.
Now, obviously that file shouldn’t have been there in the first place, the theme author should have only included the necessary files. But including the whole of library content is a long-standing tradition amongst free-software developers, so ideally, it should have been secure to start with. And in later versions of uploadify’s zip, I see that it is indeed doing a file type check. But long-lived code is longer-lived than we often think.
If site-hackers are scanning specifically for it, then it’s not about placing blame anymore, it’s about notifying the users of the existing problem.
Why have you not actually made a lot of noise about this prior? This becomes a huge issue as it’s not all limited to an easy to define script as timthumb was. Awareness of these vulnerabilities is the first line of defense and if you’ve known they were unpatched for so long why no prior serious noise about them? Yes, there are brief mentions in your prior posts but they are easily overlooked for the meat of the post. I’m glad many security teams including yours however are finally raising the red flag.
I have also implemented uploadify but only for logged in users to use. Whilst no user can be typically trusted and therefore the proper implentation is key I agree that the user, in my case admin can be slightly more trusted not to upload dangerous files!
As a side note in case anyone was interested, whilst implementing a logged-in only version of uploadify in wordpress I came across the issue of cookies not being passed by uploadify/SWF Upload and have written about how to overcome this issue in a secure fashion here
Any recommend some alternatives?
I have been hacked and it appears to have been exploited in the Udesign theme via Uploadify… Another theme to watch out for.
I love Uploadify! Solid uploader. If you know what your doing and took Ronnie’s advice it can be secure. I created my own file upload class and deleted the one it came with. On another note, file uploading will never be 100% secure, the option of uploading is a risk in itself. I love how people put blame on something they really have no clue about.
Plus, if your downloading Plugins/Theme, DO YOUR RESEARCH! Plugins/Theme are developed by all level developers – beginners, intermediate, advanced, and experts. Chances are if you use one by the first two, it will have issues.
Great job Ronnie!
Comments are closed.