This month marks the one-year anniversary of the discovery of the Log4j2 vulnerability. Technically, it’s a 2021 cybersecurity event. However IT and infosec leaders spent much of 2022 hunting for and patching applications using the buggy open-source logging library module.
If they’re smart, they’ll keep doing it in 2023, says one expert.
“Many CISOs may still be thinking this is an exploit that is particular to a couple of vendors, and once they’ve patched their current software, this problem has gone away,” said Robert Falzon, head of engineering at Check Point Software Canada.
“There are [IT] systems that kick in only once or twice a year, and those systems may be vulnerable and overlooked from a checking perspective.
“It is still being exploited,” he said, and will be “for some time to come.”
“This component still exists in thousands of pieces of software across the entire spectrum of enterprises, from big to small. And despite the fact that Microsoft may have patched their current servers and software … there are organizations that are running other applications that are not being updated because they are not a piece of code that Microsoft or Linux has access to upgrade.”
It can be hard for IT administrators to trace if you don’t have the tools, he said. “Attackers are targeting these in a much more effective way now, because they’re mapping the environment of organizations that have this exposure,” Falzon added.
Briefly, Apache Log4j is a free, open-source Java-based logging framework that collects and manages information about system activity. In a July report, the U.S. government’s Cyber Safety Review Board said Java developers have embedded it into thousands of software packages and services.
The problem in Log4j version 2 was introduced by the developers in 2013, and only discovered in November 2021. At that point, it was privately reported to Apache. However, before Apache could release a fix, it was publicly disclosed, triggering a race to find and patch the hole before it was exploited by threat actors.
The race wasn’t always won by the good guys. Check Point has seen nation-state threat actors exploiting the vulnerability. Cisco Systems’ Talos threat intelligence service reported the Mirai botnet attempting to exploit it. The U.S. report said an unnamed cybersecurity company investigated multiple ransomware incidents that leveraged the Log4j vulnerability from January through to March. That U.S. report also mentions that a news story said hackers had exploited the vulnerability at the Belgian Defense Ministry.
While threat actors were — and still are — trying to find vulnerable applications, many software developers haven’t gotten the message. According to Sonatype’s Log4j Vulnerabile Downloads Dashboard, about 25 per cent of the Log4j downloads every day are vulnerable versions of the library.
One good thing about the discovery it is that has increased the pressure on software developers to improve the quality of their code through rigorous processes, including creating a software bill of goods so purchasers will know what it comes with.
It has also put a spotlight on three major problems: how easy it is for threat actors to plant malware in open-source repositories such as GitHub, NPM and PyPI under spoofed library names; the difficulties faced by individuals who try to maintain open-source code in their spare time; and the need for every IT department to have a complete inventory of all the applications employees are authorized to use for work.
“The Log4j event highlighted fundamental adoption gaps in vulnerability response practices and overall cybersecurity hygiene,” said the U.S. report. “These gaps highlighted challenges in raising awareness within organizations; coordinating trusted and authoritative sources of information; mitigating at scale; measuring the enormity of the risk; and synchronizing the understanding of threats and corresponding defensive action.”
In their recent 2022 Mass Exploitation report [registration required], researchers at GreyNoise Intelligence noted that the U.S. Cybersecurity and Infrastructure Security Agency’s GitHub database of software affected by the Log4j weakness stopped receiving regular updates earlier this year. The last update showed either “Unknown” or still “Affected” status for about 35 per cent (1,550) of products catalogued. “Attackers know what existing products have embedded Log4j weaknesses, such as the popular VMWare Horizon, and have already used the exploit in ransomware campaigns,” the report says. “If you have not yet dealt with your internal Log4j patching, now would be a good time to get that into Q4 2022 and H1 2023 plans.”
“This is a new dynamic for many organizations,” said Falzon, “who don’t even realize they have these resources internally, and that they are both critical and exploitable.”
Over time, systems that look for vulnerable versions of Log4j2 will get better, he added, and as IT departments upgrade their security infrastructure, there will be fewer successful exploits. But the hole will continue to exist “for some time to come.”
In its report, the Cyber Safety Review Board said IT departments should:
•have a documented vulnerability response program;
•continue to proactively monitor for and upgrade vulnerable versions of Log4j;
• prioritize applying software upgrades (using mitigations sparingly) to avoid errant conditions that would create exposure over the long term (for example, configuration mistakes that expose vulnerable attack surfaces);
• use robust business processes that prevent the reintroduction of vulnerable versions of Log4j (otherwise known as regressions);
• take a risk-based approach to remediate Log4j so they can address other high-severity vulnerabilities.
Application developers and maintainers should:
• establish a comprehensive approach to code maintenance that encompasses consistent secure development processes, and accounts for software security assessments and vulnerability management operations, as well as patch creation and co-ordinated disclosure;
• implement communication processes and mechanisms that provide consistent and relevant security messaging to software package users, noting all recommended data to include in a security advisory;
• leverage Integrated Development Environment (IDE) tools and add-ons for assisting in secure software development, consistent with NIST’s Secure Software Development Framework;
• integrate source code scanning and tools that provide software maintenance status and versions to heighten their situational awareness of applications and software used within the environment.
The report — issued six months after the discovery of the hole, said Log4j has become an endemic vulnerability that will be exploited for years to come.
