The outbreak of Log4j2 vulnerability has caused an uproar all over the world, with a wide range of influence and great harm second to none. The event is a typical supply chain event caused by open source software. The vulnerability of upstream software affects the products of downstream industries. The complex dependency expands the scope of influence and eventually spreads throughout the whole cyberspace. The Log4j2 incident has sounded an alarm to network security manufacturers and relevant practitioners. We must be alert to the hidden crisis in the supply chain of open source software and take actions.
This article analyses how the Log4j2 vulnerability is introduced and the far-reaching impact on the whole software life cycle from the perspective of supply chain. By analyzing the secondary propagation of Log4j2 in open source components, we clarify the infection path of Log4j2 vulnerability and possible attack scenarios based on this. The addition of open source software brings new challenges to software supply chain security, which calls for efforts of all parties to build an effective supply chain security scheme.
Impact of Log4j2 vulnerability at all stages of software supply chain
As a basic log library comparable to a standard library, Log4j2 is relied on directly or indirectly by countless open source Java components. The vulnerability of a core original component in the software supply chain itself has the most direct, concealed and far-reaching impact on the whole software supply chain.
In the stage of component integration build, when log4j2 is integrated into some core business components as a basic component, the vulnerability is also intentionally or unintentionally spread to the higher-level core business, exposing the business to an additional attack. At this stage, thanks to the clear dependency relationship between components, it is easy to check the attack surface when vulnerability is introduced. Generally, We only need to upgrade the affected component version to a secure patch version or directly replace it.
In the stage of dependent use of component, with the increasing complexity of software system architecture, the dependency between components is also increasing. When core components, such as log4j2, are affected by vulnerabilities, the complexity of software system will mask the impact, resulting in the attack surface being hidden and easily ignored. Therefore, it is the most difficult to troubleshoot the impact of vulnerabilities at this stage. It often requires security engineers to conduct large-scale analysis and investigation to sort out the complex dependencies of the software system. The same is true from the perspective of attack and defense. Attackers and defenders often need to test the call depth of components through hook, fuzz and other methods, so as to find out the hidden vulnerability trigger point.
In the use stage of downstream users, the impact is more passive. Complex software system is like a black box for downstream users who know nothing about the risks of the components. Only responsible software providers can provide operation and maintenance support services. In case of irresponsible or untimely vulnerability response suppliers, users can only rely on community suggestions and bypass safety equipment for temporary mitigation.
Analysis of log4j2 vulnerability propagation channels
According to the way log4j2 vulnerability components are introduced, it can be classified into two cases: direct dependence and indirect dependence. The former refers to the direct use of log4j2 as logging framework during project development; The latter refers to the use of log4j2 by third-party components or frameworks, so that vulnerable components are introduced into the project indirectly.
Compared with those in direct dependence, vulnerability components in indirect dependence are less likely to be known by developers and thus less likely to be fixed. According to the software supply chain report released by Sonatype in 2020, open source components are used more frequently in projects, but the proportion of open source components that developers can detect decrease significantly.
At present, we have noticed that many components in Maven library are affected by this vulnerability. In addition, many independent frameworks and applications are also affected. In order to study the secondary propagation path of log4j2 vulnerability, NSFOCUS research team made statistics on some affected projects in Maven warehouse. According to the existing statistical data, we find that the secondary propagation of log4j2 vulnerability mainly depends on open source frameworks and components.
Potential impact of log4j2 vulnerability on downstream of supply chain
The vulnerability covers a wide range and does serious harm, so all areas should be focused. In order to protect the operation of business and the security of assets, users in all fields should be aware of the seriousness of the vulnerability and troubleshoot the potential impact in time. At the same time, in the face of complex assets, we should distinguish the priorities, and gradually get rid of the vulnerability threat from those with high impact on the business. The following are typical cases in several scenario to help security practitioners minimize the possible impact of vulnerabilities on the downstream of the supply chain.
Security products
As enterprise’s armors against vulnerability intruders, security products protect the enterprise’s assets all the time. Once the protection of security products is lost, the enterprise assets are easy to be obtained. In addition, some security products have the authority to monitor and control enterprise assets. If compromised, they will help attackers further expand the harm.
The cloud product GravityZone Cloud in Bitdefender contains the risk of being attacked by Log4j2 vulnerability. The product can centralize the management of hosts in cloud environment. Once it is attacked, the attacker will directly take over the whole cloud environment.
Big data
Data is often the primary target of attackers’ intrusion. Big data platforms often contain great amounts of users’ privacy data. The leakage caused by the fall of platforms will have an immeasurable impact.
ElasticSearch, a powerful open source database, is widely used in various enterprises and organizations for its fast search speed and flexible configuration, and thus stores huge amounts of data. In October and December 2019, ElasticSearch exposed to the public network was not configured with password protection, resulting in the disclosure of billions of user information. The plug-in XenForo Enhanced Search of ElasticSearch5 and above versions include available Log4j2. If attackers exploit the Log4j2 vulnerability, it will lead to the fall of ElasticSearch databases, resulting in massive data disclosure.
Virtualization Platform
The virtual containers deployed in virtualization products often contain some important user businesses. Once the virtual container is attacked, it will cause business interruption or data leakage and encryption. What’s more, if the management service in the virtual platform is attacked, it will lead to the fall of the whole virtualization platform.
As the core component of VMWare vSphere cloud computing infrastructure virtualization platform, VMware vCenter can centralize the management of VMWare vSphere environment. On March 14, the blackmail virus attack against VMware virtualization environment affected the production business of a large number of users in virtual machines, and the data of some Windows systems were also encrypted. Once attackers can successfully exploit the Log4j2 vulnerability to attack the vCenter server, they can manage all virtual machines in the virtual environment through the vCenter server, resulting in business interruption or data disclosure.
Software supply chain security calls for action of all parties
Developers of open source software should have the ability to collect vulnerability information, define the scope of impact and provide patches in time. However, maintainers of open source software are often tired of maintaining, and have no time to take into account the potential security risks. In this event, only three community contributors of Log4j2 project team worked on open-sourcing and bug fix to maintain this vital project. Making the role of open source project maintainer professional and taking effective measures to ensure supply chain security in the process of project development are the only way to ensure the security of open source software supply chain.
When selecting open source software, enterprises should pay attention to developers’ capabilities, which also derives capability evaluation services and capacity building services. Some of these services can be from security companies and purchasing SaaS services provided by distributors (such as Vulnerability Intelligence).
Distributors should establish direct contact with developers and users, provide updated patches and the latest fixed versions timely, and notify users to update. In this sense, the capacity building and evaluation of distributors are also important.
After receiving the vulnerability information, users should fix in time. Here, a user may be a software integrator developing with open source components, so the capacity building and evaluation of software integrator are necessary as well.
Therefore, vulnerability threat intelligence, software supply chain security capability assessment of all parties, vulnerability closed-loop management, and security capability platform construction will be general supply chain security solutions to some extent.
Summary
The introduction of open source software not only reduces the development time, but also increases the complexity of software supply chain security. Widely used basic components, such as Log4j2, have a deep impact at all stages of the supply chain. The complexity of dependencies, in terms of quantity and levels, increases the difficulty of vendors in troubleshooting vulnerabilities. The secondary propagation caused by open source components and frameworks that indirectly depend on vulnerable components greatly expands the impact scope of Log4j2 vulnerability. The cumulative impact of vulnerabilities in upstream software supply chain products will eventually emerge in downstream application scenarios. Downstream product service providers should take effective measures to troubleshoot assets involving vulnerabilities.
The complex multi-level dependence in product development and the complexity of customer assets all call for an effective solution. At present, NSFOCUS ‘s code security audit product SDA can accurately detect the remote code call vulnerabilities in Log4j2 components in versions from 2.0 to 2.15-rc1 through multi-dimensional BOM analysis technology and rich vulnerability knowledge base, so as to prevent the vulnerabilities from being exploited in the code.
