6 months later, the terrible Log4Shell flaw still infects thousands of companies

6 months later, the terrible Log4Shell flaw still infects thousands of companies

Like the Covid, which never seems to end, will the Log4Shell computer virus rot the lives of companies for a long time to come? Anyway, it’s a good start. Because six months after its appearance, the biggest computer flaw in history is still far from being resolved for thousands of companies around the world, which are still suffering the consequences.

It all started on November 24, 2021. On that day, researchers discovered a major computer vulnerability, called “aepidemic incident” as described in the columns of La Tribune Erka Koivunen, security manager at F-Secure. Located on the Log4j software component, the flaw quickly named “Log4Shell” had triggered a real commotion in the security teams. And for good reason: Log4j was used by thousands of applications coded in Java (one of the most widely used computer languages ​​in the world) and the incident therefore concerned millions of machines belonging to thousands of companies.

6 months later, although overshadowed by fears related to the war in Ukraine, the Log4Shell threat has not disappeared. The peak of the crisis has passed, but vulnerability is now beginning a new life cycle. “We arrive today at the end of the tail of the comet“, explains to La Tribune Samuel Hassine, Cybersecurity Strategy and Operations Director of the publisher Tanium. In other words, the incident response stage – particularly long due to the particularities of the flaw – only ends now. But however, the exploitation of Log4Shell by malicious actors is still in its infancy.

A vulnerability that takes a long time to fix

Samuel Hassine reports a beginning of calm after very complicated months for certain companies, which have struggled to track down the flaw in their computer networks. “For some, the remediation of the flaw only took a few days. But for others, dependent on external publishers, it dragged on over time“, he develops. The Apache Software Foundation, which distributes Log4j, released a patch to fix the flaw as soon as it became known. The problem is that it was then up to each publisher using Log4j to deploy this patch itself. Some got down to it immediately, others dragged on, either out of lack of interest or ignorance of the component. And it is here that the crisis escalated.

On the one hand, companies that only use a small number of applications, most often popular and recent. The publishers of these applications immediately updated them, and the crisis therefore lasted for them only a handful of days. On the other, larger companies with more complex and diverse computer networks. “In health, for example, many software are coded in Java, and among them, some are very old and respond to very specific tasks. The problem is that these old software are sometimes no longer updated, and their publishers are not even reachable in some cases.“, develops Samuel Hassine.

For this second category of companies, a real headache started: they had to list the applications used on their computer equipment, find those that use Log4j, make sure that the publishers have deployed the patch, and put the applications up to date. Problem: The update process isn’t as easy as it looks. “In some cases, an impact analysis must be carried out beforehand to be sure that the patch will not break everything“, tempers Antoine Richer, application security expert at Accenture Technology in France. “If it is not possible to deploy the patch, it is also possible to deploy a virtual patch, removing the functionality responsible for the vulnerability at the application level“, he adds. In other words, the security managers of the companies concerned had to judge each application on a case-by-case basis. A time-consuming and demanding lace job.

A flaw well integrated into the arsenal of cyberattackers

As a direct consequence of this difficulty in remedying Log4Shell, in April, Rezilion researchers warned that the flaw was still present on 90,000 applications and 68,000 servers exposed to the Internet (and therefore vulnerable to attacks). And again, it was just “the tip of the iceberg“These thousands of vulnerable machines are all entry points for cybercriminals. As a result, alerts to the exploitation of Log4Shell have multiplied at regular intervals.

As recently as June 23, Cisa – the American cybersecurity policeman – warned that Log4Shell was being exploited by malicious actors to reach servers of VMware Horizon (workstation virtualization software), widely used by businesses. Once introduced to these servers, attackers can move around their victims’ computer workstations, looking for internal systems that could contain sensitive data. Three months earlier, Mandiant researchers accused the Chinese government-affiliated hacker group APT41, known as Halfnium, of successfully exploiting Log4Shell to spy on the governments of “at least“six American states.

More generally, many cybercriminal groups – with pecuniary objectives for some, strategic for others – have included Log4Shell in their attack kits, that is to say in the kit of tricks that they try to systematically exploit. to enter the network of their targets. Concretely, they scan the machines connected to the Internet of their targets in search of a whole set of very widespread vulnerabilities (like Log4Shell) for which they have the methods of exploitation.

According to expert Jamie Moles of publisher ExtraHop, these features are even incorporated directly into botnets – networks of infected computer machines available for hire to launch coordinated cyberattacks. Result: ExtraHop had 147,000 scans of the Log4j flaw in May alone, and almost as many in the previous months. Cybercriminals are all about finding the easiest (and least expensive) access to their victims’ network, and Log4Shell is a particularly easy door to enter. “Java is one of the most widespread languages ​​in web applications, which are by definition exposed to the Internet“, recalls Antoine Richer.

Developers massively download vulnerable versions of Log4j

If Log4Shell continues to be exploited, it is not only because of a delay in the deployment of patches. The publisher Sonatype has observed for several months a strange phenomenon which does not weaken: more than a third of the versions of Log4j downloaded from Mazen (one of the reference directories) are not up to date, and therefore contain the flaw. In other words, the developers integrate a software component vulnerable to attacks. In February, company CTO Brian Fox told the Wall Street Journal that affected developers “don’t know what’s going on in their softwareSince then, he regularly presents his observations, without succeeding in changing the status quo.

Questioned by a US Senate committee in February, the president of the Apache Software Foundation recalled that there were several scenarios justifying the use of older versions of Log4j, for example to do security research or because other components require keeping an outdated version. But these particular cases are not enough to explain the more than 33% of downloads of vulnerable versions.

To avoid continuing down this path, professionals try to learn from security incidents like Log4Shell. “The application security community is increasingly interested in the supply chain”, explains Antoine Richer, “ohn becomes aware that a large part of the application code that we develop comes from external libraries. You have to know what you import into your code, to master its application and react more effectively in the event of an incident.“These best practices are gradually taking hold, but the flaws continue to be discovered at a breakneck pace.