Many Companies are Still Exposed to Attacks Even One Year After the Detection of Log4Shell

Although the number of security vulnerability attacks announced to the public is less than expected, nearly three-quarters of organizations are still exposed to them.

The Log4j security vulnerability, revealed by the Apache Software Foundation last November, continues to pose a great threat to corporate companies even after a year although the number of attacks caused by this vulnerability was lower than initially expected.

Security researchers state that many systems still do not have a patch against this vulnerability, and organizations have difficulty detecting and correcting the problem and preventing its recurrence.

David Lindner, Chief Information Security Officer at Contrast Security, said, "The fact that Log4j is used in [nearly] 64% of Java applications and only 50% of those have updated to a fully fixed version means attackers will continue to target it. At least for now, attackers continue to have a field day in finding paths to exploit through Log4j."

Although considerable, attacks are less than initially predicted 

The Log4j vulnerability (CVE-2021-44228), commonly referred to as Log4Shell, is a vulnerability in the Java Naming and Directory Interface (JNDI) used to store and retrieve data in Log4j. This vulnerability allows attackers to gain control of vulnerable systems quite easily from a distance. This is a big problem considering that Log4j is used in almost all Java application environments. Security researchers consider this vulnerability one of the most important vulnerabilities in recent years, due to its prevalence and ease of exploitation by attackers.

Over the past year, numerous incidents were reported where attackers have targeted this vulnerability to gain initial access to a target network. Most of these attacks were reportedly carried out by advanced permanent threat (APT) groups supported by Independent states such as China, North Korea, and Iran. For example, in November, the US Cybersecurity and Infrastructure Security Agency (CISA) warned about an Iranian government-backed APT group that deployed crypto mining software and credential collectors in a federal network, exploiting a Log4j vulnerability on a VMware Horizon server.

This warning is similar to the warnings by Fortinet in March that Deep Panda, a Chinese threat group, used the same vector to install a backdoor into target systems, as well as the warnings by Ahn Labs that the Lazarus Group from North Korea created its own backdoor in the same way. Moreover, companies like Microsoft reported that state-backed actors such as Phosphorous from Iran and Hafnium from China used Log4 to connect to infected systems via a reverse shell session.

Despite such developments and news about the existence of cybercrime groups targeting Log4j with economic motivations, the number of violations via Log4 seems to be relatively low, particularly when compared to incidents involving Exchange Server vulnerabilities such as ProxyLogon and ProxyShell. According to Bob Huber, Chief Security Officer at Tenable, the number of reported cyber-attacks is surprisingly lower than expected in terms of scale and scope, given the size of the vulnerability and the ease of attacking through it. Huber said, "Only recently have we seen some significant evidence of targeting, as noted by recent nation state activity from CISA."

The threat is not over

Security researchers, however, highlight that this does not mean that Log4j threats have diminished over the past year.

First of all, a large number of companies are still as vulnerable to this threat as they were last year. A recent telemetry analysis conducted by Tenable on Log4j vulnerability revealed that as of October 1, 72% of organizations have a Log4j vulnerability. The analysis reveals that 28% of organizations around the world adressed the issue completely have eliminated this vulnerability, but organizations that improve their systems tend to face the Log4j vulnerability over and over again as they add new assets to their environments.

In 29% of the cases, servers, web apps, containers, and other assets become vulnerable to Log4j soon after the initial improvement.

Bob Huber expresses his thoughts on the subject as follows: "Assuming organizations build the fix into the left side of the equation — during the build pipeline for software — rates of reintroduction should diminish.” He added that "Much of the rate of reintroduction and change depends greatly on an organization's software release cycle."

Moreover, despite the common awareness of the cybersecurity community regarding the vulnerability in question, it remains difficult to detect vulnerable versions of Log4j in many organizations due to the way it is used in applications. According to Brian Fox, Chief Technology Officer at Sonatype, some applications may use open-source logging components as direct dependency and in other cases, an application may use Log4j as a transitive dependency or dependency of another dependency.

Fox said, "Since transitive dependencies are introduced from your direct dependency choices, they may not always be known or directly visible to your developers."

He also highlighted that many companies had to send thousands of internal e-mails, collect results in spreadsheets, and scan file systems repeatedly after the Apache Software Foundation first reported Log4Shell. "This cost companies valuable time and resources to patch the component and prolonged the magnitude of the vulnerability's malicious effect.", said Fox.

Data from Sonatype's Maven Central Java repository reveals that 35% of Log4 versions are still vulnerable versions. Fox commented, "Many companies are still trying to build their software inventory before they can even begin a response and are unaware of the implications of transitive dependencies."

Earlier this year, the Cyber Safety Review Board of the US Department of Homeland Security considered Log4 as an "endemic vulnerability" that organizations must tackle for years because of all these issues. Members of the Review Board said that vulnerable Log4j versions would remain in systems for many years and put organizations at risk of cyberattacks in the near future.

One Positive Results of the Incidents

Security researchers who have followed up on the Log4j vulnerability state that the only good thing to come out of what happened due to this vulnerability is the growing interest in applications such as software composition analysis (SCA) and software bill of materials (SBOM). The effort that organizations went through just to assess if they were vulnerable or the vulnerability level of their systems allowed them to better understand why all components in their code bases, especially those from open-source and third-party sources, should be transparent.

Matthew Rose, Chief Information Security Officer at ReversingLabs, said, "The investigation into the Log4J issue has reaffirmed the need for better software supply chain attestation in addition to SBOMs that keep up with the speed of DevOps." He added, "Application security and architecture teams have realized that just looking for risk in parts of the application like source code, APIs, or open source packages is not enough. They now realize that a complete understanding of the application's architecture is just as important as finding SQLI or cross-site scripting bugs (XSS),"

Source: Dark Reading