Two weeks ago, businesses have been alerted by a zero-day vulnerability, Log4Shell, which may cause one of the biggest cyber-attacks in the coming weeks and months.
The vulnerability was found on an open-source code, Log4j. Log4j is a piece of software that records events like errors and routine system operations and communicates these events to system administrators and users.
Businesses got aware of the vulnerability first on 9th December 2021. NVD has scored CRITICAL the severity level of the vulnerability as the impact and exploitability of it are high.
According to ZDNET as soon as the vulnerability is known by cyber criminals a vast amount of attacks started to take advantage of it. Microsoft stated that the vulnerability has been used by multiple tracked nation-state activity groups originating from China, Iran, North Korea, and Turkey. Their activities were including experimentation during development, integration of the vulnerability to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.
On the other, Apache software foundation, the provider of Log4j has announced an upgraded version of the code which was addressing the issue on the 10`th of December 2021. However, it has been seen that the patches addressing the first vulnerability was not complete and a second patch was released on the 13th December 2021. This patch was also addressing a critical vulnerability. Lastly, on December 16, 2021, Apache issued the most up-to-date patch which was addressing a vulnerability on the code issued on the 13th December. But this vulnerability was not as severe as the first two. However, it was severe enough to get a score of high by NVD.
It seems remediating the vulnerabilities arising around Log4j will take a long time because of its use in so many enterprise applications, servers, and internet facing devices.
Santiago Torres-Arias, who is an Assistant Professor of Electrical and Computer Engineering at Purdue University states two issues about patching Log4j vulnerabilities.
Firstly, instead of being a software component, log4j is a piece of software and this makes the situation harder when it comes to patching it. This means system administrators must inventory their software to detect if Log4j has been used in their software. Being unaware of the presence of Log4j in the system makes the problem around it harder to eradicate.
Secondly, another major problem regarding log4j is that it may not be easy for organisations to fix it quickly. Because of the nature of log4j, it is a part of the software supply chain. That means when a software is built, it travels through multiple departments and then it ends up in a final product. When a problem occurs at a point of this travel, the software is patched right there.
However, as Log4j is used so widely in different software products generating a fix requires involvements of many parties like Log4j developers, software developers who inserted Log4j library in the software code etc. At the end, this causes a delay to remediate the vulnerability and even ignoring it.
So, you may be asking yourself then what is the roadmap that you should follow. So far, the most effective way seems to be to keep the software you are using up-to-date.
