Lale Çorumlu

For security teams scrambling to secure their organizations against Log4j exploitation, one of the first and most challenging tasks is understanding where Log4j exists within their environment. Without this understanding, any remediation efforts will be hamstrung from the get-go. Of course, this type of asset management can prove exceedingly difficult as Log4j is represented across thousands of products.

Still, even missing one vulnerable instance of Log4j can leave an organization at risk, which is why discovery is one of the most important steps in the remediation process. Below are four easy-to-implement vulnerability discovery strategies that can be used to assess an environment for vulnerable Log4j implementations.

Conduct full port vulnerability scanning

First, organizations should perform full port vulnerability scanning with service fingerprinting enabled. Scanning tools like Nmap can allow security teams to identify commonly abused protocols like HTTP and Remote Method Invocation (RMI). Vulnerability scanning tools can also identify RMI services that are hosted by Java applications. Teams can also conduct server layer vulnerability scanning with tools like Nessus or Nexpose to identify vulnerable Log4j instances by injecting into the top HTTP Header injection points. This process should take minimal effort if executed from a single location.

To go a step further, experts can use the Nessus or Nmap output to configure a tool such as EyeWitness, WitnessMe, or Aquatone to perform a screen scraping of available websites. This will help create a catalog of websites to review, which can then be used to identify web applications that may need to be targeted for more thorough testing. Once the list of web applications has been generated, teams can use a tool like Burp Suite Pro with the Log4Shell Scanner plugin to identify vulnerable Log4j instances. This is accomplished by injecting exploitable strings to initiate callbacks to the user into all the dynamic elements of the web application it can map.

Target files unique to Log4j

Log4j is open source, which means its use in applications is widespread due to it being free, practical, easily distributed, and modifiable. However, the open-source nature of Log4j can also prove useful in the discovery stage. Security teams can easily download Log4j and create an inventory of all the files that are used by the package, and from there target files that are unique to Log4j.

Once this inventory is developed, security teams could leverage it with endpoint detection and response (EDR), file integrity monitoring (FIM), and configuration management tools that already exist in an organization’s security environment to identify vulnerable instances of Log4j. Additionally, in theory, the same inventory could be used as a dictionary against web servers. By utilizing this strategy, security teams can make efficient use of existing automation tools, saving time and resources that can then be used on the actual task of remediation.

Collaborate with your development teams

Security is everyone’s responsibility. To ensure an organization is truly secure, security and developer teams must work together. Comprehensive insight is needed to successfully mitigate Log4j risks. This process requires in-depth collaboration with business units and development teams to ensure that all Log4j instances are truly uncovered. In some cases, this can be a challenge when there are “black boxes” on an organization’s networks that have no clear owner.

Security teams must first work with development teams to create a list of all internally developed applications and the associated application owners. Then they must connect with the application owners and determine if a given application utilizes Log4j. For those that do, the security team and application owners will need to work together to apply the required patches. While this strategy requires a more hands-on approach, it will offer significant benefits in terms of remediating some of the more difficult to find Log4j implementations.

Shore up your vendor risk management

Third-party software providers have proven one of the main sources of cybersecurity risk for organizations over the past decade. Log4j is no exception. Security teams must communicate with vendors to determine Log4j’s relation to external applications, determine which vendors and services leverage Log4j, whether those organizations have taken the necessary steps for discovery and remediation, and whether they’ve tested their networks for successful exploitation or instructions.

Communication with vendors to this effect should be started as soon as possible so teams will know which services they might need to isolate or cease using, as well as how that might affect their organization’s functionality or services in turn.

Log4j discovery is the first hurdle

The ubiquitous nature of Log4j presents a clear challenge for cybersecurity experts, and with many security teams already short-staffed, finding all possible vulnerabilities seems like an insurmountable challenge. Establishing a discovery strategy is the first step in overcoming the challenge. With a straightforward strategy and clear communication and collaboration, teams can and will continue to protect the organizations they serve.

Source: https://www.helpnetsecurity.com/2021/12/27/log4j-discovery/