Process "911.exe" in folder "coldfusion\SERVER-INF\temp\wwwroot-tmp"

[rici2002]

Hi All,

Our couldfusion application stopped working a few times last week due to the process "911.exe" which costed 99% CPU. Once we kill that process, everything back to normal again. The problem is process "911.exe" should be in C: root, but we found it in "ColdFusion8\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\neotmp56746.tmp" and been recognized as a virus. We kill it, it will appear again and again. Does anyone have the similar problem? How can I fix it?

I think this folder "temp\wwwroot-tmp" is used to store chached files, uploaded files. Does that mean someone uploaded some files with the virus?

Thanks in advance.

Wei

[Guest]

I had the same problem. I also received the following viruses:

zz.exe

zzz.exe

winacp.exe

911.exe

The only solution I've found is to install antivirus "Sophos", here's the link:

(It is compatible with Windows Server)

http://www.filecluster.com/downloads/Sophos-Anti-Virus.html

You install it as usual.

The antivirus will ask the user's name and password of the administrator.

Then you need to find the latest virus updates, is in the following link:

http://www.sophos.com/downloads/ide/

You select the ZIP version updates. Then you have to manually unzip in the folder anitivus "Sophos":

c:\Program Files (x86)\Sophos\Sophos Anti-virus

Then you realize overall scanning. The antivirus will protect the windows against possible virus entry suspects.

(Sorry for the bad English).

[rici2002]

I think we already installed sophos. We will update sophos to the latest version and run the scan again.

[efirkey]

I too have been hit by this.

zz.exe

zzz.exe

winacp.exe

911.exe

all in C:\

I installed Norton Symantec and the only item that keeps coming up is 911.exe at random times.  I believe it to be sending out emails because when it pops up Norton is killing it and also killing my POP3 program mepops.exe (mailenable).  Norton was also killing coldfusion executables but I updated and patched coldfusion to version 9.02 and secured the CFIDE directories and it hasn't killed coldfusion since.

I am very close to creating a whole new server if there isn't a solution to totally eradicate this soon.

My gut feeling is that this was caused by some weakness in coldfusion.

Is symantec aware of this situation?

Eric Firkey  www on-queue dot com

[Guest]

Hi,

The antiviurs "Sophos" detect any possible viruses zz.exe 911.exe and family, etc.

Sophos does not destroy any service process as coldfusion, mdaemon, etc.

Sophos controls infection by detecting the virus in the coldfusion temporal zone and destroying it.

Possibly be resolved with an update, but I do not know if 9.0.1 and 9.0.2 updates resolve it.

[Guest]

I think it is a worm that filters through port 443.

I ran the file at ThreatReport.com

http://www.threatexpert.com/report.aspx?md5=02c8e8bf1cd56d95667ee870e4b14f1b

and

http://www.threatexpert.com/report.aspx?md5=6afb7109b50c86fe598c38e6ad73181e

Sophos online scanner detected this:

2013-03-11 11:28:06 The following items will be cleaned up:

2013-03-11 11:28:06 Troj/Agent-AAPB

2013-03-11 11:28:06 Mal/IRCBot-A

[Steve Sommers]

Yes, you should have an AV running on your server but I don't think the executables mentioned here in this thread are the actual problem -- instead, they are the symptoms of an un-patched ColdFusion server. Your server is the victim of an unauthorized upload of an .exe and its execution.

There is a thread somewhere that describes remapping the CFIDE directory to an empty directory and then creating a "scripts" virtual directory under it the points back to the CFIDE/scripts directory. I highly recommend doing this whether or not you patch to the latest and this will plug your immediate vulnerability hole. Good luck.

[rici2002]

Hi Steve,

You know where we can find the thread?

[Steve Sommers]

I attempted to find the thread yesterday but my searches returned too many results. I guess it's a hot topic. Anyway, what we do is:

First, create an empty folder on your server. It does not matter the name, but I call it something like CFIDE_faux.

