By the end of 2021, security teams were scrambling to patch one of the biggest vulnerabilities to be identified – Log4Shell, which affected the Apache Log4j library.
It was a shock to all in cybersecurity as Java and the Log4j open-source logging library are prevalent, commonly used across software applications and online services.
The issue quickly came to the attention of national governments. The UK’s NCSC described Log4Shell as “potentially the most sever computer vulnerability in years” and the US’ Cybersecurity and Infrastructure Security Agency (CISA) urged organizations to take mitigating action.
“Log4j was a stark reminder of the critical importance of securing the software supply chain. It was used in virtually every modern application and affected organizations’ services across the globe. One year on from the Log4Shell incident, the situation remains grim. According to our data, 30-40% of all Log4j downloads are of the vulnerable version, despite the fact a fix was released within 24 hours of the vulnerability’s premature disclosure,” said Brian Fox, CTO at Sonatype.
Meanwhile, as the bug ages, Michael Skelton, senior director of security operations at Bugcrowd, told Infosecurity that his team still experience Log4j submissions arriving in their programs, although he noted it is rarer now than 12 months ago.
“In the first 48 hours of the vulnerability being identified, we experienced over 1000 critical findings linked to Log4j, which has slowed significantly as the bug ages, but is still reported,” Skelton said. “From our observations, these findings have migrated from being typically found in the core of an application, and instead tend to originate from the dependencies that those applications rely upon, highlighting that Log4j is likely to be with us still for quite some time to come.”
Throughout the past year, threat actors have been exploiting the vulnerability. For example, in September 2022, cybersecurity agencies in the US, UK, Australia and Canada warned that Iranian state-sponsored hackers are exploiting Log4j vulnerabilities in ransomware campaigns.
"Log4j vulnerability CVE-2021-44228 remains popular with APT and criminal threat actors. We continue to see a background level of one to two million detections a day for exploitation attempts,” Rafe Pilling, principal researcher at Secureworks, recently told Infosecurity.
Alongside the Iranian threat group Cobalt Mirage leveraging the vulnerability, Pilling noted that suspected Chinese threat groups and initial access broker Gold Melody have been seen exploiting Log4Shell to compromise enterprise networks.
“This is just the tip of the iceberg,” Pilling said.
Despite 12 months passing, in which organizations have been advised to patch the vulnerability quickly and only use the latest versions of Apache’s Log4j that do not suffer from the vulnerability, it is still a major problem.
“It’s imperative that organizations recognize most of the risk involved with open source lies with consumers, who must employ best practice instead of blaming flawed code. Log4j is not an isolated incident – 96% of vulnerable downloads of open-source components had a fixed version available,” Fox noted.
Recommended Actions
Despite 12 months passing since the issue was uncovered, action is still required in the face of Log4j and other known vulnerabilities.
Pilling said: “We strongly recommend that organizations review their environment for vulnerable instances of Log4j, which might be bundled into other software stacks. It's not just their internet facing applications that need to be patched but potentially instances deeper in the network that receive log data from internet facing systems, and may potentially be exploitable."
Meanwhile, Rob Demain, CEO at e2e-assure, a security operations center (SOC) services company, highlighted best practices and good security hygiene among his assessment of lessons learned and actions to take.
“Some organizations consider Log4j a nation-state level threat and think they’re powerless against it, so why even try to safeguard themselves against an attack? However, having good hygiene means you can detect intrusions more easily,” Demain noted.
He also said that getting preparations and hygiene right is important for when this happens again, noting that is not a case of ‘if.’ The ability to detect, remediate and minimize impact quickly is imperative.
“We recommend performing a tabletop exercise: imagine a new vulnerability where no patching is immediately available. You think you are using this software on your internet facing application servers. Ask yourself how you’re going to find out if you’re using the affected component and how you’re going to protect your assets. Think also how quickly you could do this. The emphasis needs to be on speed,” Demain said.
Full Oversight
Some of the recommended actions Demain detailed relate to knowing what you’re dealing with and having full oversight of the software an organization is using. He recommended implementing a robust asset management system but noted that these are often good for infrastructure but not so effective on software and code, which presented a weakness.
Some of the confusion surrounding Log4j was caused by organizations having to figure out of it was a software library they were actually using. Demain recommended maintaining a software bill of materials (SBOM) to address this problem.
“When combined with a traditional asset management system, tools like vulnerability scanning mean organizations can get on top of the inventory issue,” he said.
Fox also emphasized the importance of this level of oversight: “Organizations need better visibility of every component being used in their software supply chains. This is why quality software composition analysis solutions are so important today as the world contemplates how SBOMs will help in the future.”
While the software supply chain is top of mind when analyzing this vulnerability, Demain warned that there are other angles to consider.
“Think about the people – particularly developers who will be considered as high value targets for attackers. If a hacker can get into a developer’s account, they can enter the software. Developers often have privileged access to data and systems, such as the cloud, servers, repositories and libraries. Often developers have poorly managed devices running local virtual machines, all outside of typical patch and monitoring regimes. If an attacker can phish their credentials or compromise their development machines and infrastructure, then you can become the source of the software supply chain problem,” he said.
The Log4j vulnerability remains a pertinent issue in cybersecurity over 12 months since it was first discovered. It is clear that the industry, along with government, still has work to do to communicate the problem and set out the actions organizations must take into 2023.