Log4Shell Vulnerability Scan Tool Compilation and Advice

Log4J Scan Tool Compilation (use caution, I have not tested these & make no guarantees)

Comprehensive list of Log4J / Log4Shell Scan Tools - see below

Caveat: Proceed with caution at your own risk when it comes to other tools and code.  I make no guarantees whatsoever, use at your own risk.  Also, go to the end of this article to see my caveats and recommendations to test tools first before using them in an operational environment, get permission and ensure accountability.  

If any tools in test environments show anything undesirable then do not use in production.  I have not tested any tools and do not know their quality, potential unintended consequences or full capabilities.  

I recommend to run in an isolated and segmented test zone within a test environment first.  Take a note of any undesired things that may have been included so as to preclude their use in production.  This is why I emphasize using existing tools in the environment first.   

No tool is perfect, so realize there will be limits for what they can detect, especially when tools are written and pushed out so quickly.  Also assume attackers could eventually use tools and attacks not yet covered, so you should stay up-to-date with new developments.

Caution must be taken as first advice and tools are usually at the bleeding edge and may contain some flaws.  Here are a few examples of how quick fixes resulted in issues and why these need to be re-examined a couple of times, before trusting that they’re good-to-go:

Example 1 – an update causes another issue
https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/ 

Example 2 – scanners fail to detect things
https://www.rezilion.com/blog/log4j-blindspots-what-your-scanner-is-still-missing/ 

The CISO or their designated representative should be the one to approve use of such tools, in coordination with IT operations, as appropriate.  I recommend setting up an approval process as needed and the CISO and/or CIO should only approve their use.  Even using existing tools and Scan tools must go through the proper process - preferably an emergency process (change control, etc.) to expedite.

A. Use PowerShell to query if there are vulnerable instances per CISA

Nathan Kula’s GitHub page: PowerShellSnippets/Invoke-Log4ShellScan.ps1 at: https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1 

Will Dormann’s GitHub page: checkjndi.ps1 at: https://gist.github.com/wdormann/c609ae63a6ec8b58302b8cf377e0ef15 


B. Use Existing Vulnerability Management and Scan Tools to detect Log4Shell like Rapid7, Qualys and Tenable to detect Log4J Vulnerabilities to patch, determine what’s most critical and patch quickly
C. Top 3 Scanners that detected the most Log4J nested files per Rezilion Research

As of this writing, Rezilion tested 8 scanners among the currently available Log4J scanners at sites like Github.  These tests consisted of 10 “open source and commercial scanning tools…assessed against a dataset of packaged Java files where Log4j was nested and packaged in various formats”.  

Of these 10 scanners tested, not one scanner could detect a compressed archived Uber JAR.  As they said, “Some scanners did better than others, but none was able to detect all formats.”  

They further state something important “Rezilion’s research demonstrates the limitations of static scanning in detecting Log4j instances, and highlights the need for code-level visibility in runtime memory where the code isn’t packaged or nested. It also reminds us that detection abilities are only as good as your detection method. Scanners have blindspots.”  Ref: https://www.rezilion.com/blog/log4j-blindspots-what-your-scanner-is-still-missing/

This is eye-opening, and causes me to state the following:

CISO’s, CIO’s and teams must realize from the get-go – this is unknown territory and “best effort” is the name of the game.  This process will not be as thorough or as perfect as some would hope.  Nor will it be completed in as quickly as desired.  It will also require use of resources and could impact other projects and initiatives.  However, the risk requires a higher-than-normal level of effort and response.

The effort is meant to remediate what’s highest risk, and use existing defense-in-depth tools and methods to cover residual risk.  In addition, continued projects and efforts should focus on the longer-term, to further reduce risk as well as tackle many root cause issues.

Scanning is still useful – here’s what else the research found:

3 of 8 scanners show the most promise, detecting most files.  These 3 scanners detected between 7 or 8 of 10 files, and are provided here as recommendations to try these first to achieve the greatest effectiveness in shortest time:

