Category Archives: Security

TinyMCE TinyBrowser Plugin Vulnerability

After the FCKEditor vulnerability that was patched by Adobe a few weeks ago, it turns out that a plugin for TinyMCE is also exploitable for remote file uploads that could be used to gain malicious access to the server hosting your application.
The details of this particular exploit are posted at Milw0rm (  Keep in mind this only affects the TinyBrowser plugin and not TinyMCE, so if you just have a default TinyMCE without this plugin you should be ok.
That being said, some general security tips as usual:

  • Always upload outside the web root initially and perform additional checks on those files prior to making them web accessible.  If you cannot access a location outside the root of your site (shared hosting) have you hosting provider adjust permissions on a temporary folder in your web root to disallow those files from being served (by the web server) but can still be accessed by your application.
  • Keep any upload scripts behind an authentication scheme, whether it be HTTP authentication (a pop-up password box) or with something like cflogin.  Make sure you test that these files cannot be accessed without first being logged in, you make think “OK, you need to log in to the /admin/ directory” but, can you still access /admin/tinymce/, etc. without logging in?
  • Use secure passwords.  I can’t say this enough, I’ve seen MANY applications where the administrator is admin/admin or admin/admin123, which are the first things that an attacker (more likely their scripts and software) are going to attempt.  I have seen a bit of a surge in brute force attempts on admin login screens recently – many of them successful because the passwords were woefully insecure.
  • Define a password policy.  Set things like password length and complexity as part of the business logic of your application and use regular expressions to enforce them.  Another good idea, is to log every login failure (keep things like CGI.QUERY_STRING and CGI.REMOTE_ADDR so you know where these request are coming from).  If you want to go a step ahead of simple logging, send alerts on each password failure with the same information.  You could even keep track of failed logins and lock the user for a period of time after x failed log in attempts.  While these things may add a bit of time and complexity to your development cycles they could very well save you hundreds of thousands of dollars and man-hours in the future.


Recent ColdFusion Vulnerabilities Follow-Up

For about three weeks now, ColdFusion servers have been under attack making use of one of two exploits, one in older versions of an application written in ColdFusion and some through the built in FCKEditor.  Both of these issues have an active fix and should be handled with the utmost priority.
When Adobe initially shipped ColdFusion 8.0 it included the FCKEditor, which was enabled when using <cftextarea richtext=”true”>.  In version 8.0, the built in FCKEditor file manager and uploader were disabled.  While there was a post about enabling them, most developers didn’t use these features much, either because they would rather handle file uploads separately.  However, when the upgrade to 8.0.1 was released, Adobe enabled file uploads by default on the FCKEditor instance.
It was determined that an attacker could access the upload files directly and by using some form of spoofing, get files uploaded to the server that could potentially allow compromise of Windows security.
To correct this, there are two fixes.  The first is simply to edit the config.cfm file at CFIDEscriptsajaxFCKeditoreditorfilemanagerconnectorscfm to disable uploads [see].  Also, Adobe released a security patch for this issue and is a very high level patch that should be applied to your servers [link].
As I mentioned in my last post, users who were running older versions of CFWebstore could also be vulnerable due to a few upload scripts that are accessible directly and can be susceptible to file spoofing.  It’s important to note that CFWebstore responding very quickly providing a temporary fix to prevent access to the upload files.  They also released a more detailed description of what exactly was happening to servers which was compiled from many user’s experiences described on their mailing list.
Staying on Top of Things
So how can you stay on top of these sort of issues in the future?  My first recommendation is to subscribe to as many ColdFusion related blogs as possible, at least start with the feed.  Second, join any related forums or mailing lists related to any applications you are running.  Third, try to keep your software as up-to-date as possible, the longer software is in the wild, to more likely someone with lots of time on their hands has found some way of exploiting even the smallest hole to create a very large hassle for you.  Lastly, keep an eye on SANS Internet Storm Center which posts up and coming vulnerabilities that are being learned of and patched, this includes everything from Apple products, web applications, and Windows issues.
Additional Resources


CFWebstore File Upload Vulnerability

NOTE: Please read my follow-up to this and the recent FCKEditor issues affecting ColdFusion, also if you’re using TinyMCE with the TinyBrowser plugin read this post as well.
There has been a recent outbreak of attacks on servers running the ColdFusion shopping cart CFWebstore, that is allowing the attackers to upload a ColdFusion variant of the C99 shell script. This is giving them full access to your server and it will get compromised if they get that file up there.
Here’s what they do:

  1. Using the /customtags/uploadfile.cfm page, they are spoofing the MIME type to upload index.cfm and image.cfm to /images/accounts directory – these are their web shells (think of them like control panels).
  2. After having these web shells uploaded, things can go one of several ways:
    1. If you have cfexecute/cfregistry disabled, they will likely just inject JavaScript into every site on your server
    2. If you have cfexecute/cfregistry enabled, they will likely attack you with wminotify, this allows them to log and send back home all passwords used to log into the server for remote administration. At this point, you should probably plan to build a new server because this level of compromise is pretty deep and you likely won’t clean it all up.
    3. If you had cfexecute/cfregistry disabled and Sandbox security on each site, then only the CFWebstore site that was attacked will be injected with JavaScript.

So, you’ve been attacked, cleaned things up/rebuilt a server or two, what now? According to the folks at CFWebstore, you need to modify the application.cfm file for your store with this code from their blog. EDIT: More detailed information from CFWebstore. Use the link, not posting it incase something is changed in it. Also, I would suggest upgrading to the newest version as fast as possible for your budget and resources, since version 6, according to CFWebstore, certain upload files in the customtags directory are no longer used and are removed from the code base.
Additional details about the attack:

  • The shell contains many references to seraph, this is likely his/their blog in China
  • It looks like one of seraph’s buddies, chanm is actually doing the attack as I’ve seen Windows users created with the name of chanm$.
  • More info about wminotify.dll from Symantec
  • Read through the comments on Ray Camden’s post about this issue which includes many details from various people’s experience with this attack
  • The attacker is sometimes uploading a JSP file to get around the security layer in ColdFusion, which allows complete bypass of any Sandboxes you already had setup

While this is a specific attack on one application, the lessons learned can be applied to any web application:

  • DO NOT blindly trust the MIME types that are sent by a browser, these are easily spoofed.
  • DO upload outside you web root initially
  • DO additional checks on uploaded files before pushing them live (file extensions should match, use functions like isImageFile() and isPDFFile() in ColdFusion, etc.)
  • DO protect uploads with some sort of login (assuming your business rules preclude the public uploading content to your site)
  • DO disable JSP handling in ColdFusion if you don’t use it, see Adobe instructions.

Edit: Its been a long 2 weeks dealing with these, if I’ve missed something, let me know in the comments.
Last Update: 2 July 2009 12:40 PM

Spoofing MIME Types with ColdFusion and CFHTTP

Think your file uploads are secure? Think again. Using this very simple technique with ColdFusion installed locally, you can easily spoof the MIME type of any file and get it uploaded to another server, allowing any number of code exploits.
First, we’re going to write a quick file upload script:

<cfform name='upload' action='uploadact.cfm' enctype='multipart/form-data' method='post'>
<cfinput type='file'
message='Select a file to upload.' /><br />
value='Upload File'
name='submit' />

Notice this goes to an action page called uploadact.cfm which only accepts jpegs and gifs, this form actually handles the upload as follows:

<cfif isDefined('fileUpload')>
destination='C:path to upload'
<p>Thankyou, your file has been uploaded.</p>
<p><a href='/'>Return Home</a></p>

Now for the fun part, we’re going to write a page using cfhttp that would run on the attackers server/workstation that allows for files local to them to be uploaded by faking the MIME type with cfhttpparam:

value='Upload File'
file='C:PathTo	est.cfm'

Now with this we could upload an ASP or ColdFusion based web shell that would essentially give us unlimited access to a server.  So follow the following tips:

  1. If you have an Enterprise license, use Sandbox Security.  This will limit each site to its own set of directories and data sources.
  2. Disable cfexecute and cfregistry.  If you can use Sandboxes, do this for each Sandbox, or setup a global Sandbox on your main site’s directory.  Remember with Sandboxes, if you absolutly need cfexecute, remember that you can setup a Sandbox for a single folder with access to it and put processing files in here (say to use FFMPEG for videos conversion).
  3. Disable JSP (Adobe Instructions) if you don’t actually use it.  Since the default for ColdFusion is to run as System on Windows, any JSP file that makes its way to the server will have full access, and JSP’s don’t follow Sandboxes, so even if they are setup they are of no use.
  4. Run ColdFusion as another user (Adobe Instructions).  Obviously, running ColdFusion as a less privileged user will prevent total control of your server should something malicious get uploaded
  5. Always perform multiple checks on your file uploads (Pete Freitag has a good article on this)

Jason Dean’s Security Series

Jason over at has been writing a really great series of articles about secure application development for quite some time.  Since I haven’t seen them all in one index, I threw up links to all the articles on this page.

I’m pretty sure I got them all from Jason’s site, but if I did just let me know in a comment.