Akamai Recommendations for Log4j Mitigation
Executive summary
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.
Akamai’s extensive security suite, including Application and API Security solutions, Secure Internet Access Enterprise, and Guardicore Segmentation, is well positioned to help address this vulnerability in different ways. It’s highly recommended that organizations update Log4j to its latest version, 2.16.0. Due to the rapidly escalating nature of this vulnerability, Akamai teams will continue to develop and deploy mitigation measures to support our customers.
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. Akamai’s security research and incident response teams continue to monitor and protect our infrastructure and customers, leveraging our unique visibility and intelligence.
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.
To assist in this, Akamai has a number of recommendations. At this time, the greatest amount of attack traffic that we are seeing associated with Log4j is web application–based, therefore the most impactful step that organizations can take after patching is to leverage Akamai’s Web Application and API protections. Read on to learn how and what to do inside your enterprise as attack vectors evolve.
Mitigating Log4j abuse using Akamai App and API Protection suite
Akamai continues to update web application firewall (WAF) rules to provide protection against this exploit and its many variants. This includes updating rule 3000014 within Akamai’s Kona Rule Set and Adaptive Security Engine. For customers using the Automated Attack Groups, we have updated the Command Injection group. Any customers who currently have those rules or attack groups activated in DENY mode will receive automatic in-line protection for the following protection engines and versions:
Kona Rule Set — Any version dated October 29, 2019 or later
Automated Attack Groups — Any version
Adaptive Security Engine — Any version
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
To learn more about Akamai’s Web Application and API protections, read more or contact us.
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 Secure Internet Access Enterprise
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.
Mitigating Log4j abuse using Akamai Guardicore Segmentation
Customers using Akamai Guardicore Segmentation can leverage its process-level visibility to identify vulnerable applications and security risks in the environment. This can then be used to enact precise control over network traffic to stop attacks on vulnerable systems, without disruptions to normal business operations.
What’s under threat: Identify vulnerable Java processes and Log4j abuse
To protect against potential Log4j abuse, it is necessary to first identify potentially exploitable processes. This requires deep visibility into network traffic at the process level, which is provided by Akamai Guardicore Segmentation. Precise visibility into internet connections and traffic allows us to see clearly what mitigation steps need to be taken without disrupting business operations.
Stopping the attack: Block malicious IoCs and attack vectors
It is imperative to be able to take action once vulnerable applications have been identified. While patching is underway, Akamai Guardicore Segmentation offers a multitude of options for alerting on, stopping, and preventing attacks. Critically, a solution with detailed and precise control over network communication and traffic is required to surgically block or isolate attack vectors, with minimal to no disruption to normal business functions. These include:
Automatic IoC blocking with Threat Intelligence Firewall (TIFW) and DNS Security
Fully quarantine compromised servers
Block inbound and outbound traffic to vulnerable assets
Block outgoing traffic from Java applications to the internet
Additionally, Guardicore Hunt customers have their environments monitored and investigated continuously by a dedicated team of security researchers. Alerts on security risks and suggested mitigation steps are immediately sent.
If you’d like to hear more about Akamai Guardicore Segmentation, read more.
Conclusion
Akamai will continue to share its insights as we closely monitor and research Log4j exploits and provide timely updates to our protections and capabilities.
