Posted in ColdFusion | Posted on 06-30-2009 | 11,051 views
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.
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.
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.


IE. http://foo.com/imageUPloads/uploadedFile.cfm
The CFM file runs and they can do what ever they want.
And if a file manager is in use, make sure files cannot be renamed with as anything.cfm?
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.
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.
so you're saying that Adobe shouldn't address this?
That being said, a security note on the Adobe site wouldn't hurt. But again, this is not their responsibility.
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.
this post has some information on getting the mimetype of file that has been written to the server.
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.
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.
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.
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.
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.
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.
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.?
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.
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.
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>
find . -name '*.cfm' -exec grep -Hoi -E '<cffile.*action="upload".*>' {} \;
I might write something more sophisticated, but that does the trick for now.
-joseph
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.
http://www.coldfusion.tv/viewVideo.cfm?videoID=100...
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
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.
Hopefully posts like this makes it's rounds enough for people to be aware and protect themselves!
Good catch on this and it is always the right time to raise a security concern.
@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!).
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
@Ray - Sure, lets schedule it for Monday sometime.
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.
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.
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,
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
http://isc.sans.org/diary.html?storyid=6715
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.
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.
Is that true Script/Executable trun off?
I'm Turkish Hacker....
Raymond :P
[Add Comment] [Subscribe to Comments]