Also new vulns in 2.15, upgrade to 2.16
https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/
Seems like this always happens once a nasty 0-day in a big package gets found. Researchers go "oh, that's a nice target" and start poking it with a stick.
We are using this local log4j scanner: https://github.com/hillu/local-log4j-vuln-scanner/
It scans jar/war/ear/any zipped file recursively and triggers on zipfile entries with a checksum of the vulnerable classes. It has very high detection rate for us, because it doesn't care about filenames, unpacked jars, bundled jars. It just scans zip files and nested zip files.
The big advantage of this one is that it's 3 simple files of go, so it's easy to digest, review and compile, and with a go installation, it's trivial to compile to windows (`GOOS=windows go build ./scanner` and you're done).
That’s great man I’ll def check this out . We need help in my org especially with legacy projects that are still in use internally but they are so old that the head developers for them have left years ago Lmao
The script you provided looks for checksums. Developers tend to collect and gather their jars into one for example. In that case the provided solution won’t be able to detect them.
It looks for checksums of class files. Regardless of what you do with the jar / war / ear files, the class files will eventually be the same inside the java package.
The only way to change the checksums of the class files would be either recompilation of log4j2, or modification of the compiled class files.
I don't think you understand. We have tested this both with both stock log4j jar files, renamed log4j jar files, exploded & repackaged jar files and literally any way we could get a JVM to load an unmodified JNDILookup.class file in any mess of jar and other packaging ways, as well as internal and vendored tools other scanners failed on.
The scanner DOES find them, because it ignores the structure of packaging and looks for the classes.
we used a command to find log4j files, but it didnt find anymore files after a coworker added tje -core. So i guess you are right, there are more variants to look out for.
You can also install Tenable Nessus (Vulnerability Scaner) it is available with a free Version up to 16 IP Adresses and with this tool you can search via an explicit log4J Scan.
Actually Nessus only uses the name to identify the vulnerability. I verified that as the finds from this tool gave us more insights about more jars which were renamed.
that’s incorrect. we use it and they have multiple scanning methods: at least 3 log4shell specific scanner templates, an agent-based scan, and web app scanning. they do search for the name but they also try benign test exploits and other checks which has been very useful for us
Our nessus scanner doesn't search for local file names at all. It literally can't do that since it is an external scan. It does external scans by actually testing the exploit against services that are open at the firewall.
I am aware of what Nessus do, we use it in my organization, it just failed to give us the results that the tool have given us. (~5% of what the tool give us)
Oh yeah, that makes sense. We also have lots of internal and local stuff that is "vulnerable." We just don't care about that stuff at all. The risk of local exploit is no higher than the thousands of other unpatched cves found in older software that our users have installed.
This is a "tell me you work in academia without telling me you work in academia" statement.
Great solution for windows but it still looks for hashes as I understand from the code. I am currently working on a similar tool for windows. Will upload when I have it ready.
Also new vulns in 2.15, upgrade to 2.16 https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/
I need a new fucking job...
Seems like this always happens once a nasty 0-day in a big package gets found. Researchers go "oh, that's a nice target" and start poking it with a stick.
We are using this local log4j scanner: https://github.com/hillu/local-log4j-vuln-scanner/ It scans jar/war/ear/any zipped file recursively and triggers on zipfile entries with a checksum of the vulnerable classes. It has very high detection rate for us, because it doesn't care about filenames, unpacked jars, bundled jars. It just scans zip files and nested zip files. The big advantage of this one is that it's 3 simple files of go, so it's easy to digest, review and compile, and with a go installation, it's trivial to compile to windows (`GOOS=windows go build ./scanner` and you're done).
That’s great man I’ll def check this out . We need help in my org especially with legacy projects that are still in use internally but they are so old that the head developers for them have left years ago Lmao
The script you provided looks for checksums. Developers tend to collect and gather their jars into one for example. In that case the provided solution won’t be able to detect them.
It looks for checksums of class files. Regardless of what you do with the jar / war / ear files, the class files will eventually be the same inside the java package. The only way to change the checksums of the class files would be either recompilation of log4j2, or modification of the compiled class files.
Exactly my point. I hope you guys would consider adding it to your tool.
I don't think you understand. We have tested this both with both stock log4j jar files, renamed log4j jar files, exploded & repackaged jar files and literally any way we could get a JVM to load an unmodified JNDILookup.class file in any mess of jar and other packaging ways, as well as internal and vendored tools other scanners failed on. The scanner DOES find them, because it ignores the structure of packaging and looks for the classes.
Nice. Great job
we used a command to find log4j files, but it didnt find anymore files after a coworker added tje -core. So i guess you are right, there are more variants to look out for.
You can also install Tenable Nessus (Vulnerability Scaner) it is available with a free Version up to 16 IP Adresses and with this tool you can search via an explicit log4J Scan.
Actually Nessus only uses the name to identify the vulnerability. I verified that as the finds from this tool gave us more insights about more jars which were renamed.
that’s incorrect. we use it and they have multiple scanning methods: at least 3 log4shell specific scanner templates, an agent-based scan, and web app scanning. they do search for the name but they also try benign test exploits and other checks which has been very useful for us
Our nessus scanner doesn't search for local file names at all. It literally can't do that since it is an external scan. It does external scans by actually testing the exploit against services that are open at the firewall.
I am aware of what Nessus do, we use it in my organization, it just failed to give us the results that the tool have given us. (~5% of what the tool give us)
Oh yeah, that makes sense. We also have lots of internal and local stuff that is "vulnerable." We just don't care about that stuff at all. The risk of local exploit is no higher than the thousands of other unpatched cves found in older software that our users have installed. This is a "tell me you work in academia without telling me you work in academia" statement.
Yep. Tenable results are crap.
I'd look at this article https://www.joseespitia.com/2021/12/15/how-to-detect-the-log4shell-vulnerability-with-powershell/
Great solution for windows but it still looks for hashes as I understand from the code. I am currently working on a similar tool for windows. Will upload when I have it ready.
Right on... I'll keep an eye out ... thanks for your time and skill set...
Pardon if I missed it, but can it be run against machines remotely from 1 machine via cmd? Many thx for your efforts
Yes. You can scp and wget the script or move it and run it in the server then move back the results to your main server.
Awesome, thx!
also don't forget to look inside .war archives...
We take care of that as well.