CDSA

Log4Shell, a critical vulnerability in the Log4J logging utility discovered in late 2021, is still being used to attack new victims and is one of several threats organizations must be aware of, according to the Media & Entertainment Information Sharing Analysis Center (ME-ISAC) — an initiative within the Content Delivery & Security Association (CDSA) — and its partners at information security company SecurityScorecard.

During a Feb. 24 “Log4Shell Vulnerability Overview” webinar hosted by ME-ISAC, SecurityScorecard explained what the Log4Shell vulnerability, found on a wide variety of internet-facing web apps is, as well as what it means for media and entertainment organizations, and how to find out if one’s organization is vulnerable.

There have, meanwhile, already been “a considerable number of reports” of attacks against Ukrainian government agencies and civilian companies’ networks as part of the separate issue related to the ongoing Russia/Ukraine situation,  Chris Taylor, ME-ISAC director, pointed out at the start of the webinar.

“It looks and feels like ransomware but there’s no decryption key. So it just comes in and destroys things,” Taylor said.

“We saw the same action taken in 2017,” he said. That took down FedEx and other internal networks, he told viewers, noting Russian military attacked Ukraine “but they deliberately included collateral damage so that the attribution wouldn’t coming back to Russia.”

Therefore, “we are very concerned about collateral damage on peoples’ networks when this attack starts,” he said. “Cyber weapons have a way of leaking and hitting other targets. So you’ve got to be very careful and watching out right now,” he warned.

“Definitely a very good control to have is a set of offline, disconnected backups so that if something like that does hit your network, you want to be able to do your entire response, get the malware off the network and then plug backups in and restore knowing that they haven’t been corrupted,” he said.

However, a lot of the ransomware groups will get their initial entry and then go looking for an organization’s backup server and corrupt it first, before they deploy the ransomware, he warned. “It’s not unheard of for ransomware response to go grab the backup tapes and find out those are also encrypted. So a good backup strategy needs to include a disconnected set that can’t get encrypted by whatever attacks you,” he explained.

There was a ransomware group that “would hang out for a solid month before they dropped the encryptor,” he also noted, adding, “they were pretty darn evil.”

It is, however, unfortunately a “common practice to stick your head in the sand and then keep doing what you’ve always been doing,” according to Mike Wilkes, chief information security officer (CISO) at SecurityScorecard, a New York-based firm that rates the cybersecurity postures of organizations.

Log4Shell’s Discovery

Moving on to Log4Shell, Wilkes noted that Alibaba Cloud security researchers disclosed their discovery of it to The Apache Software Foundation, Log4J’s developer, on Nov. 24.

“Most of us didn’t learn about it until December 9, when it was publicly disclosed, and a lot of us, including our team, learned about it through” the online game Minecraft “because that was one of the first communities that became aware of this fascinating vulnerability,” he pointed out.

“We all looked at this vulnerability and understood this is probably one of the biggest vulnerabilities in the last 10 years and this is going to be around for a long time,” he predicted.

The next step: “We wanted to make sure that we started scanning our infrastructure and making sure that we weren’t vulnerable or at least we knew where we were and how to mitigate it,” he explained.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) hosted a conference call on Dec. 13 to share information it had on Log4Shell and take questions about the vulnerability, he noted.

“My high-level recommendation is just send a short due diligence questionnaire – three or four questions” to third parties used by your organization, asking them if they have Log4J vulnerabilities, have they mitigated them if they do and when will they be done, he said. The reason: “It’s going to be your third parties that we notice are being attacked and vulnerable, not necessarily you,” he explained.

Wilkes was surprised to find out that a few companies were “actively using the exploit to detect the exploit back in December and this is a felony – this is illegal – even with good intentions,” he warned. “So I would recommend that you only use the exploit to detect the exploit for your own infrastructure.”

The back-end, Log4Shell vulnerability is a “library that can be running on servers two or three firewalls deep on your infrastructure – anything that’s processing log files essentially – and so it’s difficult to have full visibility if you’re just doing passive scanning,” he explained to viewers.

SecurityScorecard created an issue type for Log4Shell on its platform that “can be queried across your portfolios to figure out which of your third parties – or even your own digital footprint – has signs of exposure to it, he said.

His company first discovered signs of Log4Shell “on the very day it was disclosed,” when an IP address coming from China Telecom hit the application programming interface (API) for SecurityScorecard’s platform, he pointed out. “The Russians were observed attempting to exploit the vulnerability by 1 pm the very next day,” he added.

What’s Next?

“So what’s next? Expect years of exploits and breaches from this vulnerability, where the root cause analysis turns out to be an unpatched Log4J instance,” Wilkes said.

He predicted “Log4Shell detection and mitigation is going to be around for a long time.”

Software Bill of Materials (SBOMs) are “helpful for us knowing where Log4J is installed,” he said. “But unfortunately not all open source or commercial projects actually produce an SBOM,” he pointed out, noting that’s “not widespread practice yet.”

It’s also “not just embedded Log4J that we need to track,” he told viewers, pointing to Sonatype reporting that the Java JndiManager.class was borrowed by 783 other projects and was actively seen as a vulnerability in nearly 20,000 individual components.

“Think of this basically as ransomware on steroids,” he said, warning ransomware is the top payload being delivered by advanced persistent threats (APTs) and threat actors of all kinds are taking advantage of this vulnerability.

To detect and mitigate the Log4Shell risk using automation and event-based assessments of third-party risk, he suggested that M&E organizations check their webserver logfiles for signs of exploit attempts and check their operating system logfiles for signs of successful exploits.

Companies can also put a web application firewall (WAP) or content distribution network (CDN) rule in front of their websites, APIs and services if they don’t already have one of them. They can also block outbound traffic by default, he said. Although egress firewall rules can take some time to test and deploy, this will mitigate hundreds of scenarios and vulnerabilities in the future, making it worth the effort.

And continuous monitoring, such as what SecurityScorecard provides, helps also, he added.

ME-ISAC provides stakeholders with intelligence on incidents, threats, risks, vulnerabilities and associated remediations in the form of alerts, threat intelligence feeds, newsletters, forums, training and more.

To learn more about ME-ISAC, click here.