A critical remote code-execution vulnerability (CVE-2021-44228) has been publicly disclosed in Log4j, an open-source logging utility that’s used widely in applications, including many by large enterprise organizations.
The vulnerability allows threat actors to exfiltrate information from, and execute malicious code on, systems running applications that utilize the library by manipulating log messages. There are already reports of servers performing internet-wide scans in attempts to locate vulnerable servers, and our threat intelligence teams are seeing attempts to exploit this vulnerability at alarming volumes. Log4j is incorporated into many popular frameworks and many Java applications, making the impact widespread.
What is the Log4j Vulnerability?
On December 9, 2021, a critical vulnerability involving unauthenticated remote code execution and data exfiltration (CVE-2021-44228) in Log4j was reported, causing concern due to how commonly the open source logging function is used. This widespread usage, combined with the ease of exploitation, makes its impact particularly large. The vulnerability is actively being exploited, and security teams worldwide are working on research and mitigations.
A compromised machine allows a threat actor to exfiltrate data and remotely provide software that Log4j executes. This grants an attacker the ability to run arbitrary commands inside a server, exposing information and secrets, as well as allowing that server to be a launchpad for additional attacks, potentially against machines secured deep inside of a network with no direct access to the internet.
Developers in the Java world use Log4j extensively to facilitate the logging of errors and debug information. As a result, product vendors whose software is based on Java may be vulnerable. Even if an application doesn’t use Log4j directly, many common tools and frameworks use Log4j internally and thus may introduce this vulnerability into the application stack.
What is the severity of the Log4j vulnerability?
Although Akamai first observed exploit attempts of the Log4j vulnerability on December 9, we see growing evidence suggesting it may have been exploited for months. Since publication of the vulnerability, we have seen multiple variants of the exploit at a sustained rate of attack traffic of around 2M attempts per hour. The speed at which the variants are evolving is unprecedented.
More than half (~57%) of the attacks seen so far are from attackers previously classified as malicious actors in Akamai’s threat intelligence database. We anticipate that due to the sheer volume of unpatched systems, we will continue to see exploit attempts for months to come.
While the most important action to take during any vulnerability is to patch infected systems, security researchers understand that takes time. In many instances, organizations might not yet even have visibility into which systems are vulnerable. As such, additional mitigations must be deployed to reduce the threat surface as much as possible.
Many servers, especially those in high-risk environments such as directly accessible to the internet, may already have been compromised. To identify indicators of compromise, the following command can show exploitation attempts:
sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns)://’ /var/log
While WAF protections can be highly effective for web servers at this stage, organizations must also consider alternative avenues of attack that may have led to compromise. To that end, we recommend employing microsegmentation to gain visibility to possible exposure and to reduce risk and spread.
Detection of Log4j abuse using Enterprise Threat Protector
Akamai threat researchers have been reviewing customer DNS, proxy, and sinkhole data looking for anomalous behavior relating to the actors attempting to use Log4j vulnerability in the wild. In the DNS data, we were surprised to see DNS queries for domains containing the string “jndi:ldap”.
These are invalid DNS queries that contain invalid characters in the domain name and therefore will not resolve. Additionally, we have seen traffic to known malicious domains that were redirected to sinkhole servers; those domains hosted malicious Java code that was used to abuse vulnerable servers. All of these are indications of potential abuse within customer networks.
