Log4J, Apache and ModSecurity

(I’ll be updating this post as more rules are available to stop new vulnerabilities.)

Credit to Christian Folini at coreruleset.org for providing the rule.

A major vulnerability has been discovered in Java web apps basic logging function called Log4J/Log4Shell. The best remedy for this is to update Log4j itself, or update the web app platform running Log4j with a newer version provided by the vendor. But that may take a while in many instances to fully implement.

As a stopgap solution, you can implement ModSecurity and Apache (reverse proxy setup) as a Web App Firewall reverse proxy (WAF) in front of your web applications in order to mitigate the potential for attacks. This is merely a front end mitigation, you still need to fix the source of the problem. Most large operations already have some sort of WAF in front of their web apps and just need to add a rule to prevent this attack until they can fix Log4j in their environments.

However in some cases, smaller operations in the cloud or elsewhere may need something pretty quick to mitigate attacks as they don’t have the resources or personnel to tackle such a project.

What follows is a very brief explanation of how to go about doing that (this is assuming a lot of background):

1. In a Linux environment (Ubuntu, Debian, et al) or even a container in the cloud, setup Apache as well as the ModSecurity module.
2. Setup Apache to function as a reverse proxy, pointing to your internal web apps.
3. Using this OWASP rule below, modify the ModSecurity rules, specifically setting it as a rule before the main core rules (CRS) to include the following definition:

# Generic rule against CVE-2021-44228 (Log4j / Log4Shell)
# See https://coreruleset.org/20211213/crs-and-log4j-log4shell-cve-2021-44228/
SecRule REQUEST_LINE|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS|XML:/|XML://@ "@rx (?:${[^}]{0,4}${|${(?:jndi|ctx))" 
    "id:1005,
    phase:2,
    block,
    t:none,t:urlDecodeUni,t:cmdline,
    deny,
    log,
    msg:'Potential Remote Command Execution: Log4j CVE-2021-44228', 
    tag:'application-multi',
    tag:'language-java',
    tag:'platform-multi',
    tag:'attack-rce',
    tag:'OWASP_CRS',
    tag:'capec/1000/152/137/6',
    tag:'PCI/6.5.2',
    tag:'paranoia-level/1',
    ver:'OWASP_CRS/3.4.0-dev',

I have modified the above to deny the request instead of just logging it as it was doing on my system for some reason (maybe designed to do that?). So instead of just logging it and allowing the 200 request to pass through regardless, I send it a 403 to block it altogether.

You’ll also want to include the following. From the blog post at coreruleset.org:

---

The quick fix is to add the User-Agent and the Referer to the targets of the rule. Do this by adding the following two directives after the CRS include in your configuration:

# Defense against CVE-2021-44228
SecRuleUpdateTargetById 932130 "REQUEST_HEADERS:User-Agent"
SecRuleUpdateTargetById 932130 "REQUEST_HEADERS:Referer"

There is a certain chance this update will trigger new false positives. Personally I do not expect too many, but you have been warned.

If you want to extend the coverage to all HTTP headers, then the following should be applied:

# Defense against CVE-2021-44228 
SecRuleUpdateTargetById 932130 "REQUEST_HEADERS"

---

Hope this provides some kind of prevention for your web applications.

This post will be updated as new rules come out to thwart exploit attempts as new bugs are discovered.