In short, all versions of our Loadbalancer.org appliances are free from this vulnerability.
The Apache Log4j utility is commonly used for logging requests by millions of Java applications to log error messages. However, recently the critical vulnerability CVE-2021-44228 was discovered in the Apache Log4j library. This vulnerability has a CVSS severity level of 10 out of 10 so requires urgent attention, with attackers already taking advantage of this flaw.
As a result, the Apache Foundation recommends that all developers update the library to version 2.15.0, or use one of the approaches specified on the Apache Log4j Security Vulnerabilities page if this is not feasible.
The simplicity with which CVE-2021-44228 can be exploited makes it particularly dangerous - even a novice hacker can easily exploit this vulnerability. According to the researchers, attackers only need to compel the application to write one string to the log before using the message lookup replacement method to upload their own code into the application.
Working Proofs of Concept (PoC) for the attacks via CVE-2021-44228 are now currently available on the internet, however. As a result, it's no surprise that cybersecurity firms are already logging enormous network scans for weak applications and honeypot attacks.
Apache Log4j is part of the Apache Logging Project. By and large, usage of this library is one of the easiest ways to log errors, and that is why most Java developers use it. Many large software companies and online services rely on it and (because of its popularity), some information security researchers expect to see a significant increase in attacks on vulnerable servers over the next few days.
Loadbalancer.org software does not rely on Java in its code hence it does not include the Log4j package, so this vulnerability does not affect any of our appliances. It is crucial though to check all of your load-balanced applications to see if they are affected.
Can I use a load balancer to block hacking attempts on log4j?
When a zero day security issue such as this occurs the best option is to apply the critical patches as soon as possible. But what if the patch isn't available?
Well the best tool to use to gain you some time is a WAF, it's exactly the kind security issue it's designed to deal with. The WAF in the loadbalancer.org appliance is based on ModSecurity. I simply did a quick Google for code to block the log4j zero day exploit and found this detailed blog from our friends at the CRS project.
ModSecurity Rules to block log4j hacking attempts:
# Defense against CVE-2021-44228
SecRuleUpdateTargetById 932130 "REQUEST_HEADERS:User-Agent"
SecRuleUpdateTargetById 932130 "REQUEST_HEADERS:Referer"
Make sure the WAF is configured in blocking mode and you if you test it with the following simple curl command you should get a 403 access denied message:
curl 'http://www.example.com/?foo=%24%7B%24%7Blower%3A%24%7Blower%3Ajndi%7D%7D%3A%24%7Blower%3Armi%7D%3A%2F%2F127.0.0.1%2Fpoc'
I then started thinking maybe you could achieve the same effect with HAProxy rules? I simply did a quick Google for code to 'block log4j with HAProxy' and found this excellent blog from our friends at HAProxy.
HAProxy Rules to block log4j hacking attempts:
acl log4shell url,url_dec -m reg \${[^}]*\${
acl log4shell url,url_dec -m reg \${jndi:(?:ldaps?|iiop|dns|rmi)://
acl log4shell url,url_dec -i -m reg \${[\w${}\-:]*j[\w${}\-:]*n[\w${}\-:]*d[\w${}\-:]*i[\w${}\-:]*:.*}
acl log4shell req.hdrs -m reg \${[^}]*\${
acl log4shell req.hdrs -m reg \${jndi:(?:ldaps?|iiop|dns|rmi)://
acl log4shell req.hdrs -i -m reg \${[\w${}\-:]*j[\w${}\-:]*n[\w${}\-:]*d[\w${}\-:]*i[\w${}\-:]*:.*}
acl log4shell_form req.body,url_dec -m reg \${[^}]*\${
acl log4shell_form req.body,url_dec -m reg \${jndi:(?:ldaps?|iiop|dns|rmi)://
acl log4shell_form req.body,url_dec -i -m reg \${[\w${}\-:]*j[\w${}\-:]*n[\w${}\-:]*d[\w${}\-:]*i[\w${}\-:]*:.*}
http-request deny if log4shell
http-request deny if { req.fhdr(content-type) -m str application/x-www-form-urlencoded } log4shell_form
These are just temporary fixes, but it does show just how powerful these security tools can be when used in a production environment.