How do I look for vulnerabilities to Log4Shell?

Cisco have released what products are affected and also released Snort rules

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd#vp

and here is the vulnerability

https://logging.apache.org/log4j/2.x/security.html#:~:text=Fixed%20in%20Log4j%202.15.0

You can also see the files in this article

https://community.ui.com/questions/UniFi-Controller-security-concern-zero-day-Log4j-exploit/007103a6-823b-4316-ae76-17942539208c#answer/e10b8e76-d34a-4c1d-beba-31971b69a6bd

if you want to update yourself homebrew, but you are probably waiting until vendors have supplied upates.

A Python script has been developed here for you to check devices

https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6

To fix this you need to get the latest log4j library:
https://logging.apache.org/log4j/2.x/download.html

You want version 2.15.0 - which only came out a day or two ago.

So don't upgrade Java (that won't help).  Upgrade log4j.
There are other more complex solutions if you can't upgrade log4j for some reason, but that's the simplest.

And just to be clear this is a server side fix.  If you're just an end user there's no vulnerability here.  You need to be running a web site written in Java with logging enabled.

I have dozens of host servers with hundreds of images within each server. That has me concerned. We are a VM Ware shop.

I downloaded version 2.15.0 but it talks about verifying the download with keys. From where do I get the keys?

The keys are here:
https://downloads.apache.org/logging/KEYS

but it's largely a theoretical risk where you need to verify with keys - that's in case you might be downloading the files from a non apache server by mistake.  I would grab the files and get them out as quick as you can - because the log4j attack is a far from theoretical risk.

You need to check if your servers use it!

Do you not have a current Vulnerability checker ?

Maybe take

https://community.greenbone.net/t/latest-version-virtual-appliance/6351

it's freee!

https://www.greenbone.net/en/testnow/#downloadnow

This is what I was trying to find this morning. I have 14 days to give this a try.

It's free after the trial, the only difference is the Feed from the Community is slower to update, but at present you may find a delay with many vendors!

oh if you don't have a vulnerability scanner, it may surprise you what you find on your network - be warned!

Cisco have updated Snort, and have fixes available and Ubiquiti have just issued a fix as well.

I bet it will be interesting what it finds. Will it take into account the harware firewall that is in place?

it will scan everything (if it can), and categorise into high, medium and low, CVEs !

where there is a port open it will scan it!

and as you are a VMware shop be surprised for some results there as well!

(if you need to discuss them I would recommend posting a new question!)

You may get - SSL/TLS: Report Vulnerable Cipher Suites for HTTPS

That is where the vulnerability mgmt tool comes in like this. That is probably the first source you want to check if there is signature for the hunting. Like the use of Carbon Black in below link.
Caveat is the observed alerts will trigger based on file access of the vulnerable Log4j core library, and therefore will not alert on an already loaded library until reboot or a process restart that forces a reload of the affected library.

https://community.carbonblack.com/t5/Documentation-Downloads/Log4Shell-Log4j-Remote-Code-Execution-CVE-2021-44228/ta-p/109134

That said, this vulnerability is far real and serious as expert shared, so let's go broader in coverage of option for hunting in:

1) finding potentially vulnerable software

• Important to know where log4j is in your environment - authenticated vuln scanners ideal, but some appliances won't be visible and may have unknown Java components
• Work the inventory angle hard and early. Like Shellshock, this is the only long-term winning strategy
• reddit /r/sysadmin thread on detection
• hashes of vulnerable log4j jar files (mubix)
• Hunting with Crowdstrike
• local-log4j-vuln-scanner "JAR and WAR archives are inspected and class files that are known to be vulnerable are flagged."

2) detecting exploitation attempts

• To detect others trying to exploit, look for jndi:ldap, jndi:dns, etc in logs - but obfuscation also likely
• Some products only use log4j for local logging, so SIEM/syslog/Splunk searches are good, but may not provide full coverage
• log4shell-detector (Florian Roth) - looking for many obfuscated combinations of potential exploitation attempts in logs - see also Ansible role to run it
• Detecting log4j 2 RCE Using Splunk
• Finding applications that use Log4J - Rumble
• Check Point coverage
• McAfee NSP signature (KB95088)
• list of known source IPs attempting detection or exploit (gnremy)
• YARA and other rules (Florian Roth)

