Apache Log4J Vulnerability: Effective Mitigation Strategies from AWS

In light of recent technological advancement, vulnerabilities are inevitable.  On December 9th, the Apache Foundation published an article on a Zero-Day vulnerability in the Log4j Java library.  AWS is among the many significant software firms and online services that utilize the Log4j library.

CVE-2021-44228 (Log4J) has kept AWS security researchers busy in the last few days as they attempt to fix the vulnerability in Apache Log4j, a widely used open-source logging platform in the Java community to record error messages in java libraries.

How Log4J Works and its Effects on AWS

The Log4j vulnerability (CVE-2021-44228) flaw enables an attacker to remotely execute code on the vulnerable platform. Version 2 of Log4j is impacted, between 2.0-beta-9 to 2.15.0, which spans the timeframe of 2021-9-2 to 2021-12-09. The vulnerability makes use of the Java Naming and Directory Interface (JNDI), which is utilized by a Java application to locate data, often via a directory, and in this instance, an LDAP directory.

The vulnerability can be exploited as long as there is some sort of network access to the system from external to internal. Even if the system is not public, it can still be easily compromised as the vulnerability is non-authenticated.

If attackers successfully exploit the data on one of the servers, they will execute arbitrary code and possibly obtain complete control of the system.  Notably, the problem does not just affect services built entirely in Java ; it only takes a single java application or dependency utilizing the log4j library on the network to cause the problem.

Due to the pervasive nature of the Log4j library, all Java code must be checked, including Linux, Mac, and Windows.

AWS Mitigations Against Log4J Vulnerability

1. Update Log4j to Version 2.16.

To mitigate this issue, AWS suggests that individuals running impacted applications update Log4j to version 2.16 .  Updating Log4J offers the easiest and most effective protection, while mitigations can still be compromised.

2. Apache Log4j Hot Patch

Security is a top concern of Amazon Web Services partners. As part of the response to the Apache Log4j vulnerability, AWS has created an RPM hot patch that performs a JVM-level hot patch, disabling the Log4j2 library’s ability to execute JNDI lookups. The Apache Log4j2 node agent is an open-source project developed by AWS' Corretto team.  This program also searches for any running JVMs and tries to mitigate the vulnerability.

For further information on installing this node agent, this utility is now accessible at GitHub .

3. Altering Log4j Settings

If you cannot update to version 2.16.0, which restricts access to JDNI by default , you may prevent this issue by altering your Log4j settings. To apply this mitigation in versions greater than 2.10, remove the JndiLookup class from the classpath.

4. AWS WAF

Customers should utilize AWS Web Application Firewall to help safeguard their Amazon CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer, or AWS AppSync GraphQL API resources by following AWS Managed Rules for AWS WAF. By utilizing the AWS WAF, you can help protect your application from common vulnerabilities and injections such as the OWASP Top 10 .

5. AWS Network Firewall

Customers should install network-based detection and protection using Suricata-compatible IDS/IPS rules in AWS Network Firewall. These rules may aid in detecting both scanning and post-exploitation of the Log4j vulnerability.

Customers should also consider creating outbound port/protocol enforcement rules that monitor or block instances of protocols like LDAP from accessing non-standard LDAP ports like 53, 80, 123, and 443.  Monitoring or blocking the use of port 1389 outbound may be very useful in detecting computers that internet scanners have prompted to conduct external command and control calls. In addition, LDAP ports inbound to your infrastructure shouldn’t be open, and only LDAPs should be exposed where necessary.

6. Amazon Inspector

The Amazon Inspector team has provided coverage to detect the presence of Log4J vulnerability in the Amazon EC2 instances and Amazon Elastic Container Registry Images (Amazon ECR).  Scanning is automatic and continuous using the new Amazon Inspector.

7. GuardDuty

Amazon GuardDuty watches for attempts to connect to known-bad IP addresses or DNS entries.  It can also detect post-exploit activities using anomaly-based behavioral analysis and record the behavior.

8. Make Use of IMDSv2.

After the first JDNI vulnerability has compromised a host, attackers would occasionally attempt to harvest credentials from the host and transmit them out through some means such as LDAP, HTTP, or DNS lookups.  We suggest that users utilize IAM roles rather than long-term access keys instead of storing sensitive information like credentials in environment variables.

Customers may use AWS Secrets Manager to store and automatically rotate database credentials rather than keeping long-term database credentials in the environment variables of a host.  Customers should also consider demanding the usage of Instance Metadata Service version 2 to defend against such attacks in AWS.

Our partner Trend Micro has developed a tool that you can use to test if your environment is vulnerable by calling the different API endpoints or generating a special cURL request: https://log4j-tester.trendmicro.com/

Finally, we propose installing security solutions like Trend Micro Cloud One™ Workload Security on your AWS servers; in many circumstances, this would enable the early detection of any threats related to this vulnerability and stop them early before causing too much harm.

Contact us if you have any questions related to this vulnerability and how to best use the remediations that AWS has implemented to help.