No Significant Intrusions Related to Log4j Flaw Yet, CISA Says
But that could change anytime, officials warn, urging organizations to prioritize patching against the critical remote code execution flaw.
January 10, 2022
In the one month since news broke of a critical remote code execution vulnerability in the Log4j logging framework, there have been no major intrusions tied to the flaw in the US, officials from the Cybersecurity and Infrastructure Security Agency (CISA) said Monday.
However, they warned about the possibility of attackers exploiting the flaw later because of its prevalence — hundreds of millions of devices and components have the vulnerability — and the ease with which it can be exploited.
“We do expect Log4j to be used in intrusions well into the future,” said CISA director Jen Easterly in a virtual press conference this morning. "We are concerned that threat actors are going to take advantage of this vulnerability," especially against critical infrastructure targets.
Over the past month, the Apache Foundation has disclosed three separate vulnerabilities in Log4j — a logging tool that is present in almost all Java application environments. Of the three flaws, security experts consider the one that the foundation disclosed first (CVE-2021-44228) to be, by far, the biggest threat.
Easterly described the flaw — now referred to as Log4Shell — as the worst she has encountered in her career and one that attackers could exploit simply by sending as little as 12 characters to a vulnerable system. Once exploited the flaw gives attackers a way to gain deep access on compromised systems, she said. So far, some 2,800 products have been identified as vulnerable, she said.
Since news of the vulnerability first surfaced, CISA had been working to ensure that federal civilian agencies make patching the Log4Shell flaw a top priority, said Easterly and Eric Goldstein, executive assistant director for cybersecurity at CISA. CISA, along with the NSA, FBI, and others, including technology companies have been working overtime to provide guidance on the vulnerability to both federal agencies and to private organizations.
On Dec. 17, the agency added the vulnerability to a catalog of known and actively exploited flaws. CISA gave federal agencies until Dec. 23 to identify the flaw in their Internet-facing assets and either patch it, apply specific mitigations for neutralizing the threat, or remove the vulnerable asset. Agencies had until Dec. 28 to provide CISA with a list of all applications that they identified as being vulnerable, the vendors of those applications, and the actions they had taken to address the issue.
The widespread patching and mitigation efforts within government — and elsewhere — are likely one reason there has not been any major reported incidents of a Log4j-related compromise in the US so far, the two CISA officials said. But it is also likely that attackers have already compromised many systems and are waiting for the right moment to strike, they noted.
Meanwhile, Matt Keller, vice president of federal services at GuidePoint Security, says his organization's interactions with federal agencies show that some of them are struggling to patch the Log4Shell flaw because they have end-of-life or end-of-support systems in their environments.
"When a system or software is end of life/end of support, typically the company that designed and wrote the software moves the development team on to other projects," Keller says.
As a result, patches may not always be available for bugs that surface in these products, he says. "The system can be patched if a patch is available. Sometimes vendors will release a patch for a critical patch for something like this, but they aren't required to," he says.
Some Agencies Struggling to Pinpoint At-Risk Systems
According to Keller, some agencies are also having trouble finding vulnerable systems and are using command line scripts to try and find them.
"Running a command script on some systems can be singularly focused where you have to touch each system individually and review the findings," Keller notes.
The process is slower than using a vulnerability scanning tool and could result in agencies missing systems that need to be patched or mitigated against the Log4j flaw, he says.
Keller says government agencies are more likely to have issues with end-of-life/end-of-support systems than private companies because of the typically more complicated procurement processes that exist in government. So private organizations are less likely to run into issues with end-of-life systems when patching the Log4Shell flaw, he says.
"Patching an end-of-life product can sometimes be more involved than one would think," says Ray Kelly, fellow at NTT Application Security. "For instance, if the components being patched have a different programming interface, then it could require significant code changes and QA effort for the application [to be] fixed," he says.
The best that organizations can do to protect end-of-life/end-of-support systems is to put layers of network defenses around them, adds John Bambenek, principal threat hunter at Netenrich.
"Place them on highly isolated VLANs with strong access control and strong network anomaly monitoring on those segments," he says. Organizations should also consider simply preventing those machines from having any Internet access at all, he adds.
About the Author
You May Also Like
Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024The Right Way to Use Artificial Intelligence and Machine Learning in Incident Response
Nov 20, 2024Safeguarding GitHub Data to Fuel Web Innovation
Nov 21, 2024The Unreasonable Effectiveness of Inside Out Attack Surface Management
Dec 4, 2024