Malware alert in the coldfusion installation path - [Threat: Backdoor:PHP/Dirtelt]

@Karthikeyan.K, it's been a week now. Your problem seemed urgent, but you've not replied. 

Is it resolved, perhaps? If so, what was the solution? If not, did the considerations from bkbk or from me help, or not? 

@Karthikeyan.K , I think your vulnerability assessment tool has done a good job. Those .TMP files do indeed look suspicious. To me there are three signals that make the threat serious.

Firstly, the threat Backdoor:PHP/Dirtelt suggests a PHP backdoor attempt. Why PHP on a ColdFusion server? ColdFusion runs CFML, not PHP by default. That is suspicious.

Secondly, when you install ColdFusion, there should normally be no .TMP files in the directory COLDFUSION2021\cfusion\runtime\work\Catalina\localhost\tmp\. As Charlie mentioned, this directory is used when your application uploads a file. Even then, the upload process uses the directory only temporarily (hence the extension "tmp"), deleting the .TMP files afterwards.

Thirdly, something else raises the threat level. It is the fact that your tool flags coldfusion.exe itself as suspicious. This suggests a link between coldfusion.exe and the .TMP files.

If we put the three signals together, they imply that, possibly, an attacker could have planted one or more PHP files to serve as:

• A webshell/backdoor uploaded via a file upload vulnerability in your application.
• A side-door attack where the attacker plants a PHP script to bypass ColdFusion security.
• A server compromise allowing attackers to drop arbitrary files into your server.

How it could have happened:

• An attacker exploiting an unpatched vulnerability in Adobe ColdFusion.
• A user abusing file upload features that don’t properly restrict extensions.
• An attacker leveraging misconfigured webroots that serve multiple languages (for example., a PHP interpreter installed on same server as ColdFusion).
• An attacker dropping a backdoor into your public web directories so they can execute it over HTTP.
• You using an already compromised or infected installer at the very beginning to install ColdFusion.

What to do:

1. Check the log files. Look out for and note down any: unusual POST requests, IP addresses or domains that you don’t recognize.
2. Look out for and note down any suspicious files (CFM or PHP) or directories under the web root (wwwroot). If the attacker had access to plant PHP, they may also have planted CFML webshell lookalikes for /CFIDE/administrator/index.cfm, such as cfphpexec.cfm, phpindex.cfm or cfexec.cfm. These can be even more dangerous because they will run natively under ColdFusion without triggering PHP antivirus signatures.
   
3. Copy the the flagged .TMP files to a location outside ColdFusion (for further investigation later). Then delete the files from the directory COLDFUSION2021\cfusion\runtime\work\Catalina\localhost\tmp\, restart ColdFusion and run the vulnerability scanner once again.
4. If you installed PHP for legitimate purposes, but it is unused, then uninstall it or disable its handler in the web server.
5. If necessary and if feasible, uninstall and then re-install ColdFusion, using an installer from a reputable source. Then update ColdFusion to the latest security patch level.

Karthik, it's understandable that anyone seeing this would be tempted to panic. It's complicated whether you need to be concerned about this or not. Let me explain.

1) First, as for that folder and those files, many are unaware that if ANY CFM page is called as a form post that pushes ANY file to it (like with a form  with an input type="file", but this can be simulated with http headers directly), then CF will first STORE that uploaded file in that directory.  And note how the file name ends with .tmp. Nothing can RUN that file, and even if it has a virus in it, nothing can LEVERAGE or trip over it, at least as it exists in that file. I'll talk in a moment about how that file may (or may not) be caused to be moved OUT of that folder, in which case it MAY be something to be concerned about.

But note note that such a tmp file (created by such an upload to a cfm page) will be REMOVED when the request ends. Again, that means the file may be there momentarily (milliseconds or seconds), but it would then be removed. In fact, if you look now at such folders, you may find the file you refer to is not there....but someone may argue "it was our security protection mechanism that removed it", and that may be so. I'm just saying that ANYONE even WITHOUT such a tool should find that the tmp files don't remain long.

2) So someone would reasonabley ask "so how do they get OUT of that folder to be used legitimately by CF?" That's where the cffile action="upload" comes into play; if a CF page is EXPECTING to have files uploaded to it (like via a form with an input type="file"), then THAT cf page would use that cffile action="upload" with a DESTINATION attribute naming a folder used by the app, which tells CF to MOVE that .tmp file (just uploaded) into that named folder. That process ALSO renames the file to whatever name and extension it was when uploaded (from this neotmp*.tmp name). Again, in the end, the .tmp file itself would no longer be there in that tmp folder.

And to be clear, if a cfm page gets a file uploaded to it but does NOT do that cffile action="upload", then the uploaded file is NOT processed by CF (at all) and again it's simply deleted at the end of the request.

3) But someone may argue, "ok, but what if the CF code DOES do a cffile action="upload". Won't that put the file with a virus somewhere?" Yes, it could.

We should note first that cffile action="upload" tag does itself offer attributes to control what CAN be uploaded. More than that, the CF Admin ALSO has various protection mechanisms built into processing of such uploads (but it doesn't "check for viruses"). These features can limit what file extensions are allowed--and also whether the kind of file uploaded matches the extension (and "mime type" indicated) for the file that was uploaded.  See the docs for more on that.

4) Now, if your code WOULD have just processed that uploaded file (with cffile action="upload") and WOULD have put it in some folder, then yes it's possible somehow a file with a virus could end up in your server (and perhaps even in a web accessible directory.)  To that point, some people have such uploaded files get moved (by their cf code) into a directory where then they perform some external a/v check, before putting it wherever it was ultimately intended to be placed.

5) But your tool is doing that checking BEFORE your CF code even might try to move the file out of that tmp folder. And I'm saying it may be that such uploaded files are not put there as part of an intentional process where a CF page WOULD have moved it out of there. Instead, those could just be uploads to a CF page which NEVER would have done anything with the file. And your mechanism is basically a dog howling at the moon (nothing to be worried about). 

But bottom line: there's virtually nothing you can do to PREVENT file uploads to CF (even if your code has no intention to ever DO anything with such uploads). But again if you do NOT do anything with them, they just are removed at the end of the request that received the upload. You should find that you don't have many of that neotmp*.tmp name in that directory , cfusion\runtime\work\Catalina\localhost\tmp.  

And even if somehow you do find them, and they go back hours days or weeks, it would be because the CF file to which the upload was pushed had died unexpectedly, so that CF did not do the end of request removal of the tmp file. Even so, again those tmp files there DO NOTHING. They CANNOT be "executed" in any way by CF, even if they "have a virus" in them. They are .tmp files. Nothing will execute them. You can just delete them and get on with life.

6) I realize that some will wish for a better answer to "prevent the uploads being possible in the first place, if we would NEVER have any need to handle such uploads to ANY cf files".

While CF has no feature to do that, I will say that your web server (IIS or Apache) may offer features to block such file uploads. It may even be possible to tweak Tomcat (which underlies CF) to prevent such file uploads. That just shows you that this ability of a file to receive a file upload (posting a file) to a server is not somehow unique to CF. Other languages and app servers support it as well.

What CF offers is whether and how to process that file once uploaded (see above), and it deletes the file if not used (see above). But your  a/v or security tool is possibly seeing the file in the moments that it's uploaded. That's why you either need to let it do its job (if its removing them) OR you need to explore how to tell your web server to NOT allow file uploads to CF at all. If you seek that, speak up and I or others may chime in.

7) I warned that this was not a simple problem with a simple answer. I hope the clarifications above are useful for you or others who may find this thread in the future.