Log4j: A Year in Review

As we approach the first anniversary of Log4j, it is a good time to revisit the importance of analyzing supply chain security, as well as third party vendor management. Log4j impacted almost everyone. On November 24, 2021, a security researcher from the Alibaba Cloud Security team reported the Log4j vulnerability to the Apache Software Foundation (ASF). After discovering reports of active exploitation the ASF escalated the release of version 2.15.0. The vulnerability was publicly announced on December 10, 2021. This kicked off a mad dash by defenders to identify and remediate the vulnerability within their environments. Further complicating the issue were releases of bypasses and new vulnerabilities in the fixed versions. 

The Cyber Safety Review Board (CSRB) released a report in July 2022 calling Log4j an, “endemic vulnerability” because it will remain in systems for many years to come. CISA recommends that organizations continue to evaluate to ensure they have found and remediated all instances that could exist within their environments. They also have laid out recommendations for longer-term vulnerability management planning and have published the CISA log4j vulnerable software database. For those who cannot apply a patch, CISA has provided mitigation recommendations. 

In November 2022, the US-China Economic and Security Review Commission released their annual report to Congress. In Chapter 3, Section 2, the report provides details on China’s cyber capabilities and discusses their use of vulnerability exploitation. China has regulations in place forcing companies and security researchers to provide them with details of zero-day vulnerabilities prior to making them available to companies or publicly. Alibaba was sanctioned by the China government with no explanation given by the People’s Republic of China (PRC) government. It’s suggested that Alibaba was sanctioned because they did not disclose to PRC prior to ASF. 

In October 2022, a joint Cybersecurity Advisory was released by NSA and CISA that provided the top common vulnerabilities used by the PRC. The Apache Log4j vulnerability tops the list of most used CVEs by Chinese state-sponsored cyber actors since 2020. With how broad Log4j was as a vulnerability it’s hard to determine how much exploitation actually occurred and will continue to occur. We do know that China exploited the vulnerability and that they have a history of exploiting and waiting to take advantage of their newfound access.

Log4j is just the tip of the iceberg. Similar issues have emerged over the past year, though not as impactful as Log4j. If an attacker can find other vulnerabilities within components that are popular and widely used within applications, the impact is significant, supplying them with a great deal of bang for their buck. As a result, attacks in open source software have become an obvious target for researchers and nefarious actors in the wild and we will continue to see this as a trend in application security. 

Organizations and governments are devoting more funding and resources into researching, analyzing and remediating vulnerabilities within open-source code. Having a good inventory of the components, dependencies and libraries in a given environment will make responses to vulnerabilities, like Log4j, a much smaller affair. Software Composition Analysis (SCA) is a tool that helps organizations accomplish this goal. Some organizations who are just beginning to implement an internal Application Security Program and focus their development efforts on writing modern applications may opt to implement SCA before SAST (Static Application Security Testing) or DAST (Dynamic Application Security Testing). 

As we have done presentations and traveled around the country to meet with clients over the past year, we have polled audience members about their experiences with Log4j. Typically when asking an audience who had to deal with Log4j, most of the hands in the room go up. When we asked them how many classified Log4j as an AppSec issue at its root cause, at least half of the hands in the room tended to go down. The organizations who recognized that Log4j impacted more than just Commercial Off-the-Shelf (COTS) solutions were better enabled to find where Log4j might exist within applications and repositories. Those who also had software composition analysis tools were able to scour their code repositories for the issue and were most successful in addressing the zero-day. 

It should be noted that this is a more reactive approach. Once a tool is in place and an inventory better known as a Software Bill of Material (SBOM) has been created, an organization can move to a more proactive approach. After evaluating the inventory and deciding which open-source components are acceptable, secure and up-to-date, this list can be published illustrating what is approved for use. A process can then be put in place for developers to request new components to be included in the list. The approved list will require maintenance as those secure and up-to-date components may one day become outdated and/or vulnerable. 

As noted above, open-source components that are widely used are a perfect target for attackers. Statistics say that 80-90% of modern applications are made up of these dependencies, so if an attacker can find a significant vulnerability within a commonly used component, they can execute an attack with an extremely profound impact. This might be why we are starting to see SBOMs as an emerging requirement for regulatory compliance frameworks. Without these inventory lists, open-source components, libraries and dependencies are difficult to identify and track. Software composition analysis tools are an essential part of an organization’s defense in-depth toolbox.