Many cyber-attacks and security breaches made the headlines last year (SolarWinds, Kaseya…). But that was almost nothing compared to the Log4Shell vulnerability present in the Java open-source Apache logging library Log4J that was revealed in early December and sparked a coordinated response from several US agencies (NSA, FBI, CISA…). This dismay is not disproportionate as Apache is the world’s largest opensource foundation and notably backing one of the most important global server networks.
Already exploited and affecting thousands of services and applications (Google, Apple, Tesla…), the flaw can allow a remote execution of arbitrary code by an attacker without login credentials. The possibility to conduct remote code execution opens the door to the whole array of attacks like ransomware, backdoors, data theft or unauthorized crypto mining.
What makes the vulnerability so dangerous is that it requires very low levels of skills for an attacker to execute and that billions of devices currently use Java and could then be targeted. The potential threat is compared with some of the most serious security breaches of the past decade.
Patches for the vulnerability affecting several (but not all) versions of Java and Log4J are available, but the problem is here to stay. Indeed, to get rid of the issue, organizations will need to extensively sweep their networks to comprehensively patch every system that could be compromised. This is not a problem if you must check if the family computer is vulnerable. However, for corporations and governments, the level of interdependency within their IT environment is such that it may take years to fix. Actually, the vulnerable application can have a direct or indirect dependency with log4j. And in this second case, it is not rare to have several levels of interdependence. For example, the application to be patched may contain a module that contains a module that integrates Log4j, a little bit like Russian dolls.
Log4Shell vulnerability shines light on the flaws that our interconnected IT infrastructure bears. Internet’s backbone is not built to be secure. Originally, the only goal of the internet and its ancestor ARPANET, was to exchange information on a local network that was not in any sense as massive and widespread as it is now. When they were designed, protocols like IP address or Domain Name Service (DNS) were therefore not developed with security in mind as it was not relevant for their early application.
And nowadays, speed and features are the focus when software developers are asked to design new programs or protocols, at the detriment of security. This means that common security features necessary to protect programs and applications are “add-ons” that come atop a weak basis, Log4Shell vulnerability being a tragic example from which we need to learn.
Also, reliance on opensource software is raising concerns. Managing the dependencies of open-source components at the heart of production applications is often overlooked, according to a recent study. However, this task is crucial against attacks to the software supply chain. The installation of non-vulnerable component versions must be guaranteed.
With the Log4shell vulnerability affecting Tech giants, the question is why do these companies still rely on open-source projects like Apache? Part of the answer resides in speed of execution and cost savings. Furthermore, the habit to develop on existing infrastructure without extensively reviewing its flaws remains a common practice.
That being said, Log4shell represents a massive intrusion threat for all companies and organizations across the world, suggesting that they’ll have to invest massively in intrusion detection tools and automated response solutions to prevent attacks.
Aside from the current turmoil affecting growth stocks, the proliferation of threats and connected devices strengthens our view that Digital Security is a highly attractive secular theme.