The Top 3 Tools showing promise for detecting a variety of Log4J-related files:

[proceed with caution and may want to test in isolated test environment first]

1. Log4j sniffer: https://github.com/palantir/log4j-sniffer  which also has a nice chart for self-declared detection capability and limitations

“log4j-sniffer will scan a filesystem looking for all files of the following types based upon suffix:

Zips: .zip
Java archives: .jar, .war, .ear
Tar: .tar, .tar.gz, .tgz, .tar.bz2, .tbz2”



Also, Rezilion said "using source-code analysis...to detect dependencies on Log4j...will effectively detect nested and packaged instances of the vulnerable component...[but] it can’t be applied to packaged third party software (which still constitutes for most of the code in production). Furthermore, it has major blind spots and false-positives when it comes to transient dependencies"

“Rezilion’s research demonstrates the limitations of static scanning in detecting Log4j instances, and highlights the need for code-level visibility in runtime memory where the code isn’t packaged or nested.”

[They also offer a free assessment to help build "a dynamic SBOM to deepen visibility across your attack surface - something that NSA's Rob Joyce also tweeted about as important and exists as a way to determine supply chain risk]


D. Use Other Freely Available Scanners from Reputable and Trustworthy Resources:

Use these at your own risk – no guarantees here.  Proceed with caution.  Do not use tools from non-reputable sources.

Bytecode Codeshield (https://codeshield.io/product/) had this to say:

Specifically regarding Maven Central:

“Which artifacts other then log4j-core are actually affected?
We have been working on the topic of Java vulnerability detection for several years now and we are currently applying our technology to further detect more instances of the vulnerability in the wild.

Maven Central is one of the largest repositories for Java artifacts, and basically any Java program sources its third-party dependency from there. When installing a dependency, a jar file will be downloaded and included into your software.

The question arises which artifacts are actually affected by the log4jShell vulnerability?

This is not a simple question to answer, as source code repositories are not always linked and even if so, the packaging step of a typical Java build may just pack all dependencies into a single jar, a so-called fatjar. Once the vulnerability is part of the jar, the software is affected.

Here is the Bytecode Shield tool, which they say is “an open source tool that helps identify if a jar file is affected by the critical CVE-2021-44228. The tool scans the jar file and compares the classes against a set of vulnerable hashes for classes within the jar file. The hashes have been pre-computed for artifacts on Maven Central."

-------------------------
CISA CERT/CC CVE Scanner
-------------------------
Contrast Security Scanner: 
-------------------------
Lunasec Scanner (to scan a directory or specific Java JAR file and hashes of vulnerable classes)

Lunasec also says to follow instructions at this site to manually build your own tool or scan manually and other guidance: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/ and
-------------------------
Huntress Scanner:
-------------------------
FullHunt's Attack Surface Scanner: 

FullHunt says it is a “next-generation attack surface management platform. FullHunt enables companies to discover all of their attack surfaces, monitor them for exposure, and continuously scan them for the latest security vulnerabilities.” Also says “it can check for WAF bypasses, offers URL scans and all request methods for testing susceptibility of this Jog4Shell vulnerability” per their GitHub page.
-------------------------
Anchore Tools (Syft and Grype – see below)

“for step-by-step instructions for finding and fixing the Log4Shell vulnerability found in Log4j using Anchore open source solutions (Syft and Grype) and commercial solution (Anchore Enterprise).”  https://anchore.com/blog/how-to-find-and-fix-log4j-with-open-source-enterprise-tools-anchore/ 

Here is what CISecurity said about Syft and Grype:

Grype – Searches libraries installed on a system and displays vulnerabilities present
Syft – Searches for installed code and libraries and displays their versions

---------
Syft Scanner: https://github.com/anchore/syft 

Syft is "A CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. Exceptional for vulnerability detection when used with a scanner tool like Grype."
---------

Grype is "A vulnerability scanner for container images and filesystems. Easily install the binary to try it out. Works with Syft, the powerful SBOM (software bill of materials) tool for container images and filesystems."

-------------------------
Logpresso Tool 

Their Github site says "log4j2-scan is a single binary command-line tool for CVE-2021-44228 vulnerability scanning and mitigation patch. It also supports nested JAR file scanning and patch. It also detects CVE-2021-45046 (log4j 2.15.0), CVE-2021-45105 (log4j 2.16.0), CVE-2021-44832 (log4j 2.17.0), CVE-2021-4104 (log4j 1.x), and CVE-2021-42550 (logback 0.9-1.2.7) vulnerabilities."

-------------------------
NCSC-NL Scanner (Netherlands Gov)

NCSC-NL Scanner List
-------------------------
NCC Group Recommended Log4j-finder: “finding vulnerable versions of Log4j on your systems
RIFT has published a Python 3 script that can be run on endpoints to check for the presence of vulnerable versions of Log4j. 

The script requires no dependencies and supports recursively checking the filesystem and inside JAR files to see if they contain a vulnerable version of Log4j. This script can be of great value in determining which systems are vulnerable, and where this vulnerability stems from. The script will be kept up to date with ongoing developments.

It is strongly recommended to run host based scans for vulnerable Log4j versions. Whereas network-based scans attempt to identify vulnerable Log4j versions by attacking common entry points, a host-based scan can find Log4j in unexpected or previously unknown places.

The script can be found on GitHub: https://github.com/fox-it/log4j-finder “
-------------------------
Whitesource Scanner Log4JDetect 

[Linux, Mac and Window install options]

WhiteSource Log4j Detect is a free CLI tool that quickly scans your projects to find vulnerable Log4j versions containing the following known CVEs:
CVE-2021-45046
CVE-2021-44228
CVE-2021-4104
CVE-2021-45105
CVE-2021-44832
and some info regarding, at:
-------------------------
Mubix Scanner for vulnerable file hashes
-------------------------
Yahoo Tool 
Yahoo says their tool is “different from other tools that attempt to verify whether a specific service is vulnerable by triggering the exploit and e.g., tracking pingbacks on a DNS canary token...The check-log4j tool attempts to give host owners a tool to determine likely vulnerability by looking at running java processes and inside of any common Java archive files found.”  They also ref their manual page for more details: https://github.com/yahoo/check-log4j/blob/master/doc/check-log4j.1.txt 

Beware any of these tools themselves could introduce risk.  Some such as the Yahoo tool may reach outside of the network and ping a server - theirs of course, but what if that server got compromised for example...so proceed with caution, ensure a good risk-based decision is made first by the appropriate level of management.
-------------------------
NetSpi recommend using scanners like Nmap and Nessus and their plugins to detect Log4J vulnerabilities on both external-facing and internal assets.  
-------------------------
Arctic Wolf Open Source Log4Shell Scanner 
Per their video at: https://www.youtube.com/watch?v=BSQ_SgusJ6w  their tool has these capabilities:
  • Provides detections for CVE-2021-45046 & 44228
  • Deep scan works on JAR, WAR and EAR files
  • Flags known vulns and outputs their location within host's file system
  • Available for windows, MacOS/Linux clients
  • Video includes demo for use” 
Note: if other vendors include videos and instructions, I recommend to look at these first for familiarity and caveats as well as updates.
-------------------------
CISA Recommended Tools
• To identify server applications that may be affected by Log4Shell and CVE-2021-45046, see TrendMicro: Log4J Vulnerability Tester https://log4j-tester.trendmicro.com/ 
Trend Micro's vulnerability scanner is based on the following projects:
List of hashes to help determine if a Java application is running a vulnerable version of Log4j, see:
For guidance on using Canary Token to test for callback, see Thinkst Canary’s Twitter thread on using Canary Tokens https://twitter.com/ThinkstCanary/status/1469439743905697797 
• For guidance on using Burpsuite Pro to scan:
For guidance on using NetMap’s Nmap Scripting Engine (NSE), see Divertor’s GitHub page: nse-log4shell. https://github.com/Diverto/nse-log4shell 

See Florian Roth's GitHub page, Fenrir 0.9.0 - Log4Shell Release, for guidance on using Roth’s Fenrir tool to detect vulnerable instances. https://github.com/Neo23x0/Fenrir/releases/tag/v0.9.0 Ref: https://www.cisa.gov/uscert/ncas/alerts/aa21-356a 
-------------------------
CISecurity Resources for State Local, Tribal, Territorial (SLTT), MS-ISAC / EL-ISAC Members

“State, Local, Tribal, and Territorial (SLTT) governments and affiliated organizations, including Elections organizations, may contact the CIS SOC for assistance if you believe you were impacted or compromised.

MS-ISAC and EI-ISAC members are encouraged to reach out to the Security Operations Center (SOC) as soon as possible if you suspect you have been impacted by an attack against this vulnerability.

The MS-ISAC is currently working with members who have been impacted. The scope of this vulnerability is more widespread than any other case in recent history. We aim to support all SLTTs and respectfully ask for your patience as we work through this together.

Additionally, we have the ability to scan your external facing infrastructure with up-to-date signatures from leading vulnerability vendors Tenable and Qualys. If you are a member or qualify to join (see here for MS-ISAC, and here for EI-ISAC membership information), please inquire with our SOC about a scan.” Ref: https://www.cisecurity.org/log4j-zero-day-vulnerability-response/

Added caveats using tools in the environment, testing first, accountability and more

I strongly emphasize setting up an accountable process for approval of tool use via vetting, testing and document.  Keep this process fast and efficient to include testing and approval – but ensure it gets done and is an accountable process - think ITIL!  

Every tool and every instance of a tool’s risk poses risk and must be follow risk-management-based processes.  Ensure the Red Team understands the tool approval process and does not just start downloading tools and using anything that becomes freely available on the Internet.  

Pre-approved tools in the environment are preferred, as others not pre-approved must be vetted first, which takes extra time.  If no process exists, cautiously use tools as recommended by trusted sources only, or establish a quick and effective vetting and gating process that works for you.

Be careful about using certain scan tools that might publish information publicly and could potentially draw attention of attackers.  Always select private scans rather than public scans and realize if the company’s database is hacked, even if scanned using “private mode” the company may have data accessible by the attackers.  Best to run a tool you can control in your environment and keep the information there.  

Realize any attacker can run any tool anytime if it is publicly available.  Scanning and probing occur continuously.  One must therefore scan their environment before the attackers do, and work to remediate findings to be less of a target.

Ensure IT (network, ops) and cyber teams (Blue/SOC) are aware of any scans being conducted.  Coordination and communication are key.  Set up and use an emergency change control process as needed.  Be very selective about what tools are used in the environment, and test them first.  Know what effects they may cause and whether or not they are effective or ineffective.

The tools I’ve referenced earlier and in follow-on articles below seem to be recommended by several reputable organizations and people - however - I cannot make any guarantees whatsoever, so use them at your own risk.  They may have unintended consequences and should be tested first.  

Other Tool Cautions – misleading information and flawed assumptions

Contrast security warns: “Remember, you may be getting false results from other approaches. Scanning file systems, code repos, or containers could easily fail to detect log4j accurately. Determining exploitability by attempting to test, scan, or fuzz for log4shell is even more inaccurate, requiring exactly right input with the exactly right syntax.
  • log4j could be buried in a fat jar, war, or ear
  • log4j could be shaded in another jar
  • log4j could be included in the appserver, not the code repo
  • log4j could be part of dynamically loaded code or plugin
  • log4j could be many different versions with different classloaders in a single app
  • log4j could be masked by use of slf4j or other layers
  • log4j could be renamed, recompiled, or otherwise changed”

Note they then go on to promote their tool provided earlier, stating it:
  • “verifies that the log4shell vulnerability is actually present and exploitable
  • prevents the log4shell vulnerability from being exploited
  • Safelog4j doesn't rely on version numbers or filenames. Instead, it instruments the application to find log4j and perform an internal test to prove the app is exploitable (check). Safelog4j also uses instrumentation to disable the JNDI lookup code used by the attack (block). This is the most effective way to inoculate an otherwise vulnerable application or API.”
Use Only on Systems You Have Explicit Permission to Test.  

The CISO and/or CIO should provide this permission. They should not allow scanning of environments they do not own.  Also, scanning cloud environments should be cleared with cloud service providers and procedures established by cloud providers must be followed. 

Huntress Security recommends [and it’s good advice for all tools] “The following payload should only be used with systems which you have explicit permission to test. If you find any vulnerable applications or libraries, you should exercise responsible disclosure to minimize any potential fallout due to the vulnerability!  This tool was created with the intention of helping the community quickly identify vulnerable applications in your own networks only.” Ref: https://log4shell.huntress.com/ [emphasis mine]

I sincerely hope this scan tool compilation and advice helps.

#RCE #Log4Shell #Infosec #Cybersecurity. - CYBER Y'ALL! - @CyberYall

Comments

Post a Comment

Popular posts from this blog

Slay the Log4Shell Dragon TEAM 2 - Hunt and Detect Attacks Playbook

Image
Slay the Log4Shell Dragon Playbook TEAM 2 – Hunt and Respond Playbook Struggling with how to tackle the Log4J / Log4Shell Dragon and low on resources? First, as I've said before, start with my “ RAPID LOG4SHELL RESPONSE 1-PAGE CHECKLIST ” to begin immediate actions to tackle this issue.  In that 1-pager, I provide concise guidance to get started quickly.   However, for medium and larger sized companies, this approach might not be enough , although it is a great and immediate start.   Simply patching alone will likely not meet the expectations in the case of the Log4J / Log4Shell vulnerabilities, if there is a breach.  A more comprehensive approach is required to reduce risk.  I’ve therefore put this playbook together to help go above and beyond just a patching-based approach and hope it proves useful.   My goal was to provide something that would help ensure a high enough level of due diligence for risk reduction of this issue.   In this article I’ll provide a TEAM 2 PLAYBOOK o
Read more

Slay the Log4Shell Dragon TEAM 1 - Protect and Detect Vulns Playbook

Image
Slay the Log4Shell Dragon Part 2A - TEAM 1 -  Immediate Protection and Detection Struggling with how to tackle the Log4J / Log4Shell Dragon and low on resources? First, start with my “ RAPID LOG4SHELL RESPONSE 1-PAGER - 8 STEP CHECKLIST ” to begin immediate actions to tackle this issue.  In that 1-pager, I provide concise guidance to get started quickly.  However, for medium and larger sized companies, this approach might not be enough, although it is a great and immediate start.   Simply patching alone will likely not meet the expectations in the case of the Log4J / Log4Shell vulnerabilities, if there is a breach.  A more comprehensive approach is required to reduce risk.  I’ve therefore put this playbook together to help go above and beyond just a patching-based approach and hope it proves useful.   My goal was to provide something that would help ensure a high enough level of due diligence for risk reduction of this issue.   In this article I’ll provide a TEAM 1 PLAYBOOK of recomm
Read more

Keys to Working Smarter Not Harder in Cybersecurity Part 5 of 5

Image
Welcome to the last in the series - part 5 of a  discussion about working smarter not harder in cybersecurity.   We'll look at: How to tackle the huge tasks with bite-sized chunks and baby steps  What to do instead of trying to defend everything despite competing priorities Baby Steps and less is more  It’s been said that a long journey begins with a single step.  It’s also been said that to eat a large steak, you have to do it one bite at a time.  Remember the movie “What About Bob?”  Baby steps folks.  Small incremental progress in important things like low-hanging fruit is key.   A “Less is More” philosophy should be a basis of a better approach in cybersecurity.  Also, “try softer” rather than “try harder” is another important strategy.  Trying too hard usually ends up backfiring and causes too much friction.  All of these things are behavioral patterns on the human and process side of things.   For example, why try to implement 30 items in a  STIG checklist  when the attack to
Read more