Log4j Vulnerability – Technical Details
April 12, 2022
In December 2021, log4j aka CVE-2021-44228 was publicly released and rapidly was flagged as one of the most critical security vulnerabilities in recent years. This article will talk about this vulnerability in depth – why it is critical and how Indusface detects and protects against the vulnerability.
Log4j – The Zero-Day Vulnerability
Log4j is a logging library, part of the Apache Software Foundation’s Apache Logging Services project, that is pretty much ubiquitous in applications and services built using Java.
Applications regularly log many pieces of data continuously, often at every request/transaction, for various purposes like telemetry, analytics, enabling post facto diagnosis of issues, etc. With computing and storage becoming ever cheaper, logging has become more verbose over the years. A lot of the data logged comes from user requests which means an attacker can control what is logged. For example, web applications typically log the user-agent to categorize devices used to access the application.
It may seem strange that a vulnerability in a logging library can be this critical even if attackers can control what is logged since logs are generally understood to be simple string data. However, log4J allows lookups that can be used to enhance the log messages. For example, information like environment variables, hardware, and locale can be added to the log message to aid developers in debugging issues. One of the lookups supported was JNDI (Java Naming and Directory Interface) which allows looking up and loading Java objects by name and crucially allowed loading and executing java code from remote servers such as LDAP servers. An attacker could send a crafted string which, when logged, could execute arbitrary code in the context of the process that is writing the log.
Another reason this vulnerability is so insidious is that data flows through many systems, sometimes transformed and other times unchanged for processing as well as for analytics. In all these steps and systems, logs will be generated. This means that even if the system facing the internet is not vulnerable, other internal systems and 3rd party services that are used could also be vulnerable. Finding the attack surface and vulnerable systems is not straightforward.
How Does Indusface Detect This Vulnerability?
Dynamic testing for the vulnerability is not straightforward since logs may be generated and written at any time so the checking must be out of band i.e., a simple ‘send attack, check response’ will not suffice. Indusface uses a specially crafted JNDI attack vector containing a unique subdomain of a domain that we control. If a log using this vector is generated on a vulnerable system, log4j will trigger a DNS lookup of that subdomain and when we detect the DNS lookup, we know that the system is vulnerable. The Indusface WAS scanner will scan all areas of the application request such as header, query parameters, cookies, etc., and will provide all the attack details when the vulnerability triggers pinpointing to the exact page, parameter and attack. Since logs may not be generated immediately on the system, the vulnerability may be reported some time after the scan and not immediately.
In one interesting case, we reported a vulnerable log4j system a week after the probe was sent. Even though the application is scanned daily, we always reported the alert only on a particular day of the week. On further investigation, we narrowed this down to a process that executes weekly to perform tasks like summarizing and auditing and that process was vulnerable to log4j.
Protection and Mitigation
Due to the nature of this vulnerability, successfully exploiting a vulnerable system is complicated but the threat is serious, and attacks are still going on. As can be seen in the chart below, attacks, are being blocked by AppTrana everyday even months after the vulnerability was disclosed.
Figure 1: Attacks still occur regularly
The figure below categorizes the areas being targeted for possible Log4j vulnerabilities. Unsurprisingly, HTTP headers dominate since many headers will typically be logged by the application.
Figure 2: Split of areas being targeted (Headers dominate)
Indusface AppTrana provides real-time protection and visibility for attacks targeting the log4j vulnerabilities since December 2021. Additionally, Indusface recommends that all customers apply the mitigation steps to guard against this vulnerability.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.
