Reputation: 93
What will be the best way to search for log4j vulnerability? Is it a search for "log4j" keyword in the source code enough? Does it only affects Java applications? I read somewhere that applications sometimes rename log4j under another name. A quick google search gives several tools than claim can detect the vulnerability.
Upvotes: 2
Views: 2937
Reputation: 1102
You can use below scanner to identify vulnerable log4j jar files in your application. https://github.com/logpresso/CVE-2021-44228-Scanner
I have used jar version to scan the application. Download jar from from: https://github.com/logpresso/CVE-2021-44228-Scanner/releases/download/v2.4.2/logpresso-log4j2-scan-2.4.2.jar
Open a command prompt in the same location and execute the below command to scan your application
java -jar logpresso-log4j2-scan-2.4.2.jar 'your application path'
Upvotes: 2
Reputation: 388
The vulnerability comes from JndiLookup.class
. In your console use the following command:
sudo grep -r --include "*.jar" JndiLookup.class /
If it returns nothing, you are not vulnerable. But you may encounter such returns:
Fichier binaire /home/myuser/docx2tex/calabash/distro/lib/log4j-core-2.1.jar correspondant
or
grep: /usr/share/texmf-dist/scripts/arara/arara.jar : fichiers binaires correspondent
The first one is clearly vulnerable (version matches), the second one has to be investigated. To mitigate the risk I've immediately removed the JndiLookup.class with the following:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
and
zip -q -d arara.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Applications may continue to work, or not. By the way upgrading to versions using log4J >= 2.17 has to be done. This is the next step, in the meantime you are no more vulnerable.
Upvotes: 3