3) vulnerability testing

• To test your own vulnerability, pass ${jndi:ldap://[some-IP-you-listen-on]/uniquestring]} as data that might be logged (form fields, User-Agent strings, usernames, etc.) to your target, and then check your HTTP listener logs for uniquestring
• When testing, be sure to hit other vectors and protocols - IMAP, SMTP, SNMP, HTTP on alternate ports, HTTP headers, syslog, username fields ...
• log4jscan (BurpSuite)
• byt3bl33d3r HTTP server tester
• Centralize detection for your own tests with canary tokens, including a new dedicated token type
• codeql query to find vulnerable code paths (Paulino Calderon)
• PortSwigger ActiveScan++ detection support

As @depearson mentioned, this is a server side fix, fixed in v2.15, so just check your versions to ensure you have 2.15 installed.

Do I need to have Java installed to run these jar files? With which one do I start?

Do I need to have Java installed to run these jar files? With which one do I start?

This vulnerability is just in Java (specifically one library commonly used in Java applications).  So if your servers do not already have Java installed you have nothing to worry about.

However, if you have Java installed on your servers you likely also have at least one copy of this library somewhere.  Just search for log4j*.jar and anywhere you find it, swap for the matching file from the log4j 2.15.0 distribution.

To share more insight.

To check whether your application is likely affected you must verify:

• Log4j version – all 2.x versions before 2.15.0 are affected
• JVM version - if lower than:
  • Java 6 – 6u212
  • Java 7 – 7u202
  • Java 8 – 8u192
  • Java 11 - 11.0.2

If both are true, your Log4j version is older than 2.15.0 and your Java version patch level is older than listed above, you’re almost certainly affected. 

• JVM version - if lower than:
  • Java 6 – 6u212
  • Java 7 – 7u202
  • Java 8 – 8u192
  • Java 11 - 11.0.2

We also saw this list of Java versions posted online as being particularly vulnerable, but I have to say we run on Java 14 currently and could reproduce the attack.  So it does not appear to be complete.

I would suggest focusing on just this one rule:

• Log4j version – all 2.x versions before 2.15.0 are affected

Agree with expert as key is the jar file shared in this discussion

It has found Apache.Arrow.dll in the Visual Studio 2019 folder
com.sap.apache.abdera.rs.jar in the SAP Business Objects folder
Hundreds of files like tp.apache.cxf.bundle.biprs-2.3.8-core-nu also in the SAP Business Objects folder

are these of any concern?

need to search for the JndiLookup.class in jar file. pls see
https://www.windows-commandline.com/search-classes-in-jar-file/

Keep an eye on this document which is being updated and growing

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

PS If you are a VMware shop you will need to apply workarounds, no patches yet!

What do they mean by saying add the java binary files folder to PATH environment variables?

forfiles /S /M *.jar /C "cmd /c jar -tvf @file | findstr /C:"Logger.class"

Select allOpen in new window

I am getting this message
 Access is denied for "C:\Users\Rich\AppData\Local\ElevatedDiagnostics\".

You set the PATH var so that you dont need to spell out the full path to the file.
Set the PATH environment variable if you want to be able to conveniently run the executables (javac.exe, java.exe, javadoc.exe, and so on) from any directory without having to type the full path of the command. If you do not set the PATH variable, you need to specify the full path to the executable every time you run it, such as:

C:\Java\jdk1.7.0\bin\javac MyClass.java

Select allOpen in new window

Access denied as you are not the administrator. Run in administrator account instead. 

there is a log4J detector - https://github.com/mergebase/log4j-detector

Reach out to 3rd party Application Support and ask for a fix or a workaround.

On Windows
Until then run the below command to identify if there are any files with log4j as a jar file
Get-ChildItem 'C:\'  -Filter 'log4j*.jar' -rec -force -ea 0

You can refer https://github.com/NCSC-NL/log4shell/tree/main/software consolidated list of all known 3rd party applications, impacted services with a link to workaround\fix from providers. Managed by NCSC