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]

Here's news shared initially from Mark Takata at Adobe:

"As reported this morning, Log4J is vulnerable to a zero-day RCE exploit. Details here:

https://www.lunasec.io/docs/blog/log4j-zero-day/

This is being classified as a severe vulnerability, as it can be exploited to allow unauthenticated remote code execution.

Details of the CVE here: https://www.randori.com/blog/cve-2021-44228/

The Adobe ColdFusion engineering & support teams are currently working with the security team to examine how this exploit affects a vanilla CF2021 and CF2018 install. Initial reports seem to indicate that installs of this nature do not utilize Log4J in a way as to be exploitable, but research is just beginning so please exercise a maximum of caution, especially if your installation utilizes Log4J in a way other than the default install.

An initial method of reducing/eliminating your vulnerability is to alter your jvm.config by adding the following line:

-Dlog4j2.formatMsgNoLookups=true

Once the config file is altered, you will need to do a restart of the environment to ensure it is taken up. I will share any further news about this situation as it comes in."

Update: I got this quote from Pete Freitag, by way of an email sent to those of us using his excellent HackMyCF service, which I discuss more in a later comment here. Note also that Pete had later that day done a blog post with more info on this vuln, and options to consider for addressing it (while we await any official/final word from Adobe).

[Priyank Shrivastava.]

Hi Charlie,

Small correction to it, we are still analyzing the impact and we don't know if this argument can help or not. Once we have further communication from Adobe security team, we will update here. 

[michaelm87459285]

Thanks Priyank. FYI- we are already seeing active attacks and have applied several countermeasures, but would be better to just have this patched or know if we are not actaully vulnerable.

Michael Miller

[Charlie Arehart]

When you say you're seeing active attacks, can you share any more? Do you mean via cf? And something that any cf user would experience, or due to code you have? I realize you may feel you can't say, but if you can it would be very helpful.

Thanks Dave and others as well for points added here. 

[michaelm87459285]

Hey Charlie-Not sure I can share wo govt concurence, seeing nothing specific to CF just the usual suspects running published exploit stuff with user agent jdni:ldap - at least so far. SANS thinks it will morph and so do I

[michaelm87459285]

let me know if you want to talk offline

[Charlie Arehart]

Michael and I talked. He did not mean what I read. I thought he meant his org had experienced *successful* attacks via this vuln. He meant just that he'd seen evidence of ATTEMPTED attacks. That's quite different, of course. (Most people would be shocked to see what percent of their cf request traffic is literally just hack attempts.)

We chatted a bit more and got on the same page about things. That said, what I'm about to say is my own (current) opinion. I'm not putting these words in HIS mouth. 🙂 But I think it should be said by someone. I'll take the stand. 

Folks should look more closely into this vuln: from what I've read, an attacker would need to find some way that your code (or something in cf itself) takes user input and logs it. That's where the vuln would begin.

In cf, that would typically be via CFLOG or writelog. The odds of leveraging that for the typical cf shop seem slim, unless new info proves me wrong:

• a) you'd have to have code that DOES do cflogging (in a publicly accessible web app, or that an insider in your network could access) ,
• Then b) you'd have to also pass user input to that. 
• Then c) the attacker would have to FIND where you do it and
• Then d) they'd have to determine what user input is logged, and try to abuse that.

That just doesn't sound at all a common situation. But sure, knuckleheads will try, beating every door and jiggling every lock, with automated tools to try factorial permutations. (Buy stock in Amazon. Bandwidth charges on aws should get a record bump.) 

It's early days for this vuln, but it sure feels like there may be an overreaction to this, like happened with the ghostcat vuln of early 2020. Not saying ignore it, but I am saying let's keep our heads. Or ok: as is said in some circles, keep 'em on a swivel. Time will tell how big a deal this is. Maybe it' s huge. Maybe it's a lot of fury signifying...well...little.

But we're blessed to have Adobe and Pete and others digging into it.

And again I am open to having my opinion changed. I suspect some reading this may even feel I'm being irresponsible to question the urgency.  They're just thoughts for consideration. Each must choose their path, given the info we've been presented. 

[Charlie Arehart]

I have some new thoughts to share this morning. I will add them at the top level, instead of as a reply here, as these can get really narrow as columns on a mobile device.

[s_sykes]

Charlie,

As best I can tell, this will be very difficult to exploit in a standard setup that does not use CFLOG.  Has anything changed in the last few days to change your opinion?

Thanks!

[Dave Watts]

I think Mark (& Charlie) are pretty accurate. To be vulnerable to this, four things have to happen:

- you need a broken version of log4j,

- you need to be writing Java code that unintentionally exposes this to the outside world by using LDAP and a fairly common Apache Struts configuration,

- that version of Struts needs to be reachable from the attacker, 

- your server needs to be able to make external LDAP requests to attacker's server

We do have a broken version of log4j, that's a fact. It's possible that just turning off remote lookups as Mark & Charlie stated is enough to fix any problem. We'll have to see what Priyank says about that. There's a new version of log4j that doesn't do remote LDAP lookups for JNDI clients, but I don't know when that'll be available as a CF update. I'm fairly confident that Struts should not be exposed to public HTTP clients. You can also simply block any egress at your firewall unless you know it's legitimate. Almost nobody does that because it's a giant pain, as far as I can tell.

Dave Watts, Eidolon LLC

[Dave Watts]

Also, hey, ColdFusion 10? The version of log4j in there might actually be too old to be vulnerable! But you should probably upgrade to a supported version of CF.

Dave Watts, Eidolon LLC

[Sireex]

I believe CF10, 11 and 2016 use log4j version 1, this shouldn't be vulnerable?

[Dave Watts]

