Apache Log4j 2, a Java-based logging library, was affected by a zero-day vulnerability on December 9, 2021. The vulnerability, known as Log4Shell and identified by the National Institute of Standards and Technology (NIST) as CVE-2021-44228, allows cybercriminals to take control of vulnerable systems and servers.
Many web applications, open-source cloud platforms, and service providers utilize Log4j. This widespread use could expose your organization’s internal attack surface and third-party ecosystem to the Log4Shell vulnerability. To secure critical systems and data effectively, your organization needs to assess its internal use of Log4j and its vendor’s use of the logging library.
Keep reading to discover 11 questions your vendor risk management team can use to determine how vendors use Log4j across your third-party supply chain and how this could impact your organization’s security posture.
Learn more about UpGuard Vendor Risk: the world’s #1 vendor risk management solution>
Summary of the Log4Shell Vulnerability
In December 2021, security researchers announced a critical security flaw in the Apache Log4j framework, allowing malicious hackers to compromise vulnerable systems through a single code injection.
During the first days of impact, security researchers identified approximately 10 million Log4Shell exploitation attempts every hour. Various industries are vulnerable to Log4Shell because many digital products and software, including Microsoft and IOS applications, utilize Java.
The retail industry was the most affected by the Log4Shell vulnerability, but other sectors, including technology, financial services, manufacturing, and healthcare, were also affected.
Patching the Log4J Vulnerability
Apache began developing a patch for Log4Shell quickly after it became aware of the vulnerability in December 2021. However, Log4j still presents significant security risks, given its widespread use.
Any version of Log4j 2 earlier than 2.17.1 is vulnerable to the Log4Shell vulnerability. To effectively protect themselves against this vulnerability, organizations must address any vulnerable version of Log4j 2 in use across their internal infrastructure and third-party ecosystems.
Security teams can follow the following protocol to address the vulnerability:
- Update to the latest version of Log4j 2
- Run vulnerability scans using a scanner
- Update Java system properties
- Disable JNDI
- Send an Apache Log4j questionnaire to vendors
- Employ multi-factor authentication
Recommended Reading: Log4Shell: The Log4J Vulnerability Clearly Explained
Related Log4J Vulnerabilities
While Apache worked to resolve the Log4Shell vulnerability, researchers and threat actors discovered additional flaws in various versions of Log4j. NIST has identified these flaws with the following codes:
- CVE-2021-45046: Allows cybercriminals to send malicious JNDI lookups, present in Log4j 2.15 and below
- CVE-2021-45105: Allows cybercriminals to deploy denial-of-service attacks through malicious messages, present in Log4j 2.16 and below
CVE-2021-44832: A remote code execution vulnerability (RCE) that allows hackers to exploit systems with arbitrary code if they have elevated permissions, present in Log4j 2.17 and below
11 Apache Log4J Questions To Ask Your Vendors
Security questionnaires are one of the most effective ways an organization can evaluate the security posture of its third-party vendors. Your organization can use the following 11 questions to create a security questionnaire to identify any outdated versions of Log4j across its entire vendor ecosystem.
Discover UpGuard’s robust security questionnaire library>
1. Does your organization run any version of Log4j 2?
- Yes
- No
- [Open text field for vendor comments]
2. Has your organization updated to Log4j 2.17.1 as the Apache Software Foundation and CISA recommended?
- Yes, the organization has updated to Log4j 2.17.1
- No, the organization is unable to update to Log4j 2.17.1 (please explain below)
- The organization has not yet updated to Log4j 2.17.1
- [Open text field for vendor comments]
3. If no, what version of Log4j 2 does your organization currently run?
- The organization utilizes a version of Log4j 2 between 2.7 and 2.14.1 (proceed to question 3)
- The organization utilizes a version of Log4j 2 between 2.0-beta9 and 2.10.0 (proceed to question 4)
- The organization utilizes Log4j 2.17.1
4. If your organization utilizes a version of Log4j2 between 2.7 and 2.14.1, have the following mitigation efforts been implemented:
a) Either the system property, log4j2.formatMsgNoLookups, or the environment variable, LOG4J_FORMAT_MSG_NO_LOOKUPS, have been set to true
AND
b) All PatternLayout patterns have been modified to %m{nolookups} instead of just %m
- The organization has implemented precaution a)
- The organization has implemented precaution b)
- The organization has implemented precautions a) and b)
- [Open text field for vendor comments]
5. If your organization utilizes a version of Log4j2 between 2.0-beta9 and 2.10.0, have the following mitigation efforts been implemented:
a) Either the system property, log4j2.formatMsgNoLookups, or the environment variable, LOG4J_FORMAT_MSG_NO_LOOKUPS, have been set to true
AND
b) The JndiLookup class has been withdrawn from path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
- The organization has implemented precaution a)
- The organization has implemented precaution b)
- The organization has implemented precautions a) and b)
- [Open text field for vendor comments]
6. Did your organization use CISA’s GitHub repository to identify assets vulnerable to Log4Shell?
- Yes
- No
- [Open text field for vendor comments]
7. Has your organization identified any indicators of compromise (IOCs) resulting from the Log4Shell vulnerability?
- Yes (please list below)
- No
- [Open text field for vendor comments]
8. How did the Log4Shell vulnerability impact your organization?
- The vulnerability didn’t affect the organization, and we were not exposed to any cyber attacks or security issues resulting from the vulnerability
- The vulnerability moderately affected the organization, but no critical systems, infrastructure, services, or data were impacted (please explain below)
- The vulnerability directly affected the organization’s critical systems, infrastructure, services, and/or data (please explain below)
- [Open text field for vendor comments]
9. Does your organization have an incident response plan to respond to cyber threats?
- Yes, the organization has an incident response plan in place
- The organization is in the process of finalizing a dedicated incident response plan
- No, the organization does not have an incident response plan in place
- [Open text field for vendor comments]
10. How often does your organization deploy in-depth risk assessments to appraise internal security vulnerabilities?
- Annually
- Every six months
- As needed, or we do not have a scheduled cadence for risk assessments
- [Open text field for vendor comments]
11. Who is your organization's point of contact to field additional questions and queries?
- Name:
- Title:
- Email:
- Phone:
- [Open text field for vendor comments]
How To Remediate Vendor Risks
If your organization deploys an Apache Log4j security questionnaire and finds a vendor is running a vulnerable version of Log4j 2, you must fix the risk immediately. Your organization should prioritize remediation efforts based on vendor criticality if multiple vendors are exposed.
Depending on the vendor’s level of security awareness, your organization may need to work alongside the vendor’s security team to deploy necessary updates and remediation protocols.
Your team can follow the following remediation workflow upon identifying an exposed vendor:
- Communicate with the identified point of contact and request remediation
- Suggest mitigation procedures, such as removing JNDI lookups, updating to the latest version of Log4j, using CISA’s GitHub repository to inventory vendors, and others recommended by Apache and CISA
- Communicate expectations, timelines, and advisory consequences for remediation failure
- Send a new security questionnaire to verify the risk has been remediated
Recommended Reading: Choosing Automated Vendor Risk Remediation Software in 2024
How Can UpGuard Help With the Apache Log4J Vulnerability
UpGuard is a cybersecurity company dedicated to helping security teams protect their internal and third-party attack surfaces. UpGuard’s two products, Vendor Risk and BreachSight, allow organizations to improve their cyber hygiene, appraise the security posture of individual vendors, and deploy robust vendor risk management and cyber risk management protocols.
UpGuard’s vulnerability scanning and vulnerability assessment capabilities allow organizations to identify various vulnerabilities that could impact their security posture and lead to cyber attacks such as malware or ransomware.
UpGuard Vendor Risk and BreachSight include the following features:
- Data leak detection: Protect your brand’s reputation, intellectual property, and customer data with timely detection of data leaks
- Continuous monitoring: Get real-time updates and manage exposures across your attack surface, including domains, IPs, apps, endpoints, plugins, and firewalls
- Attack surface reduction: Reduce your attack surface by discovering exploitable vulnerabilities and domains at risk of typosquatting
- Shared security profile: Create an UpGuard Trust Page to eliminate the hassle of answering security questionnaires
- Workflows and waivers: Streamline remediation workflows, quickly waive risks, and respond to security queries
- Reporting and insights: Access tailor-made reports for different stakeholders and view information about your external attack surface
- Vendor Security questionnaires: Automate security questionnaires to gain deeper insight into your vendor relationships and third-party security posture
- Security ratings: Appraise the security posture of individual vendors by using our data-driven, objective, and dynamic security ratings
- Risk assessments: Streamline risk assessment workflows, gather evidence, and quickly request remediation
