Log4j – First Year Anniversary ! Lesson Learned -Importance of Software Supply Chain Risk

The first anniversary of Log4j is about to come later in this week, this is a good time to revisit the importance of analyzing supply chain security, as well as third party vendor management. Log4j impacted almost everyone in the IT industry.

Initial Havoc

On November 24, 2021, researchers 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 wild run for the 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 efforts of security practitioners were high during the period following Log4j’s discovery. But as time went on, it became evident that despite that the Log4j threat wasn’t going anywhere.

Vulnerability Exploitation by Threat actors

The flaw first gained popularity as Log4Shell following the release of a patch by the video game maker Mojang Studios to its MineCraft game on December 10, 2021.

According to Check Point, on December 13, 2021, just 72 hours after the release of the patch, there were more than 800,000 attempted attacks seeking to exploit the vulnerability. Emergency patching of the vulnerability became the only option if organizations had any hope in protecting themselves.

By January of 2022, Microsoft warned of continued attempts by nation-state actors and cybercriminals to exploit the vulnerabilities found in Log4j to deploy malware on vulnerable systems. China-based group that exploited the vulnerability in some versions of the VMware Horizon server to gain initial access, allowing them to eventually install the NightSky ransomware.

An Iran-linked threat actor known as APT35 exploiting the Log4j vulnerability to deploy modular, PowerShell-based malware. Attempts by APT35 using this same tactic were made on more than 150 organizations.

Array of Advisories from Government agencies

In July 2022, The Cyber Safety Review Board  released a report calling Log4j an endemic vulnerability. Since it will remain for years, organizations should  continue to evaluate to ensure they have found and remediated all instances that could exist within their environments. Log4j database should be kept handy for all present and future vulnerability management.

In October 2022, a joint advisory was released by NSA and CISA that provided the top common vulnerabilities used by the People’s Republic of China. The Apache Log4j vulnerability tops the list of most used CVEs by Chinese state-sponsored cyber actors since 2020.

In November 2022, the US-China Economic and Security Review Commission released their annual report. 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.

Importance of Securing Open-Source Software

Log4j is just like tip of the iceberg. 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 criticality.  

Open-source software attacks have become popular and an obvious target for researchers and nefarious actors in the wild. 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 each environment will make responses to vulnerabilities.
• Importance of having a SBOM, become popular among organisations. This will make proactive while facing these types of attacks in future.
• Using SBOM only approved set of components will be used. Continuous updates and monitoring will be in place for the components and libraries.
• Organizations who were started to implement an internal Application Security Program and focus their development efforts on writing modern applications may opt to implement Software Composition Analysis (SCA) before SAST (Static Application Security Testing) or DAST (Dynamic Application Security Testing).

Many development organizations may not have an appetite for increased scrutiny of their supply chain. However, changing government rules and regulations mean that the changes wrought by the Log4j vulnerability may be mandatory, rather than optional.

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.

Final Thoughts

The threat related Log4j will persist, and other zero-day vulnerabilities could arise in the future, the industry is positioning to handling such software supply chain risks. As with other major security vulnerabilities and attacks, Log4j and Log4Shell will have a mixed legacy, fueling attacks. But the threat raises the profile of threats to the  software supply chain in ways that could leave organizations better prepared to identify and fend off such attacks.

Here at TheCyberThrone, Since from the initial days of the vulnerability became popular we have covered more than 80 articles across vendors about the exploitation by threat actors, mitigations, remediations. This will be continued

This brings end of this coverage. Thanks for visiting TheCyberThrone. If you like us please follow us on Facebook, Twitter