Skip to main content
Blog

Log4J Zero-Day Vulnerability

By December 20, 2021February 23rd, 2024No Comments

AWS Vulnerability -- SpinSciSecurity is paramount in today’s high-tech environment, and bad actors continue to challenge us as they seek ways to infiltrate and attack our vulnerabilities. This past weekend (December 9th) a previously unknown vulnerability was published affecting Log4J. The flaw is estimated to be present in over 100M instances across the world.

SpinSci has over 50 deployments, both cloud and on-premise, and ensuring the security of data and operations for our customers is critical. Each of our deployments consist of their own intricacies and nuances, which provides us the knowledge and experience to perform effective impact analyses and mitigations as outlined below. Security of our solutions and the associated data is a pillar of SpinSci Technologies as we move into the new year.

What is Log4J?

Log 4J is a java logging utility that is commonly distributed with Java applications. It’s an industry-standard logging utility and is widely used. It’s often used with enterprise software solutions and is a component of many cloud computing services.

 

What is the problem?

A flaw identified in Log4J is currently the most high-profile security vulnerability with a severity score of 10 of 10. The Log4J vulnerability impacts everything including the cloud, security devices and developer tools. The Log4Shell vulnerability makes use of variable substitution in the Log4J framework to craft a malicious system log message and escalate that to Arbitrary Code Execution (or ACE). Because many systems log failed requests on one level or another, this can often work without needing to successfully authenticate.

What tools, applications and devices are at risk?

Any device connected to the internet is at risk assuming it’s running Apache Log4J, versions 2.0 to 2.141. This includes software and services provided by many major solutions providers including Oracle, Cisco, RedHat, IBM, VMWare and Splunk, and cloud features from Amazon Web Services (AWS) and Microsoft Azure. Hackers are currently attempting to identify and infiltrate vulnerable devices and over 40 percent of corporate networks have been targeted.

Responses

The Cybersecurity and Infrastructure Security Agency (CISA), the Federal Agency tasked with defending against today’s modern threats, has identified the flaw as one of the most serious ever identified. CISA expects sophisticated actors to exploit the flaw and that there is limited time to take the necessary steps to limit the damage. Apache Software Foundation has released version 2.15.0 to address the flaw, and product vendors must apply the fix within their solutions and then end-users must update their devices once the fixes are available. A major challenge in mitigating the flaw is identifying software that actually harbors the Log4j vulnerability.

Many large cloud providers are already working on fixes and patches. AWS, for example, has detailed how the flaw impacts its services and has released mitigations for AWS services such as CloudFront. 

SpinSci Mitigation Response

SpinSci’s plan for resolution is as follows:

  • The standard SpinSci deployment of IVR and Agenta Middleware both use Log4J, and thus we need to ensure that potential vulnerabilities are closed. Disabling or not implementing the variable substitution feature is sufficient.
  • In the case of the Agenta Middleware, we have subcomponents:
    • The NGINX component does not use Log4J at all, so is unaffected
    • The Mirth component uses an older version of Log4J that had not implemented the features used in the vulnerability, and thus is not affected either.
    • In both cases we can verify this by inspecting the install directory of both and confirming that the vulnerable file “org/apache/logging/log4j/core/lookup/JndiLookup.class” does not occur in the install files.
  • For the IVR system, we can run the same confirmation.

In the event either of these systems DO have the vulnerable feature, we can update the log4j settings file to specifically disable the vulnerable feature, by setting the system property “log4j2.formatMsgNoLookups” to “true”. Alternatively, Log4J version 2.15.0 will also patch out the vulnerability.

To mitigate the risk posed by this vulnerability, we would like to take immediate actions as described below:

  • Update any server using log4j-core2.10 to V 2.15
  • Set jvm property -Dlog4j2.formatMsgNoLookups=true

Lessons Learned

This is not the first, nor will it be the last, opportunity for malicious actors to penetrate our technical environments. This and other prior vulnerabilities have taught us the following:

  1. As a partner we must continue to be experienced in identifying and following the appropriate mitigations protocols in an extremely short timeline
  2. We must continue to leverage our agility in being able to rapidly identify the various environments that could potentially be impacted and understand how to apply an associated fix or mitigation, and
  3. We must continue to be strong communicators and keep our clients informed with rapid impact analyses followed by comprehensive plans addressing mitigation

References

Leave a Reply

WordPress Lightbox
demo request