Cybersecurity experts are warning about a newly discovered software vulnerability, called Log4j, which poses a security risk to businesses that may be using the software or cloud services that include the software. In this podcast, Acceleration Economy analysts Aaron Back and Chris Hughes, who is a cybersecurity expert and CISO, assess the nature of the immediate threat and how businesses should respond.
Log4j is a remote code execution (RCE) vulnerability that, if left unmitigated, enables a malicious actor to execute arbitrary Java code to take control of a target server. It is easy to exploit and doesn’t require authentication. It can allow malicious actors to execute software or insert backdoors on systems to maintain persistent access.
The vulnerability was patched in Log4J v2.15.0 by Apache. One of the leading recommendations is to upgrade to Log4J 2.15.0 if possible.
01:50 – The vulnerability is called Log4Shell or CVE-2021-44228. It is technically categorized as improper input validation, and places too much trust in untrusted data from an external source. It is a vulnerability in the Apache Log4j2 Java-based logging library. It was originally made public last week, but it has been disclosed that it was being exploited for some time prior to the reported discovery.
02:35 – It is impacting all Log4j versions before 2.15.0. Part of the reason that is so concerning is due to how widespread the use of it is. Advisories and bulletins have come out from some of the largest tech companies in the world, such as Apple, Amazon, Microsoft, VM and others. This emphasizes how one vulnerable software component can have a cascading impact across the IT ecosystem and beyond.
03:30 -The log4j vulnerability also highlights the fragility of the open-source software ecosystem. Despite being used by millions of people and countless software vendors, the Log4j project is maintained by a group of volunteers as part of the nonprofit Apache Software Foundation.
06:05 -The Cybersecurity and Infrastructure Security Agency (CISA) has created a dedicated page capturing some of the relevant guidance for mitigating and addressing the vulnerability. Their guidance includes aspects for both software vendors and consumers. For vendors, the guidance is to immediately identify, mitigate and patch affected products that use Log4j. They’ve also recommended that vendors notify impacted customers of the vulnerable software and ask them to implement available updates. This is exactly what we have seen many vendors do, including the leading Cloud Service Providers.
06:50 – For impacted organizations, the guidance includes identifying external-facing devices that have Log4j present, ensuring the SOC is alerting on these impacted systems, and implementing Web Application Firewall (WAF) rules to address it. Several CSP’s and security vendors have released pre-configured WAF rules to identify attempts to exploit it and potentially block it as well.
07:00 – Log4j is used by countless software products and organizations, impacting millions of users. It will be months or even years before all of the impacted software products or services that use the vulnerable versions of Log4j are updated.
08:20 – This highlights how fragile the software ecosystem is, with widespread use of open-source software often maintained by unpaid volunteers. There’s increased talk of the need for a Software Bill of Materials (SBOM), which helps provide insight into what software components are being consumed.
09:10 – Also, the need for the software maintainers, especially of widely used and critical software components, to be paid through various approaches, to try and mitigate the likelihood of these sorts of scenarios. Organizations such as Tidelift are looking to provide software consumers visibility into the software they are consuming, associated Software Bills of Materials, the health and risk of the projects they use and more. They provide recommendations for the software package organizations are using and opportunities to drive down risk based on this actionable insight.