Log4J, NGINX 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 NGINX (reverse proxy setup) as a Web App Firewall proxy (WAF) in front of your web applications in order to mitigate the potential for attacks. You could also use Apache as a reverse proxy with ModSecurity as well, and in some situations may be easier to setup. But this is what I did using NGINX. This is merely a front end mitigation, you still need to fix the source of the problem, Log4J. 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:

1. In a Linux environment (Ubuntu, Debian, et al) or even an NGINX container in the cloud, download and install NGINX and compile the ModSecurity module along side of it.
2. Setup NGINX 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 (I did this in the /etc/nginx/modsec/owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf file) 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,\
    deny,\
    t:none,t:urlDecodeUni,t:cmdline,\
    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.