In this guest blog post, Yaffa Finkelstein, Product Marketing Manager of Cloud Security at Check Point Software Technologies, examines the Log4j vulnerability and how you can protect your systems from compromise.
Late in 2021, the Apache Log4j open-source logging framework made headlines — headlines that cloud security architects and specialists didn’t want to read. Since the dawn of the new year, the Apache Log4j remote code execution has become one of the most exploited vulnerabilities in cybersecurity history, affecting nearly half of all organizations globally. It is one of the most serious vulnerabilities the world has ever witnessed, and due to the complexity in patching it and its easiness to exploit, it is likely to stay with us for many years to come unless companies take immediate action to prevent attacks.
What is Log4j?
Log4j, an open-source logging library from Apache, is ubiquitous in its presence, directly embedded in major software applications. Part of the Java library still used by major enterprises for their web applications, Log4j is prevalent across many of the consumer apps that users interact with on a daily basis. It amassed more than 400,000 downloads from its GitHub project and more than 2 million downloads in the last quarter of 2021 alone. The tool is used by major cloud service providers and tens of thousands of applications that run on cloud platforms. All cloud providers are affected, as well as millions of websites and applications that connect to the internet.
Here is a timeline of the Log4j developments:
The scale of the potential damage is yet to be defined, but a quick online search shows the broad range of mechanisms that hackers could use very easily in order to exploit mainstream sites like Twitter, Minecraft, social media platforms, and other popular web-based applications.
What has been exploited?
Logging tools have rarely, if ever, been used by hackers before, but this issue allows unauthorized entities to take control of applications and move unabated throughout a network. Apache has rated this vulnerability (now known as Log4Shell) as “critical” and has published patches in an attempt to contain the potential damage. Log4Shell has also received the top common vulnerability scoring system (CVSS) score of 10. This vulnerability represents a critical flaw in a piece of code used at the foundation of a vast number of web applications and as such is considered extremely widespread and dangerous.
The Log4Shell vulnerability is contained within a lookup plugin that provides a way for Java apps to retrieve objects stored in a domain name server (DNS) or lightweight directory access protocol (LDAP) directory. The plugin provides the ability to do something more proactive than “just” log, and therein lies the key to the ability of the attacker to exploit a logging tool in order to hack an app.
What do the attacks look like?
Bad actors have created automated tools to detect applications that use Log4j in order to exploit the bug at scale. When considering the automated nature of this kind of attack, exploiting a vulnerability affecting such a huge number of web applications, it’s important to remember what security tools are in place. Most web applications are protected by a web application firewall (WAF), which is configured by security teams that are trying to keep up with their applications evolving quickly, at a speed that doesn’t limit their DevOps teams.
But typical WAFs cannot protect against these kinds of attacks — and in Log4j’s case, they were unable to prevent application and network disruption and takeover. The current WAF paradigm is rule-based, using binary rules to match requests to attack-signature databases, augmented by human administration and manual updating processes. But hackers often use automated tools that exploit all parts of an app and its application programming interfaces (APIs), and typical WAFs can’t recognize or defend against that. A new approach is needed, one that allows enterprises to use automation to keep their evolving apps and APIs protected at all times from both known and unknown threats.
How can organizations prevent these kinds of attacks and exploits?
The approach of traditional WAFs, relying on a rule-based system, human administration, and manual updates, cannot prevent these kinds of attacks. The paradigm must be built on machine learning and security based on artificial intelligence (AI), with full automation, in the cloud.
Fortunately, Microsoft Azure customers who have implemented CloudGuard AppSec in prevent mode were protected from day zero from Log4Shell and other Log4j exploits.
Contextual AI, using machine learning to train the AI engine, automatically protects applications like Log4j from any anomalous usage that indicates an attack. Unlike traditional WAFs, which frequently generate false positives, contextual AI-driven application security solutions provide zero-day prevention.
Check Point’s CloudGuard AppSec, available in the Microsoft Azure Marketplace, is this kind of contextual AI solution. AppSec customers are confident in its efficacy, demonstrated by the fact that 90 percent of them run the solution in prevent mode. Microsoft Azure customers who implemented CloudGuard AppSec were not only protected from Log4j’s exploit on day zero, but are also protected from similar kinds of attacks in the future. CloudGuard AppSec doesn’t rely on signature matching or manual updates to the security – unlike other WAFs, AppSec customers were protected from these attacks before the first attack took place.
The key: contextual AI engine
CloudGuard’s contextual AI engine builds a risk score for every request to the application. By considering all of the contextual parameters of a request (the user behavior, crowd behavior, content risk, and so forth), CloudGuard AppSec can precisely identify an attack with no human intervention. CloudGuard builds this risk score by learning from application usage over time, and the result is preemptive security that filters out false positives while providing precise prevention against zero-day attacks.
Learn more about CloudGuard AppSec in the whitepaper "Cloud Application Security Blueprint: Architectures and Solutions."
