Recently, an extremely critical remote code execution vulnerability was made public for the Apache Log4j logging library.
If an organization or software made use of Apache Log4j logging library and the vulnerable version was running, it made it possible for malicious people to remotely execute commands which in many cases required no pre-requisites.
A comprehensive list of software that is vulnerable can be found here.
Even though we don’t expect many, if any, of our customers to be vulnerable to this vulnerability, Patchstack also published a firewall rule in order to protect WordPress sites that rely on some sort of Java application under the hood that uses this library.
Although requests still get logged (in the access and/or error logs) by the webserver, it might just be enough to protect some of our customers against the potential successful exploitation of this vulnerability.
As we added the firewall rule, we quickly noticed a rapid increase in blocked attacks. Below we will describe some of the payloads we have seen.
These payloads were present in different ways, some examples include the User-Agent header, X-Forwarded-For header, in the URL, and as a raw POST payload.
Most attacks came from 2 IP addresses: 220.127.116.11 and 18.104.22.168 covered about 15% of each of all attacks that we have seen.
Vulnerabilities like this show just how difficult it can be to always be protected from all vulnerabilities at all times. The public was only made aware of this because of the publicization of this vulnerability.
Had this not happened, it could’ve had a significant impact on the security state of many organizations.
A vulnerability can always be lurking around the corner and often you cannot do much about it until the vendor publishes a patch for it.
Even though we do not protect Java applications, it is still good to rely on a firewall to prevent your website or application from being exploited while you are waiting on information on how to patch or update the vulnerable software.