While a "significant" Log4j-based attack on critical infrastructure systems has yet to be seen, a panel established by the Department of Homeland Security (DHS) is warning that the “endemic vulnerability” will continue to plague organizations for years to come as exploitation evolves.
The prediction comes as part of a 52-page report dissecting the exploitation, mitigation efforts and systemic security challenges of the ecosystem surrounding the Apache Log4j flaw in the more than six months since its public disclosure. The report is the first one released by the Cyber Safety Review Board (CSRB), a panel of private and public sector industry leaders that was tasked by the DHS in February with identifying key lessons learned, and developing non-binding recommendations based on those lessons, from significant cybersecurity events.
After reviewing publicly available material and talking to developers, end users and defenders from 40 separate organizations, the CSRB highlighted what went “right” and “wrong” in the days leading up to, and following, the disclosure of the Log4j flaw. Both the Apache Software Foundation (ASF) and the ecosystem recognized the criticality of the flaw and urgency of patches during the time of disclosure, with vendors and government organizations quickly coming out with guidance and tools, the board found. However, the process of updating vulnerable software has been strenuous, time-consuming and costly for impacted organizations. At the same time, security risks continue to exist across the open-source software ecosystem, mainly stemming from tight resources.
“To reduce recurrence of the introduction of vulnerabilities like Log4j, it is essential that public and private sector stakeholders create centralized resourcing and security assistance structures that can support the open source community going forward,” according to the report, released this week. “The Board predicts that, given the ubiquity of Log4j, vulnerable versions will remain in systems for the next decade, and we will see exploitation evolve to effectively take advantage of the weaknesses.”
The flaw was first reported on Nov. 24, 2021 by a security engineer from the People’s Republic of China (PRC)-based Alibaba Cloud Security team. Meanwhile, while ASF was working to devise a fix for the flaw, another PRC-based cybersecurity company, BoundaryX, disclosed the flaw on WeChat before ASF made a publicly available update. While there had been previous speculation that the PRC or another country may have exploited the flaw before it was disclosed, when looking at Log4j-based attacks, the board did not discover any evidence confirming that threat actors from the PRC, Iran, North Korea or Russia had exploited the flaw prior to its Dec. 9, 2021 disclosure date. While the earliest known exploitation of the flaw occurred on Dec. 1, 2021, the activity was linked to limited exploit testing of the Log4j flaw in the wild by Alibaba.
“The Board predicts that, given the ubiquity of Log4j, vulnerable versions will remain in systems for the next decade, and we will see exploitation evolve to effectively take advantage of the weaknesses.”
After disclosure, widespread attempts to exploit the flaw were observed; however, the CSRB concluded that the ensuing exploitation of the flaw has occurred at lower levels than previously predicted, with no publicly reported "significant" Log4j-based attacks. However, it's important to note that no authoritative source exists to help collect and understand exploitation trends across varying locations and industries beyond anecdotal reporting from cybersecurity vendors, making a more comprehensive detailing of Log4j exploitation trends difficult.
“The impact to organizations over the long term will be difficult to assess without better tools for discerning real exploitation and centralized reporting of successful compromises,” according to the report.
Beyond these exploitation levels, organizations impacted by the Log4j flaw have faced a rocky mitigation and patching process. The time, money and resources needed for responding to the flaw have often had a financial impact on companies and delayed other mission-critical security tasks, including responding to other flaws. One federal cabinet department spent over 33,000 hours responding to the Log4j flaw, the CSRB found.
At a higher level, the inherent security issues that exist in the open-source software ecosystem itself pose long-term problems. These have already been widely discussed by the U.S. government and tech sector on the heels of the Log4j flaw’s disclosure, which have mulled over solutions like a proposal to set up an independent clearing house to offer support and match volunteers with open source projects that need help. The CSRB expanded on these proposed measures with a recommendation for the U.S. government to “play a role in driving security enhancements” for the overall ecosystem as a significant consumer of open-source software. That role would include the OMB taking the reins in directing federal agency IT staff members to assist in securing and maintaining the open-source software on which they rely. Private-sector organizations that use open-source libraries in order to build commercial software should also offer up financial resources toward the open-source projects that they deploy, said the board.
“The ‘long-tail’ scenario outlined in the report is one we’ve seen with countless past vulnerabilities, and one that favors attackers since their success is based on having at least one victim who hasn’t patched their systems.”
The CSRB also recommended that CISA invest more heavily in open-source software security by creating a Software Security Risk Assessment Center of Excellence in order to develop and manage a central inventory of all software across federal agencies, with the end goal of facilitating vulnerability notification and response.
One top takeaway from the report is that the Log4j flaw will continue to pose a risk to organizations long after the dust has settled, with exploitation levels continuing to persist and evolve. Companies should continue to proactively monitor for and update systems vulnerable to the Log4j flaw, while CISOs at federal agencies should report any observed Log4j exploitation instances to CISA, said the CSRB.
“The ‘long-tail’ scenario outlined in the report is one we’ve seen with countless past vulnerabilities, and one that favors attackers since their success is based on having at least one victim who hasn’t patched their systems,” said Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center. “Given management of open source software is different than commercial software, and open source powers commercial software, reliance on a commercial vendor to alert consumers of a problem presumes that the vendor is properly managing their usage of open source and that they are able to identify and alert all users of their impacted software – even if support for that software has ended.”
Organizations should also finetune their security practices to better enhance vulnerability management, including investing in vulnerability scanning technologies used to identify vulnerable systems; maintaining asset and application inventories and creating a vulnerability response program and vulnerability disclosure and handling processes. Security industry professionals hope that the CSRB's report will shine a timely light on major challenges facing organizations, government agencies and the open-source software ecosystem as a whole.
“The vulnerabilities in Log4j prompted ‘one of the most intensive cybersecurity community responses in history’ and there are a great many lessons to be learned from it, and hopefully applied back into software and F/OSS vulnerability management,” said Casey Ellis, founder and CTO at Bugcrowd.