I had heard a few rumblings of this recently but had not really paid it much attention. Mike emailed me today and described how he was hacked pretty badly by it. I'll share his email and then add some notes to the end.
Nice (and by nice I mean it in the snarky, oh crap, why can't people be nice version). So, I strongly encourage folks to read both of the linked too articles above. They nicely describe the issue as well as talk about solutions. I'll add to Peter's post that you can sniff a file for being a valid image by using the new isImageFile(). Ditto for isPDFFile(). Of course, if you are working with something besides images and PDFs then you will need to use another mechanism. I especially like the suggestion of pushing static files to something like Amazon S3. Not only does this help reduce your security risk, but it also means you don't have to worry about drive space (as long as you can afford it of course). I decided not to post the code of the attack script. I don't think it's a risk to post it - I mean, it's not the code that's bad but the fact that someone uploaded it and used it to attack, but I'll err on the side of paranoia here and just not post it. (Although I did not that the hacker didn't properly var scope. Tsk Tsk.) I think every software project contains red flags - things that you must have but have (potentially) negative side effects in terms of performance and security. Certainly any file upload ability should be considered a red flag and should be documented/reviewed/checked to ensure it can't be abused.Over the last week we have had 3 Coldfusion servers hit by a hacker who is uploading .cfm files using upload form fields that are set to accept only images.
As a long-term Coldfusion user, I never knew that it is possible to spoof Coldfusion into uploading executable (.cfm) files when it was set to only allow images. This post by Brent Fry explains more: http://www.cfexecute.com/post.cfm/spoofing-mime-types-with-coldfusion-and-cfhttp
This has major implications for any web site that allows users to upload images (like dating sites or community sites). You MUST take precautions like adding code to verity the mime type after an upload as discussed by Peter Freitag in this post: http://www.petefreitag.com/item/701.cfm
In our case, the hacker was able to upload an index.cfm file that provided them with COMPLETE control of our server (I'll send you the hackers page if you'd like -- it is truly impressive). They were able to install trojans that, among other things, would email China with our username and password every time we logged onto the server.
We could not find a scanning program that could identify and remove these trojans. All the Google search results about it were in Chinese. Our servers were so thoroughly compromised that we had no choice but to completely rebuild them.
I am hoping that you can warn others about this issue. I am not aware of any information from Adobe about this, and I have heard very little on the blogs. I'm surprised because I know of MANY other sites who have experienced the same attacked over the past week.
I'm hoping that people can learn from our experience and protect themselves now. I have no doubt that this will become a much more common attack in the very near future. The message is clear: if people are able to use an upload file form field on your web site, you too may be vulnerable.

