Officials from the Cybersecurity and Infrastructure Security Agency (CISA) and within the cybersecurity industry are warning of the potential for threat actors to have already exploited the Log4j vulnerability, but are waiting to pull the trigger on any planned exploits until focus on the vulnerability abates.
On a call with press Jan. 10, CISA Director Jen Easterly said that while the agency has seen “no significant intrusions” using the “Log4Shell” vulnerability in the Log4j library, there is always the potential that – like with the Equifax data breach in 2017 – threat actors could already be present in the environment.
“At this time, we have not seen the use of Log4Shell resulting in significant intrusions,” Easterly said on the call. “This may be the case because sophisticated adversaries have already used this vulnerability to exploit targets and are just waiting to leverage their new access until network defenders are in a lower alert.”
“As everybody remembers the Equifax breach that was revealed in September of 2017 was a result of an open-source software vulnerability discovered in March of that year,” Easterly continued. “It may also be due in part to the urgent actions taken by defenders in many organizations to rapidly mitigate the most easily exploitable devices such as those accessible directly from the Internet.”
“Now, that said, we do expect Log4Shell to be used in intrusions well into the future, and for this reason, we are remaining focused on driving remediation of vulnerable assets for months to come,” she said.
What Makes Log4j Unique
Easterly has called the Log4j vulnerability “the most serious” she’s seen in her career. That characterization speaks not only to the widespread nature of the library – reported to be in over 2,800 unique products – that the vulnerability is housed in, but as well as the ease of exploitation.
Easterly said with just 12 characters in a text box, adversaries could exploit the vulnerability and gain access to systems.
However, Jim Gogolinski, vice president of threat intel at iboss and a veteran threat intelligence analyst, said it is not just how few characters it takes to exploit that makes the Log4j vulnerability worrisome, it’s also the ease of repeatability.
“As a defender, I can still stand back and you know, admire what the offenders are doing,” Gogolinksi told MeriTalk in an interview. “You know, it’s kind of like being a Mets fan. When the Yankees have a good game, I can be like, ‘Okay, you had a good game.’ I don’t have to like it, but I can acknowledge that.”
“When you’re doing vulnerabilities, what makes them worthwhile is how repeatable they are,” he explained. “There’s a lot of exploits that work in certain conditions and you have to have these five things in alignment. This one here, just worked and what made it even easier was you did the exploit and the exploit had to point back to some infrastructure you owned. And you could set that infrastructure up and you could test that all in your own environment. So, it was pretty much very easy; if you had access to that system, you can make it work.”
“The fact that it was 12 characters or 100 is, in general, [is] maybe less of an issue,” Gogolinski said. “I think the bigger piece of this is that it was it was 100 percent reliable.”
What now?
Despite the worrisome image of persistent threat actors lying in wait and biding time until they can attack, CISA Executive Director of Cybersecurity Eric Goldstein said such a possibility is not unique to the Log4j vulnerability.
“In general, anytime that there is a vulnerability that is not ubiquitously mitigated, there’s always a concern that adversaries have utilized that that vulnerability to gain a foothold on a target network, gain persistent access, and then lie dormant until such a time as they choose to pivot and achieve their objectives,” Goldstein said on the press call.
CISA is pushing for the requirement of a software bill of materials (SBOM) to make remediation of vulnerabilities easier in the future. Such a requirement would make it easier for organizations and Federal agencies to understand what exactly is in their environment.
Gogolinski agreed that SBOMs would aid in organizations’ network visibility but added that it is important to not just stop at the first level. He noted that many commercial software products depend on open-source libraries, and open-source tools to utilize those open-source libraries, and also depend on development tools that – you guessed it – depend on more open-source libraries, all the way up until you get to a vendor. Because of this, Gogolinski emphasized the importance of being thorough in the creation of SBOMs.
“The big takeaway from this is there’s a lot of dependencies on open-source software,” Gogolinski said. “The software bill of materials is going to help with this. There’s going to have to be a lot of scrutiny continued on open-source libraries. It’s getting a lot of attention right now, a lot of people are looking at other particular open-source libraries and seeing if there’s anything similar, but it’s always going to be a risk.”
“While it’s not going to be easy – it’s going to be a fair amount of work for software companies to have to start tracking this and honestly hardware companies as well – it really is going to be critical,” he said. “And what that gives you is, ultimately, when something like Log4j goes on, you just bring up the bill materials.”
