Recently, a Remote Code Execution vulnerability was discovered in the Apache Log4J library. This vulnerability, which is tracked in CVE-2021-44228, dubbed Log4Shell, allows attackers to execute arbitrary code on affected systems.
While HAProxy, HAProxy Enterprise, HAProxy ALOHA, and other products within the HAProxy Technologies portfolio are not impacted by this (they do not use the Log4J library at all), you can use them to block the attack.
These mitigation techniques we describe are subject to change as attackers come up with new evasion methods, new false positives are discovered, or better ways to handle this are found. When the rules change this blog post will be updated with a changelog added to the top. While these rules have been tested, it is possible that there are false positives or false negatives still remaining, so for sensitive environments we recommend testing these rules in your environment (such as replacing the http-request deny rules with an http-request capture rule to log violations rather than deny them outright). Use HAProxy or HAProxy Enterprise 1.8 or newer, or HAProxy ALOHA 10.5 or newer, to use the syntax we describe.
Regardless of these protections, if you are using Log4j in your environment you should update to 2.16.0 or newer from their download page.
If your applications log (or might log) information in the post body you might want to consider expanding the filtering of the post body. Some applications log user names or transactions id’s in the post body and should have req.body filtered, due to false-positive risk with there being no json_parse decoder we don’t include it by default (nor does ModSecurity CRS), but it can be enabled easily if it fits your environment (and you can monitor/tolerate false positives). This can be done by adding more deny/acl lines like ‘log4shell_form’ to decode/scan specific content types if using ACL’s or by adding REQUEST_BODY to the match zones on the SecRule line if using ModSecurity.
To block the attack, add the following ACLs, which are an adaptation of the ModSecurity solution described later, to a frontend or listen section within your load balancer configuration:
| frontend myfrontend | |
| option http-buffer-request | |
| acl log4shell url,url_dec -i -m reg (?:\${[^}]{0,4}\${|\${(?:jndi|ctx)) | |
| acl log4shell req.hdrs -i -m reg (?:\${[^}]{0,4}\${|\${(?:jndi|ctx)) | |
| acl log4shell_form req.body,url_dec -i -m reg (?:\${[^}]{0,4}\${|\${(?:jndi|ctx)) | |
| http-request deny if log4shell | |
| http-request deny if { req.fhdr(content-type) -m str application/x-www-form-urlencoded } log4shell_form |
Alternatively, enable the ModSecurity WAF module:
Find the following line in the file /etc/hapee-2.4/modsec.rules.d/lb-modsecurity.conf:
| Include /etc/hapee-2.4/modsec.rules.d/crs-setup.conf |
Or find the following line in the file /app/security/etc/sec-offloader/modsecurity.load in HAProxy ALOHA :
| Include modsecurity/crs-setup.conf |
Then add the following rules directly after:
| 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,\ | |
| log,\ | |
| msg:'Potential Remote Command Execution: Log4j CVE-2021-44228', \ | |
| logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\ | |
| 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',\ | |
| severity:'CRITICAL',\ | |
| setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\ | |
| setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" |
These rules can be found on the Log4j blog post from coreruleset.org. If this is the first time you are enabling the ModSecurity WAF, we recommend running it in detection-only mode at first, to log malicious requests, but not immediately block them.
With HAProxy Enterprise, you can also block the attack by enabling the Advanced WAF:
Then update your ruleset files by updating to the latest hapee-2.4r1-lb-wafadvanced package (or using the corresponding package for your version of HAProxy Enterprise). Follow the documentation for how to set thresholds for blocking threats.
If this is the first time you are enabling the Advanced WAF, we recommend running it in learning mode at first, to log malicious requests, but not immediately block them.
To test if the mitigations you have configured are working correctly, try the following curl command:
| $ curl 'localhost/?foo=%24%7B%24%7Blower%3A%24%7Blower%3Ajndi%7D%7D%3A%24%7Blower%3Armi%7D%3A%2F%2F127.0.0.1%2Fpoc' |
If the blocking rules are working correctly, that request will be denied.
Changelog:
12/15 9:30 AM EST: Updated ModSecurity rule based on CRS guidance
12/15 9:30 AM EST: Fixed incorrect filename for HAProxy ALOHA
12/15 11:00 AM EST: Updated ACL example to use simplified rules
12/15 5:15 PM EST: Updated ModSecurity and ACL rules based on CRS guidance
12/17 3:41 PM EST: Added guidance on post body filtering
12/20 11:00 AM EST: Updated ModSecurity targets per CRS guidance
