At the time, Check Point Research 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.
On the anniversary of the Log4j vulnerability disclosure, Check Point Software looks back on one of the biggest security shake ups in recent years. 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 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.
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.
Deryck Mitchelson, Field CISO, Check Point Software said, “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. I think it was 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 was critical to my 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. It does make you think, does your vendor take your security as seriously as you do?”
What’s next for Log4j?
The Log4j vulnerability was a 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.
Muhammad Yahya Patel, Security Engineer, Check Point Software added: “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 cost them significantly.
“We need to learn from these zero-day vulnerabilities to avoid the next log4j incident from happening. Don’t 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.”
