Another handy one to find where it's hiding, since it can be bundled inside other JARs: find / -name *.jar | xargs strings -f | grep -i log4j On Tue, Dec 14, 2021 at 6:57 AM Doug McIntyre <merlyn@geeks.org> wrote:
On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote:
On Dec 11, 2021, at 04:11 , Nick Hilliard <nick@foobar.org> wrote: ... https://logging.apache.org/log4j/2.x/security.html
1. upgrade log4j to 2.15.0 and restart all java apps 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only) 3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable (v2.10+ only) 4. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
There's a lot of scanning going on at the moment, so if you have an exposed java instance running something which includes log4j2, you may already be compromised.
Nick
Alternatively, this incantation solved the problem on my linux server:
rpm -e log4j12 ant-apache-log4j log4j
There are many software setups that bundle their own log4j.jar without bothering to go through the OS package manager....
$ rpm -qa | fgrep log4j $
$ find / -name log4j*jar ....system/log4j/log4j/log4j/1.2.17/log4j-1.2.17.jar
(obviously an old system due to the commands used and version found, and nor will it get patches available because of vendor...).
Sorta like playing whack-a-mole with jquery.js (another package with lots of security history that seems to be copied _everywhere_ without registring it with the OS package manager).
So, the exercise becomes _finding_ the software that uses it, and then doing the configs that defang JNDI everywhere you find it.