Interviews

Remembering Log4j vulnerability- Learnings and the way forward

Photograph by Nishant Ratnakar

CXOToday has engaged in an exclusive interview with Ms. Kavita Viswanath, General Manager, JFrog India

 

What is Log4j? How was this detected by the industry and what was its impact?

Log4Shell, an internet vulnerability that affects millions of computers, involves an obscure but nearly ubiquitous piece of software, Log4j, which records events—errors and routine system operations—and communicates diagnostic messages about them to system administrators and users. Log4j software is used to record all kinds of activities that occur behind the scenes in a variety of computer systems.When the Log4Shell zero-day vulnerability hit on December 9, 2021, it was quickly categorised as “the most serious vulnerability in years,” impacting hundreds of thousands of businesses and millions of users. One of the major concerns about Log4Shell is Log4j’s position in the software ecosystem. Logging is a fundamental feature of most software, which makes Log4j very widespread. In addition to popular games like Minecraft, it is used in cloud services like Apple iCloud and Amazon Web Services, as well as a wide range of programmes from software development tools to security tools.

 

Cyber-attacks have increased exponentially, what is the potential for another Log4j happening, and what steps is the industry taking to prevent that from happening?

According to government data, in 2019, the total number of cyber security incidents tracked by the Indian Computer Emergency Response Team (CERT-In) was 3,94,499. The number spiked to 11,58,208 in the year 2020 and further increased to 14,02,809 in 2021. This year, as many as 6,74,021 cyber security incidents were reported through June.

The likelihood of another Log4j incident is considerable. Tenable Research finds 72% of organisations remain vulnerable to the Log4j vulnerability. Another 12 vulnerabilities have been uncovered since the prior vulnerability, but their severity may vary. Installing a system update or an application patch is the most usual technique to address a vulnerability.

The rate at which a change can be pushed into production is an important measure. According to DORA, exceptional performers may finish this cycle in less than an hour, but most organisations will take a day to a week to complete the cycle, after they’ve located all the code to be fixed. One needs to improve their skills in both finding and shipping. And here is where a solid DevOps/DevSecOps approach comes into play, as it maintains your vulnerability database up to date, helps spot risks early, and speeds up patch implementation.

 

What were the major learnings from the Log4J vulnerability?

Log4j was an interesting vulnerability that emphasised the following points –

  • Vendors need a way to mitigate critical vulnerabilities, preferably without making code changes, without upgrading the vulnerable package. We saw many vendors struggle with upgrading Log4j since the fixed version broke APIs for some older Log4j versions. Due to that – many vendors decided to apply workarounds such as removing the vulnerable class from the deployed Log4j binary, since this method was extremely fast, applicable in the deployment environment, and was guaranteed to keep existing code intact.
  • The use of DevOps-centric security can take down reaction time from weeks to days or even hours, and we saw that vendors who had a deployed DevOps solution were able to find the affected Artifacts much more quickly or even use their DevOps-centric security deployment pipeline to block/remove binaries that depended on an affected Log4j component.

From what we can see in the JFrog Artifactory cloud, there are about 1000 unique Artifacts that are still impacted by the log4j vulnerability. As a result, it is clear that efforts to patch and upgrade systems using Log4J are not yet complete.We expect attackers to continue trying to exploit the log4j vulnerability in 2023 as well, since the exploitation is practically “free”—the vulnerability is extremely suitable for drive-by attacks, which require no research efforts from attackers, and many public tools exist for automating the exploitation process.

In terms of future vulnerabilities that may resemble Log4Shell, we’ve seen a number of similar issues in Java libraries in 2022, such as SpringShell and TextShell, which have the same critical-severity impact (stable remote code execution with a public exploit) but have preconditions that reduce the number of actually vulnerable systems.As expected, most concerns about these two vulnerabilities were quickly quenched after the community realised the extent of their conditions. We expect more critical-severity Java vulnerabilities to pop up in 2023, but it is unlikely that we will see a vulnerability that affects such a widespread array of systems as Log4Shell.

 

Have Indian businesses done enough to be prepared for the next Zero-Day Vulnerability? If not, what are the key things you recommend businesses keep in mind in terms of their security planning to prevent the next Log4j?

Log4J, was exploited by attackers to target organisations worldwide, including companies in India.. Software testing has always been challenging, but the inherent complexity of Log4j brings this challenge to a new level. The Log4Shell vulnerability (CVE-2021-44228) has been around since 2013 without getting noticed. What tools could have been used to successfully discover the Log4Shell vulnerability before it shook the industry when exposed as a zero-day? Is it realistic to expect automated detection of such security vulnerabilities when they are still unknown? If so, then how come a heavily tested module like Log4j escaped all lines of defense?

To be better prepared to handle future zero-day vulnerabilities, I suggest IT and DevOps teams take the following steps:

  1. Make sure your system updates and application patches are up-to-date, being sure to cross-check with publicly available databases like the national vulnerability database (NVD) for the most recently discovered vulnerabilities and recommended fixes. You can also consult security research blog sites such as https://research.jfrog.com/.
  2. Data flow static analysis promises to enable developers to identify vulnerabilities involving manipulated user inputs, like Log4Shell, early on. Today data flow analysis is an active area of security research; bringing this technology to widespread use within developer tools and as part of DevSecOps processes should be an industry target.
  3. For zero-day vulnerability detection, it’s important to keep in mind that developers do not always know what security warning signals to look for. But, having an automatic “companion” – such as an static composition analysis (SCA) tool–that puts its virtual finger on user-controlled input being passed around can be a great help.
  4. Fuzzing is a powerful dynamic analysis technique for detecting unknown vulnerabilities by running a programme on random (or pseudo-random) inputs and looking for situations when it crashes or violates specific assertions.
  5. The industry needs to move toward a more “interactive” type of static analyzer. One can imagine an IDE that highlights suspicious-looking “data flow hints” in red and strong font, allowing programmers to check them out when they appear. Extending this idea even further, programmers may choose to zoom in on certain code areas and define their own (internal, non API) sources. This adaptable technique could be a game-changer in zero-day vulnerability identification.

Leave a Response