Log4j: Meet the new zero-day, same as the old zero-day

What is the Log4j issue?

The Apache Log4j 2 utility is a commonly used service component for logging requests for audit and review purposes. Log4J, written in Java, supports many projects, including multiple cloud services and various open-source and commercial enterprise products.

On December 9, 2021, a vulnerability was reported that could allow a system running Apache Log4j version 2.15 or below to be compromised, allowing an attacker to execute arbitrary code on the vulnerable host. For example, an attacker could include the exploit string as a user agent in an HTTP request. If the web application logs the user string using Log4j, Log4j can be exploited to connect with the attacker’s server, downloading additional code that the service will execute.  Here is a detailed image that lays out the threat and compensating controls:

The Cybersecurity and Infrastructure Security Agency (CISA) has indicated that all critical infrastructure operators patch or remediate this vulnerability immediately.  Censinet is actively following the security vulnerabilities in the open-source Apache “Log4j 2″ utility (CVE-2021-44228 and CVE-2021-45046)

Who is Affected by this issue?

Systems and services that use the Java logging library, Apache Log4j 2 between versions 2.0-beta9 and 2.14.1, are all affected. Log4j 2 is built into popular frameworks, including Apache Struts2 and others. As this library is widely adopted, many third-party apps are likely vulnerable, revealing a vast attack surface.  

The Apache Foundation has released Log4j 2 Version 2.17.0 to address the vulnerability. Users and administrators are prompted to review the  Apache Log4j 2 2.17.0 Announcement , upgrade to Log4j 2 version 2.17.0 or greater, or apply the recommended mitigations immediately.  

CISA further recommends asset owners take three additional, immediate steps regarding this vulnerability:  

• Enumerate any external-facing devices that have Log4j 2 installed.  
• Ensure that your security operations center (SOC) is actioning every alert on the devices that fall into the category above.  
• Install a web application firewall (WAF) with rules that automatically update so that your SOC can concentrate on fewer alerts.

How should we address this now and well into the future?

This vulnerability is not a new phenomenon, as zero-day exploits have become the norm.  The relatively easy-to-use open source community is prevalent across many third-party applications.  As such, Log4j is included in many packages and distributions, meaning you’re going to have to work to make sure that it’s updated everywhere.  The most immediate focus area should be any externally facing entry point, particularly where embedded and you’re reliant on a third-party or downstream source’s update.

For Vendors

Vendors must assess the vulnerability’s potential impact on any third-party or downstream products and services that they use or embed within their products and services.  Healthcare providers are asking their third-party vendors if they are exposed to this vulnerability and assess the risk of using third-party products supplied to them, whether for clinical or business operations.  You should continually communicate with your customers to inform them of the status of your mitigation and remediation efforts.  Do this even if it’s just to let them know that you’re awaiting patching confirmation from your downstream vendors and will be executing your validation steps to confirm remediation.  Equally, it is vital to communicate that an assessment has been done and no problems exist.

For Healthcare Delivery Organizations

If you have an asset inventory of your products and services:

• Reach out to those downstream vendors
• Identify who is responsible for remediating this vulnerability
• Ask them to provide the current status to address this vulnerability.  
• Determine if  they updated to the latest Log4j version
• Find out if the remediated version is the one you consume, whether in the cloud or on-premises

What’s the long-term response to these types of situations?

This response comes down to following your Incident Management process – analyze and research, contain, eradicate and escalate to internal parties and stakeholders. Distill feedback and learnings from the process into your incident management playbook for this type of widespread and complex vulnerability.  Staying on top of these types of risks requires you to maintain an asset inventory and identify those 3rd party applications, services, and devices that have the potential to be affected – think cloud vendors, data exchange vendors, on-premises software, and hardware that logs events, etc. Build your list of potential vendor/product threat vectors and research if they’ve either made public statements or direct communications to their customers to indicate what steps they’re taking to mitigate and remediate the issue.

This process becomes the foundation for your risk management program, a dynamic process that’s not set it and forget it!  Assess your vendors regularly to ascertain risk-based insights into the potential for exposure to these types of vulnerabilities.  Does this vendor/product have network access? Who’s using it? Is sensitive data involved like PHI? Is this a mission-critical product or service embedded in your clinical workflows or business operations?  Then prioritize which 3rd parties you should address first.

The Censinet Response

Censinet can track Log4j status directly in our Censinet RiskOps platform for every third-party vendor product assessment through our vendor data and access capture forms.  With Censinet, you have an electronic inventory of all third-party vendors and products, which you can quickly use to identify a prioritized target list.

You can also indicate if a product has Log4j, is impacted by the vulnerability,  and the status of any necessary actions using a curated list of mitigations and remediations from across our network. Additionally, you can track common mitigations such as Network Isolation so that you can return in the future to complete the remediation of systems you previously isolated.

All of this information is then available for reporting across the platform by simply identifying Log4j impacted vendors using filtering criteria such as “contains PHI” or “has access to our network.” You can then determine whether the vulnerability has been fully remediated or mitigated by additional controls that give you actionable information and insights.  

Where do we go from here?

Cybersecurity professionals clearly need to work more closely with application developers to understand better what open source components may exist within an application. It’s time we leverage software bills of materials (SBOMs) that, as part of a set of DevSecOps best practices, facilitate rapid response to vulnerabilities such as Log4J. Otherwise, the sheer number of vulnerabilities discovered will simply overwhelm developers as they attempt to strike a balance between adding new application features and prioritizing vulnerability remediation all at once. Fortunately, there are platforms, such as Censinet RiskOps, to help the process and some open source tools to inspect your products.

Chris Logan
SVP & CSO, Censinet