For all sites bound to external IP addresses (all but localhost/127.0.0.1):

1. Delete the CFIDE virtual directory from the site.
2. Create a CFIDE virtual directory and point it to the empty directory you created above.
3. Under this virtual directory, create another virtual directory called scripts. Point this virtual directory to the original CF CFIDE\scripts directory.
4. Now you have a CFIDE directory with only a scripts directory -- no admin and others.

An alternative to the double virtual directory is to copy the scripts directory to the empty CFIDE directory you created. The disadvantage to this is that CF patches will not be applied to the copy whereas they will be applied using the double virtual directory method.

Another option I found in my research yesterday but have not tried myself is to delete CFIDE virtual directory, then create a virtual directory for /CFIDE/scripts, again pointed to the original CF scripts directory. This "supposedly" leaves the CFIDE directory as a 404. Sounds like it might work, but I have not tried it.

If you look at the history of CF vulnerabilities, most revolve around the exposure or the complete CFIDE directory tree. Why Adobe does not hidden the CFIDE tree by default and only publish the scripts directory is beyond me. All the patches and hot fixes to the CFIDE seem like bandages on a broken leg.

Hope this helps.

[pkonshak]

I restricted access to my /CFIDE directory by IP range.  From an outside address, it gives a 403-Forbidden error.  However, the 911.exe and other files were dropped into my c:\ directory.  Is this consistent with what others have seen? 

[Steve Sommers]

Yoou restricted access to the entire CFIDE tree, or just the CFIDE directory. Also, was this via the CF administrator or at the web server/OS level?

My understanding is that there have been a few vulnerabilities where unauthorized uploads and execution could occur. Another thing to check is if you have an older version of fckeditor installed. It also had a similar unauthorized upload vulnerability.

[pkonshak]

Steve, I mis-spoke.  I only restricted access to the CFIDE/administrator directory (via IIS).  So, your tip above is something I need to look into.  Thanks!

[david_mcknight]

I am in the same boat too...

Can someone clarify is this a bug/vulnerability in CF9 all versions all patches or just up to a certain patch level?

Is putting IP restrictions on the CDIFE directory a valid solution to prevent future infections?

[Steve Sommers]

david_mcknight wrote:

...Is putting IP restrictions on the CDIFE directory a valid solution to prevent future infections?

If you mean through the CF Administrator option, no -- especially if you are not up to the latest patch level but even then I would still say no.

I guess it's possible at the web server/OS level, but that would be more work than the method I described above.

[david_mcknight]

Steve Sommers wrote:

I guess it's possible at the web server/OS level, but that would be more work than the method I described above.

Right, so in IIS I set an IP restriction to my local subnet on the CFIDE folder and all subfolders.  The theory being that IIS should not allow access to any files in those folders, there by not allowing any coldfusion code to run from files in that directory tree, unless you are here on site.

Is there any test I can do to see if I have properly plugged this hole?

[Steve Sommers]

Just remember that several client side CF features (CFForm field validation for example) requires access to /CFIDE/scripts so you'll need to remove the IP restriction on this directory -- unless you don't use CFFORM, CFGRID, others.

[david_mcknight]

Steve Sommers wrote:

Just remember that several client side CF features (CFForm field validation for example) requires access to /CFIDE/scripts so you'll need to remove the IP restriction on this directory -- unless you don't use CFFORM, CFGRID, others.

I see, now your previous post make sense.

Thanks.

[rici2002]

Hi efirkey,

I feel this is coldfusion server issue. Still googleing if there are any hotfix we can use.

[DaCFMastered]

We have seen this as well on our CF9 servers running Server 2008.  The files seem to reappear about once a week and cause a tremendous amount of network load.  That being said, I have run Sofos on the server, deleted every instance of the files (which always reside at the system root) and stopped the services.  We're currently patching our CF instances to the latest patch and we'll see if that corrects the issue.

[Guest]

Do you have any scheduled tasks or cfm files which are not from your application. Anything which is unwanted.