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 expected initially.
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 about 64% of Java applications and only 50% of those have updated to a fully fixed version means that attackers will continue to target it. Right now, the attackers seeking ways to carry out new cyberattacks through Log4j, as if mocking."
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 that attackers have targeted this vulnerability to provide initial access to a target network. Most of these attacks were reportedly carried out by advanced permanent threat (APT) groups supported by the 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, and the warnings by Ahn Labs that 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, "As also stated by the CISA, we have only recently witnessed some serious cases of this vulnerability being targeted by state-backed groups."
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 the year before. A recent telemetry analysis conducted by Tenable on Log4j vulnerability revealed that as of October 1, 72% of organizations have Log4j vulnerability. The analysis reveals that 28% of organizations around the world completely have eliminated this vulnerability, but organizations that improve their systems face the Log4j vulnerability over and over again as they add new assets to their environments.
In many cases (exactly 29% of organizations), 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: "In a scenario where we assume that organizations put the fix on the left side of the equation when they perform software pipelining, the reoccurrence rate needs to be reduced," and he added, "Most instances of recurrence and modifications are largely due to the software release cycle of organizations."
Moreover, despite the common awareness of the cybersecurity community about 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, "Transitive dependencies may not always be recognized or directly visible to your developers because they are born from your direct dependency choices."
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. Fox said, "Development of the patch for the component in question by companies has cost serious time and resources and exacerbated the negative effects of vulnerability."
Data from Sonatype's Maven Central Java repository reveals that 35% of Log4 versions are still vulnerable versions. Fox commented, "Many companies try to create their software inventory before finding a solution for this vulnerability, and they are unaware of the consequences 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.
Security researchers who have followed up on the Log4j vulnerability state that the only good thing about what has 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 find out 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, "Research into the Log4j vulnerability has reaffirmed the need for a better software supply chain in addition to SBOMs that keep pace with DevOps," and he added, "Application security and software architecture teams realized that it was not enough to look for risks in certain parts of applications, such as source code, APIs, or open-source packages. They now know that understanding the architecture of the software is as important as finding SQL injection (SQLi) or cross-site scripting errors (XSS)."
Source: Dark Reading