Businesses urged to remain vigilant as Log4Shell issues persist one year on

A red warning sign with the words Log4j underneath on a blue background of ones and zeros
(Image credit: Getty Images)

One year on from the disclosure of the Log4Shell vulnerability, security researchers are urging businesses to remain vigilant amidst continued threats.

Log4Shell is a zero-day remote code execution vulnerability in Java logger Log4j – the most popular used worldwide.

Log4j is used by a myriad of organisations and woven into virtually every internet service or application, including Twitter, Microsoft, Amazon and many more.

Naturally, when news of the vulnerability broke in December 2021, organisations globally scrambled to patch the Log4j flaw, which security specialists rightly warned could have wide-reaching implications.

Researchers at Check Point recorded almost 200,000 attempts to exploit the vulnerability within just 24 hours of disclosure. Similarly, within the space of a week, hackers launched more than 1.2 million attacks globally off the back of the vulnerability.

In the wake of the disclosure, cyber security firm Sophos also detected “hundreds of thousands of attempts” to remotely execute code using the vulnerability.

Analysis by other organisations, including Cloudflare, even suggested that Log4Shell may have been exploited by threat actors for some time prior to its public announcement.

The continued threat of Log4Shell

And as the world entered the new year, businesses continued to feel the pressure. In February, Iranian state-sponsored threat actors used the flaw to target US government networks.

This particular incident allowed hackers to illegally mine cryptocurrency, steal credentials, and alter passwords.

Indeed, throughout 2022 the impact of the Log4Shell vulnerability was felt. October saw a cybercriminal group with links to the Chinese government capitalise on the flaw to launch attacks on targets in the Middle East and a host of manufacturing companies.

Research published by Tenable in November showed that the problem still lingers. As of October 2022, 72% of organisations still remained vulnerable to Log4Shell – and that includes organisations that initially patched and mitigated threats.

“As of October 2022, 29% of vulnerable assets saw the reintroduction of Log4Shell even after full remediation was achieved,” the company confirmed in a statement.

Deryck Mitchelson, Field CISO at Check Point described Log4j as a “game changer” due to the relative ease with which threat actors could target services and devices around the world.

“It is estimated that 1 in 10 corporate servers were exposed,” he said. “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.”

What made Log4Shell so impactful?

The impact of Log4Shell was particularly acute due to rapid ease of exploitation. For threat actors, no privileged access was required to exploit the zero day vulnerability.

Similarly, the vast attack surface that could be targeted also exacerbated the situation. Millions of Java applications worldwide were affected.

RELATED RESOURCE

Enhancing cyber security in an expanding landscape

How secure connections between wireless peripherals can help mitigate cyber incidents and empower employees

FREE DOWNLOAD

At the time, security specialists noted that the difficulty in finding bugs and patching would likely cause issues for a significant number of organisations.

Muhammad Yahya Patel, Security Engineer at Check Point said that Log4j acted as a “stark reminder that security needs to underpin all applications and services”.

“Time is of the essence in these situations,” he added. “It forced many companies to review their vulnerability patch policies; any delay could cost them significantly."

Patel said that organisations must remain vigilant and learn from zero-day vulnerabilities to avoid similar situations unfolding in the future.

“Don’t trust open source software without doing your own checks,” he explained. “It is good practice to take open source software and put your 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.”

Ross Kelly
News and Analysis Editor

Ross Kelly is ITPro's News & Analysis Editor, responsible for leading the brand's news output and in-depth reporting on the latest stories from across the business technology landscape. Ross was previously a Staff Writer, during which time he developed a keen interest in cyber security, business leadership, and emerging technologies.

He graduated from Edinburgh Napier University in 2016 with a BA (Hons) in Journalism, and joined ITPro in 2022 after four years working in technology conference research.

For news pitches, you can contact Ross at ross.kelly@futurenet.com, or on Twitter and LinkedIn.