On November 24th, 2021, the security team at Alibaba found a vulnerability in the Log4J library, now known as “Log4Shell”. The security team reported the vulnerability to the Apache Foundation, which monitors the development of the software, after which it was being tracked as CVE-2021–44228
On December 9th, 2021, it was publicly reported about the vulnerability. New Zealand’s computer emergency response team, or CERT, was among the first teams to report the flaw was being “actively exploited in the wild”. This has made firms around the world seemingly worried since this vulnerability can be exploited, from the cloud to developer tools and security devices, in ways you cannot possibly imagine.
What is Log4J & why it’s widely used?
Any software application that a developer must build (or develop) needs to record or log information. It is essential to log critical information about an application, such as warnings, response times, problems, and so on. This information assists developers at various tech businesses in understanding more about their applications in order to improve the efficiency of the applications.
Log4J is the most widely-used Java-based logging library and is used in millions of applications around the world. Since it is open-source, the library is popular and is used by major tech firms like Minecraft, Apple, Microsoft, LinkedIn, Google, and Twitter, and even government-run applications.
How dangerous is this vulnerability?
The “Log4JShell” vulnerability gives cybercriminals complete access to internal networks where steal can loot valuable data, plant malware, erase crucial information, and much more.
The vulnerability is so severe that the Apache Software Foundation, which monitors the development of the software, gave the vulnerability a ten on a scale of one to ten.
“The Log4j framework is used in at least 250,000 open-source software projects.— Tony Turner, VP of Fortress Information Security
Developers sometimes build software atop existing tools without fully understanding the underlying code, potentially obscuring flaws such as the Log4j vulnerability.”
Security experts have said that the ease with which an attacker can access a web server “even without any password” makes this vulnerability highly dangerous. They have also warned that hackers have made hundreds of thousands of attempts to locate vulnerable devices; more than 40% of corporate networks have been targeted.
Patch fix is available but the vulnerability is here to stay
Although the fix was released as soon as possible, patching the systems with the newest non-vulnerable version,
2.16.0, would definitely take longer for all the applications around the world.
Nation-state-sponsored hacker organisations have already attempted to exploit the vulnerability via various methods. Hacking operations based in China, Iran, North Korea, and Turkey have also been observed seeking to use Log4j, and they will continue to do so for as long as they can. Hence, the US Cybersecurity and Infrastructure Security Agency (CISA) has mandated that federal agencies patch the vulnerability within days.
The cybersecurity researchers at Randori published their vulnerability analysis in a blog post, encouraging all organisations to adopt an “assumed breach mentality” and monitor logs for impacted applications for unusual behaviour. Identifying the applications that are vulnerable would be a real challenge.
My team came to know about this vulnerability a day later. I had already worked on my tasks for more than 10 hours that day. When the day got over, I spent some time reading books and working on an article. After dinner, as I was preparing for a good night’s sleep (I was exhausted that day), I received a call from my manager and lead about this vulnerability.
Every member from every team immediately started working on their respective applications. My team of six developers joined in a call and started applying the patch fix in over 30+ applications. We were tasked with applying the patch, deploying the applications in the lower environments, getting them tested and certified by the quality assurance team, so that they could be deployed to higher environments, i.e., UAT and Production. It took us 14 hours to do everything.
It was a nightmare. We applied the patch fix with the then recommended version of
2.15.0 with additional recommended parameters.
I thought that the issue was over. However, after 2 days, the newest non-vulnerable version (as of this writing),
2.16.0 was released. We had to do the same tasks over again.
I can only imagine a firm having thousands of apps running with this vulnerability. I can only imagine the plight of the developers who have been assigned to apply the patch fixes within a few days.
If you enjoyed reading this, you might also find the below articles worth your time.