zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228)

[Jdsplicer]

Does anyone know if the zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) that was announced on 12/9/2021 will affect ColdFusion version 10 and 2018?

[Charlie Arehart]

Yep, Dave. And FWIW, Pete's post does also recommend disabling egress (and mentions also how Java security policies or the CF Sandbox feature could help with that).

All that said, I will note that I have been trying and trying to cause the vuln in CF and have not yet been able to (even when I LITERALLY cflog the $strings identified in resources about it. I've tried many variants and hope to write up another message with more info).

In the meantime, if anyone might share any specific thing that they confirm DID prove the vulnerability within CF, please do share it. I realize some may think "that's crazy, don't publicize that", but I am for now not talking about a request that could be made from the outside. I mean just something that one would have to write CFML, in order to demonstrate the impact of the vuln being executed. 

[Dave Watts]

Those onboard egress blocking or filtering things are good. But the problem for me is, they tend not to get documented very well because they're done by the people who are managing that host, or even by the developers.

Right now, I have a client that has literally tens of thousands of undocumented rules, and no one in the entire organization can tell me what is or isn't supposed to be blocked. It turns out that the client may accidentally be blocking entire sections of the world from visiting an open, public, line-of-business site. This is ... frustrating, because now I can't even get them to agree about what should or shouldn't be blocked in the first place.

Dave Watts, Eidolon LLC

[Charlie Arehart]

Sure, Dave. But let's help readers with some clarity:

You referred in your previous comments to egress (OUTBOUND calls from CF, that might be caused by bad actors leveraging the vuln), and I was simply agreeing that Pete's blog post talked about additional ways to do that in CF. I agree that setting such egress protection (however) is not trivial--but some would either be able to say they need NO outbound calls or need only allow outbound calls to limited domains/IPs.

But then as for ingress (INCOMING calls) and trying to find potential "bad strings", I do agree 100% that it's nearly impossible to block all possible permutations and encodings (just as people find in trying to block sql injections and such). There are indeed many such variants being offered all over the IT world as "how to detect hack attempts" for this log4j vuln.

As I noted in another comment, I want to simply find even one (as a URL or as CFML one could write on their own machine) that would get passed to log4j by way of CF, to know if its at all possible for CF to be hacked this way. Anyone reading any of the discussions in all of IT (and even national news) would be under the impression that anyone with an affected log4j MUST be vulnerable. I'd like to prove it. 

Because as you say, trying to detect incoming attempts is hard, and anyone reading this thread can see that it's not clear what we can do to "fix" the problem (with CF changes, log4j lib changes, log4j config changes, etc.)  We will know better over time.

But for now, let's start with trying to come up with a way that confirms WHETHER any given CF implementation CAN demonstrate the vuln being exploited in a controlled, safe way. Then once we do, we can determine a) WHAT CF versions and configs are vulnerable, then b) WHAT fixes might "really work".

[Dave Watts]

Right, we're sort of talking about two different things here.

The thing I'm talking about is basically a standard step (in theory) for defense-in-depth. When a lot of these vulnerabilities are discovered, by having a block somewhere that's not on the specific server in question, I can be reasonably confident that I'll avoid specific things that the vulnerability could cause, and I can also be reasonably confident that I can easily manage and document these things without having to configure individual servers. That's just a general observation, not related to this specific vulnerability than to any other that can cause RCE with code that's not already on the server. And I followed up with what was to me a relevant issue I'm having where all the security stuff is host-based and 99% undocumented because it was done by whoever was managing the host at the time.

The thing you're talking about the CF-specific aspects of this vulnerability, which are potentially there but no one's been able to get a working exploit example.

I think both of these are very good and important, and people should be thinking about both of them. That's "how can I fix this issue now" but also "how can I mitigate issues in advance?"

Dave Watts, Eidolon LLC

[Charlie Arehart]

Yep, understood and agreed. Thx. 

[sdsinc_pmascari]

Charlie and Dave,

I don't post here often, but I read many of your posts and blogs.  Just wanted to send a 'thank you' your way for all the digging you're doing into this issue.  We don't have the resources at my shop to do the research you're doing and we very much appreciate your efforts and reporting.  Also, I, too, will endorse Pete Freitag and his work.  We subscribe to several of his products.

[Dave Watts]

You're welcome!

Dave Watts, Eidolon LLC

[Charlie Arehart]

Ditto. Thanks for the kind regards. 

[Peter Kulla]

Hello Experts,

can anybody tell, if ColdFusion uses log4j to write the regular CF-Logs (application.log, exception.log etc.)?

If it is the case, so there would be a simple attack possible: calling http://my.server.com/my_%24{java%3Aversion}_test.cfm would return 404, but log the path into exception.log

(at the moment it seems not to happen, but just to be sure...)

Peter

[BKBK]

Hi @Peter Kulla ,

Yes, as has been mentioned in the foregoing discussion, ColdFusion uses a version of Log4J Core that is vulnerable. It is known that the vulnerability affects Log4J versions between 2.10.x and 2.14.x. The current updates of ColdFusion 2018 and ColdFusion 2021 use log4j-core-2.13.3. Which you can verify by confirming the presence of the file /lib/log4j-core-2.13.3.jar in your ColdFusion installation.

I don't understand the reasoning behind your example, http://my.server.com/my_%24{java%3Aversion}_test.cfm. What has this URL got to do with the LDAP/JNDI vulnerability?

[NicoTexas]

We went ahead and patched "manually" our CF servers with log4j 2.15.0 on Friday morning by just replacing the 2.13.3 libraries in the cfusion lib directory.
Just to clarify the extent of the vulnerability, it is in all log4j version since 2.0. So, an easy way to verify if you are affected is to check if you have log4j-core 2.x jar file in your classpath.
We have seen through our monitoring some attempts to exploit this bug and our counter measures were effective, but I am glad we patched it anyway.

I am shocked there is not already a patch available from Adobe. This is really something they should have released already...

[jstratton77]

Just in case you were looking for validation, we did the exact same thing, manually placing the log4j-core 2.15.0 files in place, as well as api and slf4j jars.  I'm hopeful that that is all there is to this one, but am following this thread just in case there is more.  We are very vanilla CF here.

[michaelm87459285]

Awesome. We did all the other recommened stuff and were thinking manual updates to 2.15.0 as well-just to be on the safe side. Any gotchas?

[jstratton77]

No gotcha's so far.  All logging is still happening as it was, and no reports of breaking changes from our customers.  Again, we are very vanilla, you mileage may vary.

[michaelm87459285]

thx. rolling out with the updates.

[NicoTexas]

Don't think you need to update slf4j here, but I guess it won't hurt unless you are upgrading to a new major version 🙂

But good to know it was working for you too.
We did not see any difference in our logs or alerts/dashboards based on logs

[jstratton77]

Honestly, I don't know what SLF4j is, but when I saw it had the same version stamps as the other two I went ahead and did it as well.  I figured they may all work in unison and/or dependent on eachother.

[Segfault]

I find it fairly surprising Adobe hasn't yet come forward with any info at all on how/if this affects CF 2018 and 2021 installs.

Or even just short term info like if it's a good idea to deploy "patches" like the "-Dlog4j2.formatMsgNoLookups=true" argument or possibly even just straight up swap out the component with the Apache supplied version yourself.

[Miguel-F]

Subscribing to this thread...

[Ripley Casdorph]

We downloaded the new 2.15 jar from Apache and we can put it in place and remove the 2.13 version, but where do we tell Cf to get the new file?

We are now getting an error...

"Unable to initialise Logging service: java.lang.NoClassDefFoundError: org/apache/logging/log4j/Logger"

java.lang.NoClassDefFoundError: org/apache/logging/log4j/Logger

So I know we need to update a config but don't know where or what.

TIA

[NicoTexas]

You will have to stop coldfusion service
In coldfusion/cfusion/lib folder remove the files
log4j-api-2.13.3.jar
log4j-core-2.13.3.jar
log4j-to-slf4j-2.13.3.jar
And replace them with 2.15.0 version, then restart Coldfusion

No need for config update if you do that.

[BKBK]

We downloaded the new 2.15 jar from Apache and we can put it in place and remove the 2.13 version, but where do we tell Cf to get the new file?

We are now getting an error...

"Unable to initialise Logging service: java.lang.NoClassDefFoundError: org/apache/logging/log4j/Logger"

java.lang.NoClassDefFoundError: org/apache/logging/log4j/Logger

By @Ripley Casdorph

What do you mean by "put in place"? 

In any case, you could proceed as follows:

1.  Stop the ColdFusion instance;
2.  The relevant files are 
         log4j-api-2.13.3.jar
         log4j-core-2.13.3.jar
         log4j-to-slf4j-2.13.3.jar    
         Move all three from the instance's lib diectory to a backup location outside ColdFusion;
   
3.  Download the 2.15.0 files, namely,
   

         log4j-api-2.15.0.jar
         log4j-core-2.15.0.jar
         log4j-to-slf4j-2.15.0.jar

   
        from the respective locations
   
   https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.15.0/
   https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/
   https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-to-slf4j/2.15.0/

4.  Copy the JARs to the lib directory;
5.   Restart the ColdFusion instance.
   
   Oh, and, for double safety, add -Dlog4j2.formatMsgNoLookups=true to the java.args in the file /bin/jvm.config
    

[BKBK]

My suggestion is basically the same as that of @NicoTexas . 🙂

It took me some time to put the suggestion together, as you can see. I was unaware that @NicoTexas had posted in the meantime.

[virala935979]

I am on Coldfusion 2016

I tried the below steps

remove the file

• log4j-1.2.15.jar

Added the files

• log4j-api-2.15.0.jar
• log4j-core-2.15.0.jar
• log4j-to-slf4j-2.15.0.jar

However after restart it gave me 500 error 
Unable to initialise Logging service: java.lang.NoClassDefFoundError: org/apache/log4j/Layout

Am I doing something wrong here or the CF 2016 version don't support Log4j 2.15 version

[32132132164654654]

So far, evidence suggests that CF2016 is not affected by log4shell.
Plus, log4j-1.2.15.jar is required by ColdFusion to work. 
Log4J2 is will not work on CF2016

On CF2018+ as far as I've been able to understand, log4j2 is NOT used by ColdFusion "the language", but by some dependency.

I've been so far unable to pinpoint the exact dependency which requires log4j2
Knowing is necessary to create a POC replicating the log4shell vulnerability, in order to being able to test it after remediation works.