What is Log4J?
With the continuous coverage, it is pretty certain by now every 5th grader knows what Log4Shell is but just in case you missed the news, it is a recently discovered vulnerability in a ubiquitous Java logging framework LOG4J. The vulnerability has been given a CVSS Score of 10, making it the most serious of discovered flaws.
VentureBeat is reporting that Log4J attacks have been attempted on 44% of corporate networks
Log4J Vulnerability and Impact
The diagram below provides an overview of how the Log4J vulnerability works (courtesy of Juniper Networks Threat Labs).
Once attackers are able to exploit the Log4J vulnerability they can remotely inject code into services that use the library with system-level privileges. This allows attackers to send requests to any application on the server as well as retrieve information about the system itself or, in the worst-case scenario, get full control of the environment by sending a request like this one:
With a version of this last request, the vulnerability is exploited and allows the hacked server to start a connection with the attacking host through JNDI. The resulting connection provides the attacker with several options to take control of the vulnerable server and extract valuable information such as accounts, passwords, or internal configuration.
WAFs are ineffective as Log4Shell and Zero Day defenses
Many organizations rely on Web Application Firewalls (WAFs) for application security, and protection against attacks on vulnerabilities. Unfortunately, WAFs are a signature-based technology and can help only when signatures for attacks become available and polymorphic attacks such as Log4J easily bypass WAFs. Twitter is abuzz with such examples of these attacks.
WAFs typically do not have the visibility to see out-of-band attack elements such those in Log4J as shown in this analysis (courtesy of Sophos Labs).
The obvious fix is to detect the existence of vulnerable libraries and upgrade them to a minimum version of 2.17.0. For vendor proprietary applications, IT teams need to obtain updated software directly from the vendor. Additional guidance is on the CISA (Cybersecurity and Infrastructure Security Agency) government site.
In cases where upgrading is not feasible, protection against attacks is still available using Runtime Application Self Protection (RASP) solutions and is highly recommended to prevent attacks on vulnerable applications.
In more recent developments, another vulnerability was discovered in the same library that can result in denial-of-service attacks and hence the recommendation to upgrade to a minimum of release 2.17.0 which includes the fix.
There are now many free tools available to scan for Log4J. Here is one of available on Github.
K2 can detect and block Zero Day Attacks like Log4J
K2 detects and blocks all attacks without the need for any signatures, and in attacks where signatures are not yet available, such as Log4J, when it was announced.
In the example shown below, the K2 RASP deterministic engine detected, and blocked Log4J before the CVE was issued.
Figure 1. K2 Security Platform detecting and blocking an attack on LOG4J2 without patching
Demo 1. K2 Security Platform detecting and blocking an attack on LOG4J2 without patching
Figure 2. K2 Security Platform detecting vulnerable libraries
Demo 2. K2 Security Platform detecting vulnerable libraries
How does K2 do it?
K2 Security Platform uses runtime deterministic security to monitor the application and has a deep understanding of the application’s control flows, DNA and execution. By validating the application’s control flows, deterministic security is based on the application itself, rather than relying on past attacks to determine a zero-day attack. Deterministic security results in the detection of sophisticated zero-day attacks and protects from application from the risks listed in the OWASP Top Ten, including RCE, XSS and SQL Injection.