Comment 1 written by Jason Brookins on 30 June 2009, at 11:16 AM
Comment 2 written by Pete Freitag on 30 June 2009, at 11:17 AM
Comment 3 written by Jules Gravinese on 30 June 2009, at 11:20 AM
Comment 4 written by Sid Wing on 30 June 2009, at 11:25 AM
Comment 5 written by Chad on 30 June 2009, at 11:25 AM
Comment 6 written by Chad on 30 June 2009, at 11:29 AM
IE. http://foo.com/imageUPloads/uploadedFile.cfm
The CFM file runs and they can do what ever they want.
Comment 7 written by Pete Freitag on 30 June 2009, at 11:40 AM
Comment 8 written by Jules Gravinese on 30 June 2009, at 11:51 AM
And if a file manager is in use, make sure files cannot be renamed with as anything.cfm?
Comment 9 written by Joshua Cyr on 30 June 2009, at 12:14 PM
As for what it does beyond just the basics... it creates a web service, uploads executables, and reinfects periodically. I hadn't heard about the login recording, but not a surprise. This is what I got from one web host.
--
The Windows service name appeared to be randomized. I believe it started with a “w”, though. That’s probably to ensure that it ended up at the bottom of the list. The service pointed to the following file:
C:\windows\system32\wjqpoo.kll
The older version of Computer Associates eTrust which had been on the server did not catch it, but ESET anti-virus did. It identified it as “Win32/PcClient.NEF”. Unfortunately, the ESET site doesn’t provide much information about this threat. It appears to be a back door Trojan. This write-up on Symantec’s site seems to describe a similar variant:
http://www.symantec.com/security_response/writeup....
It appeared to poll a remote host periodically. It received a binary from the remote host which it downloaded to the Windows temp folder. The binary had a random name which appeared to be a signed integer. The service would then execute the binary. The binary deleted all Web log files, disabled logging on the Web sites, and appended the malicious JavaScript to the bottom of HTML and JS pages.
Comment 10 written by Tom Mollerus on 30 June 2009, at 2:16 PM
If you need to serve the file back to the user somehow, then just deliver it via CFCONTENT to make sure that it's not executed on the server.
Comment 11 written by tony petruzzi on 30 June 2009, at 2:54 PM
Comment 12 written by Joshua Cyr on 30 June 2009, at 2:56 PM
Comment 13 written by Raymond Camden on 30 June 2009, at 2:56 PM
Comment 14 written by papichulo on 30 June 2009, at 2:59 PM
Comment 15 written by tony petruzzi on 30 June 2009, at 3:03 PM
so you're saying that Adobe shouldn't address this?
Comment 16 written by Raymond Camden on 30 June 2009, at 3:06 PM
That being said, a security note on the Adobe site wouldn't hurt. But again, this is not their responsibility.
Comment 17 written by Tony Petruzzi on 30 June 2009, at 3:31 PM
for the sake of argument, i'll give in and say that you're right: it's not an adobe issue, a security hole or a bug.
that out of the way.
you can't tell me it wouldn't make sense for adobe to write a patch or issue a hotfix that checks that the mimetype of an uploaded file conforms to the specified mimetype(s) listed in the accept attribute after it has been written to the server.
Comment 18 written by Raymond Camden on 30 June 2009, at 3:33 PM
Comment 19 written by tony petruzzi on 30 June 2009, at 3:39 PM
this post has some information on getting the mimetype of file that has been written to the server.
Comment 20 written by Pete Freitag on 30 June 2009, at 3:40 PM
Most web servers have a huge list of mime-type to file extension mappings, it would be possible to create such a list and put it in a config file, and throw an exception if the uploaded file extension is not corresponding to the mime-type mappings. But at that point you might as well just add an attribute for allowed file extensions.
Comment 21 written by Pete Freitag on 30 June 2009, at 4:06 PM
There isn't anything in particular that would make a hosting company more at risk for this attack, except perhaps hosting companies that force you to upload into the web root. And those that don't allow file uploads would not be at risk.
Comment 22 written by papichulo on 30 June 2009, at 4:30 PM
Comment 23 written by Christopher on 30 June 2009, at 5:28 PM
How was ColdFusion executing the .cfm file that was being uploaded? Was it being uploaded directly to a folder the user could instantly access and execute? Or are you saying somehow ColdFusion invoked the uploaded .cfm file itself?
Because if Mike was uploading directly to a user-accessible folder, this exploit is certainly not news.
Comment 24 written by Brent Frye on 30 June 2009, at 6:13 PM
Comment 25 written by Brent Frye on 30 June 2009, at 6:20 PM
The cffile accept argument implicitly trusts the MIME types sent by the browser, so having image/jpeg in there, the attacker would simply send a .cfm file to the action page, but say its a jpeg with the MIME type. In this application, it directly uploads to an images folder, obviously not the best option - as you'd want to upload somewhere not accessible on the web and then perform additional checks on the file before moving it somewhere publicly accessible.
Comment 26 written by Christopher on 30 June 2009, at 6:31 PM
So, this is a case of uploading to a public directory. I thought someone found a way to upload a .cfm file and have the server execute the file, no matter where it was stored.
I crapped myself for nothing.
I was always under the impression that filtering out file types on the browser side was like validating form input with JavaScript, it's more for the user than for security.
That said, I don't bother with client-side restrictions.
Comment 27 written by Brent Frye on 30 June 2009, at 6:41 PM
Yeah - if you already upload outside of the web root and take extra precautions to validate those files prior to making them public you should be fine. As has been stated, this is the client side telling the server that its uploading something it isn't. When its public - that allows the attacker to execute the code like it were any other cfm file on the server. In this case, look up the C99 php web shell - they are using essentially the same thing, only written in ColdFusion.
Comment 28 written by Steve Glachan on 30 June 2009, at 7:25 PM
I've been trying to read through this while at work so forgive me if this has already been brought up but, is this exclusive to CF? All the comments seem CF related so just wondering if this is specific or experienced across the board with Java, PHP, .NET, etc.?
Comment 29 written by Brent Frye on 30 June 2009, at 8:17 PM
This could likely be exploited in any language if all you trust for uploads is the MIME type provided by the user and automatically upload to a publicly accessible location. There are web shells written in just about every language (Perl, .Net, PHP, CF, and classic ASP), so most of the discussion is applicable to any language used for web applications where the public can freely upload files.
Comment 30 written by tony petruzzi on 30 June 2009, at 8:35 PM
http://gist.github.com/138542
if anything, if you can look over the code and tell me what i'm missing, i would appreciate it. i want to implement this into all my sites tomorrow.
Comment 31 written by John Whish on 1 July 2009, at 5:20 AM
Something like:
<cffile action="upload" .../>
<cfif ListFindNoCase( "jpg,png,gif,jpeg", cffile.serverfileext ) EQ 0>
<!--- delete the file --->
<cfelse>
<!--- file has an expected extension so carry on --->
</cfif>
Comment 32 written by Joseph Lamoree on 1 July 2009, at 6:23 AM
find . -name '*.cfm' -exec grep -Hoi -E '<cffile.*action="upload".*>' {} \;
I might write something more sophisticated, but that does the trick for now.
-joseph
Comment 33 written by Sammy Larbi on 1 July 2009, at 6:42 AM
If you shared the uploaded file, we could at least write a program that would scan our drives for similar ones, to know if we've been compromised and then decide to rebuild the servers.
If not the whole thing, could you specify some things to look for? Rarely used tags that could be scanned for and examined by hand might be useful, for instance.
Comment 34 written by The Innocent on 1 July 2009, at 7:17 AM
http://www.coldfusion.tv/viewVideo.cfm?videoID=100...
Comment 35 written by Jules Gravinese on 1 July 2009, at 7:31 AM
That script looks very familiar. I had to clean that off of a server recently. It was used by EL_MuHaMMeD:
http://www.zone-h.org/archive/defacer=EL_MuHaMMeD
Comment 36 written by Matt Osbun on 1 July 2009, at 7:57 AM
Not exactly the same thing, but this issue is a lot like putting a hand grenade in a vase simply because it was delivered by FTD.
Comment 37 written by DanaK on 1 July 2009, at 9:18 AM
Hopefully posts like this makes it's rounds enough for people to be aware and protect themselves!
Comment 38 written by Wil Genovese on 1 July 2009, at 9:30 AM
Good catch on this and it is always the right time to raise a security concern.
Comment 39 written by Pete Freitag on 1 July 2009, at 10:05 AM
@Wil Genovese - No it certainly is not new, I've been talking about this issue for a long time, I never blogged it until recently unfortunately. I have always found that whenever I talk about this issue, about half of the room has to run and fix their code. So this issue is one that we all need to be vocal about as frequently as possible (just like cfqueryparam, yay!).
Comment 40 written by Raymond Camden on 1 July 2009, at 10:08 AM
Comment 41 written by Pete Freitag on 1 July 2009, at 10:16 AM
Comment 42 written by Raymond Camden on 1 July 2009, at 10:19 AM
Comment 43 written by Brett on 1 July 2009, at 10:19 AM
one preventative measure is to run ColdFusion under a user with limited permissions instead of running the service as local system.
Most of the hack (on our particular server) appears to be specific to Windows IIS servers. Some distinguishing features of the hack .cfm file are:
- the name seraph
- references to cmd.exe, adsutil.vbs, MetaBase.xml, cscript.exe
- comments that show up as question marks or gibberish in a text editor (but may be a foreign language)
Other signs of this particular hack:
- Unknown virtual directory (particularly in IIS default web site)
- Registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\wminotify (records server admin passwords)
- Unknown service which is difficult to disable
- Executables (.exe) in C:\windows\temp
- IIS logs deleted and disabled
- Script tag added to html, htm, asp, js, and application.cfm files
Comment 44 written by Pete Freitag on 1 July 2009, at 10:43 AM
@Ray - Sure, lets schedule it for Monday sometime.
Comment 45 written by Mike on 1 July 2009, at 10:56 AM
I'm sure the hackers (based in China) crawled all the HMS IP addresses looking for Coldfusion sites to hit. This attack may be clustered around HMS at this time, but I am sure it will spread over time.
Comment 46 written by Jules Gravinese on 1 July 2009, at 11:42 AM
Sometimes they do a google search. For instance, "cffm.cfm" to find that particular CF file manager. Then test if it's open. Then test uploading a file, etc etc.
I found that out by looking at the logs around the time EL_MuHaMMeD stopped by. I was able to retrace his every step, watching how he wiggled his way deeper and deeper:
(referring to log line numbers to my client)
(2) It looks like this hacker used our file manager to get a file 'tmpfiles.gif.cfm' onto the server. The file manager is locked so that you can only upload files into the /media/ folder or below. But what this guy did was upload a CFM which is its own file manager.
(4) He accessed that uploaded CFM as a regular web page.
(6-13) He's looking around for a safe place to upload/hide another hack file manager.
(14) He uploads another file manager
(16-21) He deletes the original hack file manager.
(33) He checks to see if he can run PHP code as well. But cannot.
(58) He uploads the defaced home page.
(59) And tests it.
(60) And deletes the real home page.
(61-73) He looks for other weaknesses, finds none, and leaves.
Comment 47 written by Hazen on 1 July 2009, at 11:50 AM
Should this entry be removed and if so is the entire Notify Entry to be removed? or some entries contained with in??? I guess I am asking because we have have had an attack on another server, but just this week recommissioned a new server, and started serving sites again from the new box. I want to be sure that the new box stays safe,(as much as is possible), and so I have checked for this registry and YES, Notify is in the Reg. So what's to be done?
Thanks,
Comment 48 written by Paul on 1 July 2009, at 9:15 PM
What we're seeing is essentially every web file (.htm(l),.cfm,.php,.js, etc) being appended with a script code trying to load a swf from "chanm.3322.org/flash/".
We scrubbed all of these files with a massive search and replace and then they just got reinfected again.
We're trying to find the source that is running this attack automatically, but we're having difficulties finding it. Any tips/ideas on how to isolate the malicious program thats causing this and get our servers back online??
Thanks!
Paul
Comment 49 written by Jules Gravinese on 1 July 2009, at 9:40 PM
Comment 50 written by John P on 2 July 2009, at 9:16 AM
Comment 51 written by Jeff Hubbach on 2 July 2009, at 2:56 PM
Comment 52 written by Raymond Camden on 2 July 2009, at 3:02 PM
Comment 53 written by CC on 2 July 2009, at 3:44 PM
http://isc.sans.org/diary.html?storyid=6715
Comment 54 written by Raymond Camden on 2 July 2009, at 9:27 PM
Comment 55 written by barry.b on 4 July 2009, at 9:36 AM
not you're fault, Ray, that "not really paid it much attention" ... where was the flashing red lights from Adobe? Where was the official word so you could pick it up and blog/retweet?
sure it involves a 3rd party product. I'm just shocked that it's a case of the tail (community) wagging the dog (Adobe's psirt).
In the Enterprise space, we're quite happy to pay for CF licencing even when it includes 3rd party products, because they've been tested by Adobe and have their seal of approval on them. But this is an on-going things, not "just a forget it after it's released" - that means being tightly plugged into the 3rd party products and hearing of any issues to see if it has an impact on their use in CF.
how to kill a platform in the Enterprise space - be really sloppy with security responses...
my 2c.
Comment 56 written by Jon Cavanaugh on 5 August 2009, at 12:23 PM
Edit jvm.config file and add the JVM argument “–Dcoldfusion.fckupload=true”
I have verfied that the "update" hf800-77218.jar was active and that the default JVM was being used for ColdFusion. Anyone else try enabling the upload and run into this problem?
Thanks for any help,
Jon C.
[Add Comment] [Subscribe to Comments]