On the first anniversary of the Log4j vulnerability disclosure, Check Point Software looks back on one of the biggest security shake ups in recent years
By Harish Kumar GS, Head Of Enterprise & Government, Check Point India & SAARC
On December 9th, 2021, an acute remote code execution (RCE) vulnerability was reported in the Apache logging package Log4j versions 2.14.1 and below (CVE-2021-44228). Apache Log4j is the most popular java logging library, used by companies worldwide. It is embedded in almost every internet service or application we are familiar with, including Twitter, Amazon, Microsoft, Minecraft and many more.
At the time, Check Point Research (CPR) witnessed a pandemic-like spread of attacks, recording almost 200,000 attempts to exploit the vulnerability within 24 hours of the initial disclosure. Within a week, hackers, including Chinese-backed state groups, had launched more than 1.2m attacks.
CPR also noted that more than 40 per cent of corporate networks in India saw an attempted exploit within 72 hours after the attacks. Around the world, about 2 lakh targeted attempts were made within twenty-four hours of the initial outbreak.
As we moved through 2022, it became clear that cybercriminals would continue to exploit the vulnerability. In February, Iranian state-sponsored cyber criminals used the flaw to break into a US government network, illegally mine cryptocurrency, steal credentials and change passwords. Then in October a group associated with the Chinese government used the vulnerability to launch attacks on various targets including a Middle Eastern country and electronics manufacturer.
The Log4j vulnerability continues to plague businesses today. It consistently ranks first or second in Check Point Research’s threat reports, impacting 41% of organizations globally as of October 2022.
Log4j was a game changer due to how easy it was to compromise, with a single line of code and millions of services and devices around the world that were vulnerable. It is estimated that 1 in 10 corporate servers were exposed. This could be seen as a wake-up call for an industry that was relatively blasé around the management of open-source libraries and their use therein and were perhaps too trusting of their vendors and the supply chain’s vulnerability management capabilities.
When managing services as an operational C-Suite leader, vulnerability management is always critical to organisations’ business continuity, particularly in healthcare. However interestingly, not all vendors were vulnerable to Log4j, and while some vendors stepped up and provided patches very quickly, others were days and weeks behind.
What’s next for Log4j?
The Log4j vulnerability was a global wakeup call for every organization, and it was a time that many security professionals would like to forget. However, with widespread use of Log4j and an ever-growing network of internal and third-party servers to patch, the vulnerability will be felt for a long time.
Log4j acted as a stark reminder that security needs to underpin all applications and services. Time is of the essence in these situations, and it forced many companies to review their vulnerability patch policies; any delay could have cost them significantly.
All businesses and even security vendors need to learn from these zero-day vulnerabilities to avoid the next Log4j incident from happening. Do not trust open-source software without doing your own checks. It is good practice to take open-source software and put your bespoke security controls around it. Build software code securely right from the start to avoid any surprises in the future, and make sure any changes to the software pass through your security checks.
Pic Source: archetype