FAQ about the Log4j vulnerability

In this article:

SecurityScorecard is committed to helping you assess the potential impact of the Log4j vulnerability to your organization and to third parties whom you interact with. Read the following frequently asked questions (FAQ) about the vulnerability, how we are responding to it, and what you can do to keep your organization safe. We will update this FAQ as the situation develops.

Also, learn about our informational issue types for the Log4j vulnerability.

FAQ

• What is Log4j, and what is the vulnerability? 
• Why is this flaw so concerning?
• What actions has SecurityScorecard taken with its platforms?
• What actions should I take now?
• Is SecurityScorecard able to identify who has this vulnerability?
• How does SecurityScorecard detect Log4j with these new signals?
• Are we adding a new CVE into the platform?
• How can I see whether the Log4J issue has been detected in my environment?
• How can I see if a Log4j issue has been detected in a third party's environment?

What is Log4j, and what is the vulnerability? 

On December 10, 2021, a serious flaw was discovered in the widely used Java logging library Apache Log4j. The vulnerability, Log4Shell, was first identified by users of a popular Minecraft forum and was apparently disclosed to the Apache Foundation by Alibaba Cloud security researchers on November 24, 2021.

The nature of the vulnerability is a malformed event string that can take advantage of default security settings to permit remote code execution. The vulnerability has the potential to allow unauthenticated remote code execution (RCE) on nearly any machine using Log4j. An RCE exploit enables an attacker to remotely execute commands on a victim's computing device.

Initially released in 2001, the open-source Log4j utility has become integral to popular frameworks such as Apache Struts2, Apache Solr, Apache Druid, and Apache Flink. 

Why is this flaw so concerning?

Cybercriminals can exploit RCE vulnerabilities to gain unauthorized access to your systems and applications, including phones, tablets, workstations, smart TVs, thermostats, and other devices. These actors can use this access to take control of your system remotely. 

Log4j is widely used, so the discovery of its RCE vulnerability is a legitimate “red alert” situation for the cybersecurity community. Log4Shell has the potential to be the most dangerous and impactful exploit since the Shellshock vulnerability was discovered in 2014.

Has SecurityScorecard taken appropriate action with its platforms?

We worked to remediate our potential exposures on Friday, December 10, 2021. We quickly reviewed our code repositories and transitive dependencies in order to understand our exposure. After this assessment, we concluded that we no longer had any further actions to take, other than reaching out to our SaaS vendors and service providers to query their exposure as third-party risk for SSC.

What actions should I take now?

As the situation develops, SecurityScorecard is committed to helping you assess the potential impact to your organization and your third parties. Take the following five steps right away: 

1. Check if your organization is impacted.
   Any asset is probably impacted if it runs a version of Log4j later than 2.0 and earlier than 2.17.1, the fixed version release. Review your most recent vulnerability scan results, which likely contain the location of any Log4j installations active within the environment. You can also query cloud application logs for strings matching the syntax jndi.ldap. This will identify any instances of scanning or active exploitation attempts.

   Note: A system is only potentially compromised if the request was processed by a vulnerable version of Log4j. Otherwise, the activity should not be considered suspicious.
   

2. Update to Log4j version 2.17.1 immediately.
   Find the latest version on the Log4j download page. Version 2.17.1 requires Java 8 or later, so make sure Java is running this version.

   Important: Verify that multiple Log4j installations are not present on an impacted machine, as this can mean that multiple configuration files exist. Each of these can contain a vulnerable version of Log4j. You will need to remediate each independently.
   

3. Send our Log4Shell questionnaire to your third parties with Atlas.
   A new questionnaire template titled Log4Shell Questions is now available in Atlas. If you already have Atlas, you can send this questionnaire to your third parties right away. If you do not have Atlas, sign up at atlas.securityscorecard.io or watch this video, and take advantage of five free credits that you can use to send questionnaires. 
4. Use the questionnaire to let your business partners know you are engaged.
   Leverage Atlas to proactively fill out the Log4Shell questionnaire for your own organization and share it with your business partners, letting them know what your organization is doing to address the situation. This is free and available to all SecurityScorecard customers. 
   
5. Prioritize this threat stream.
   Follow CISA guidelines to install a web application firewall (WAF) with rules that automatically update, so that your security operations center (SOC) can concentrate on fewer alerts. 
   

Is SecurityScorecard able to identify who has this vulnerability?

We have a released two issue types related to the discovery of the vulnerable Log4j version. See the following three FAQ to learn how they works.

How does SecurityScorecard detect Log4j with these new signals?

For Vulnerable Log4j version detected:

We identify the presence of Log4j in an HTTP response and the HTML raw body.  Log4j is not an application, but a library that many applications depend on. So, the detection is not as straightforward as product or service identification. Because Log4j is a static library linked to applications through configuration files, it is not always known if the application uses it. Instead, we detect through metadata whether it is present and exposed.

For Product running vulnerable Log4j version:

We identify products on your network that have been confirmed to be running vulnerable versions of Log4j, according to vendor advisories that we monitor. Our team reviews a list of impacted applications to identify whether they are visible from the outside-in. We combine these findings with extended metadata in our scanning infrastructure. 

Are we adding a new CVE into the platform?

Not at this time. CVE detection requires identification of a vulnerable product and version. Because this signal depends on identifying the presence of Log4j in HTTP content, there is no specific product to link a CVE detection to.

How can I see whether the Log4J issue has been detected in my environment?

Look for one of the following informational issue types in your Scorecard:

• Vulnerable Log4j version in the Application Security factor
  
  
  
  
• Product running vulnerable Log4j version in the Network Security factor
  
  
  
  

How can I see if a Log4j issue has been detected in a third party's environment?

In any of your portfolios, search for issue type names that include Log4j.

Affected Scorecards are included in the search filter.