They're not listed as vulnerable to this specific CVE, so probably not. But they may well be vulnerable to other stuff.

Dave Watts, Eidolon LLC

[Jdsplicer]

Well, that is actually good news. We are in the process of upgrading that last server we have that uses CF10. Thanks.

[Bardnet]

Has anyone managed to build a testcase?

After reading a post over on dev.lucee I simply put the line

<cflog text="${jndi:ldap://127.0.0.1:1389/cflog}"

in a cfm file but nothing happened.

I don't want to wait for a hacker to find the issue; I'd love to see whether I'm vulnerable.

[Charlie Arehart]

I agree and had found the same (and alluded to it in other comments here). Been wanting to offer a more elaborated comment by been too busy. Thanks for sharing this. If I get to add more things I've tried, I'll create a new top-level comment, so folks don't miss this discussion deep with others. 

[NicoTexas]

I think you forgot also to mention that you are actually logging the nefarious script. That said, this is really common to log a user login tentative, so most likely your login page is going to be the first and easiest piece to attack.

My take is that, even this takes few things to make you vulnerable, Adobe should provide a patched CF update asap.
My expectation is that it should have been worked out over the week-end and available already. Apache did a great job to provide a fix for the library in a record time. It's not like there is not an easy path to patch.
You can't just hope your clients are monitoring/restricting all the inbound/outbound traffic. They owe their user base a secured solution, especially on those kind of vulnerability which is rather easy to exploit all considered.

[jstratton77]

Hello!  According to this link:

https://logging.apache.org/log4j/2.x/security.html

It looks like Log4J version 2.15.0 has been released which patches this particular vulnerability.  Has the ColdFusion engineering and support teams investigated this?

[Jdsplicer]

Thanks all for the valuable information, much appreciated and I will continue to monitor here for any further updates. 

[Charlie Arehart]

Here's a really helpful resource from Cloudflare on what they have found regarding this vuln. They actually posted a few entries yesterday. This one talks more about the details of how it might lead to trouble, and how one could try to detect the problem (and how bad guys are doing that).

They also share how they are now blocking it for folks, via their WAF, which they also say they are enabling for free account holders. I'll leave you read more about it, and the other resources they have and that they point to (from others).

It's a good place to start, for folks wondering about more than just "there's a zero day!" And as I shared in another comment here, we have Adobe and Pete and others (including myself, I hope) who are doing more digging into the specifics for CF.

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

[JuergenW]

Three questions:

- Can we expect a Coldfusion update in the next days?

- Is it secure if the -Dlog4j2.formatMsgNoLookups=true was set in Coldfusion 2018?

- Is Coldfusion 2016 not affected?

[Charlie Arehart]

Only Adobe can answer your first question, of course. As for the next two, it's unclear. Work is being done by many to ascertain clarity: is CF affected at all, if so what versions, how is it vulnerable, how likely can the vuln be leveraged, etc.

Then the next questions are what can we do, now before they may have a fix, and what about those on CF2016 or earlier (which are no longer updated by Adobe). Those fixes (that you will see shared here and elsewhere) have caveats, again depending on what log4j version one has (which for CF people will depend on what CF version and update they have).

For now, all people can do is wade through all the info and make the best choice for themselves. I will share another message, as a top level-reply here, with a bit more info for folks to consider. 

And others, from Adobe or not, may have more in reply to your specific questions, of course.

[Charlie Arehart]

I don't see anyone yet pointing to Pete Freitag's blog post on the topic, where he is gathering info on this topic, and updating it as he learns things:

https://www.petefreitag.com/item/923.cfm

I highly recommend it, along with this discussion thread you're now reading. Between the two, we should see clarity on all this as the smoke clears.

As many know, Pete is regarded by most as THE security maven in the CF space. While he doesn't work FOR Adobe, he does work WITH them, having written the CF Lockdown Guides for the past several CF releases. 

Pete also offers an excellent service that I also highly recommend, called HackmyCF (https://hackmycf.com), whose name may scare you but whose features should delight you, as it (a paid service) keeps you apprised regularly of the state of your own CF instance and need of security-related configuration improvements.

Beyond that regular checking, Pete had also informed those with the service about this vuln the day it happened, within hours of it first being mentioned (and after he had had some time to gather his initial thoughts on this fast-moving target). For many, that alone is reason enough to buy the service.

In fact, the first comment I made here above, where I quoted Mark Takata, was indeed from the info that Pete had shared in one of his first messages to members. Since he was quoting Mark, I assumed that was something he'd found posted elsewhere. I was torn about posting that without more specific clarification on where I got it, but I had only minutes before a series of consulting sessions that day so offered it as the first response here, trusting that more would be shared in time (as it was).

I did mean to come back and add the clarification that I'd gotten it from Pete's service, and I did want to elaborate a bit on it as I have now. Again, since no one had mentioned it or his blog post (which came later that day), I wanted to get this here for the sake of the community and in thanks and with much appreciation for all Pete does.

[Dave Watts]

I'll second this, you should all check out Pete's security work in general as well as with this specific problem.

That said, I would also strongly recommend that you implement egress filtering somewhere outside of ColdFusion - at your firewall, using AWS security groups, whatever. Your front-line servers should NOT be able to just make outbound requests to just any place in the internet. This is kind of a pain to implement especially in a legacy environment, but you should have a list of all specific outbound destinations that your servers need to get to, and that list should be updated on an as-needed basis.

Unfortunately, that won't stop all exploits against vulnerable servers with this CVN, attackers can still cause information leakage of things like environment variables and file paths etc. But it will prevent remote code execution through the exploit, which is LITERALLY THE WORST.

Dave Watts, Eidolon LLC