What is the Log4j Remote Code Execution issue?
On Dec.10, 2021, Chen Zhaojun from Alibaba’s Cloud Security team discovered a new, critical Log4j vulnerability was disclosed: Log4Shell. This vulnerability within the popular Java logging framework was published as CVE-2021-44228, and categorized as Critical with a CVSS score of 10 (the highest score possible).
All current versions of log4j2 up to 2.14.1 are vulnerable. Update to version 2.15.0 or later to remediate this vulnerability.
Many application frameworks in the Java ecosystem use this logging framework by default. For instance, Apache Struts 2, Apache Solr, and Apache Druid are all affected. Aside from those, Apache Log4j is also used in many Spring and Spring Boot applications, so we suggest you check your applications and update them to the latest version.
An attacker can leverage the weakness discovered in log4j to attack an application in what is commonly referred to as Remote Code Execution (RCE). Essentially, an attacker can trick a vulnerable application into running commands passed by the threat actor. In this particular case, the attack vector is using LDAP services to deliver malicious code back to the server running the vulnerable library. This could result in placement of remote access tools or discovery of other services / secrets within the application running environment.
Does use of StackHawk expose any risk of Log4j attacks?
The StackHawk service does not use Log4j logging within our infrastructure. Our internal logging capabilities are provided via other tooling. The StackHawk scanner (HawkScan) is based on the Zed Attack Proxy (ZAP), which does use the Log4j packages for internal logging purposes. ZAP and HawkScan have been updated for this particular issue. Simon Bennetts, ZAP project lead, has written a blog post about ZAP’s patching status for more information on this issue.
StackHawk has pulled in the patched version of ZAP to update the vulnerable version of Log4j used in the project. This beta release will be available on Monday, Dec. 13th. Users can download and use it by simply running the ‘docker pull stackhawk/hawkscan:beta’ or ‘docker run … stackhawk/hawkscan:beta’ as their normal run command.
In typical deployment, it is extremely unlikely that StackHawk’s scanner can expose a customer to the Log4j vulnerability. There are mitigating factors that prevent exploitation of StackHawk with this vulnerability:
StackHawk’s scanner does not expose externally the ZAP API which could have been used to trigger this vulnerability.
StackHawk’s scanner is ephemeral in nature, reducing or completely removing the possibility of persistence due to this RCE.
StackHawk’s scanner is run inside a customer's environment and should not be publicly available to attack.
As an example, to potentially exploit StackHawk’s scanner, a user would need to set up an intentionally malicious web application in their company’s environment and scan it with StackHawk.
How to check for Log4j in your environment
There are many ways to find vulnerable versions of Log4j in use. One of the most effective ways to detect these vulnerable versions is with Software Composition Analysis (SCA) tools. These tools can point out where your applications are pulling in vulnerable versions of open source dependencies and suggest how to update to non-vulnerable versions. This does mean you have to compile and deploy your applications to have protection from the updated library. StackHawk has some great partners to use for SCA detection of the vulnerable Log4j library:
Does StackHawk detect Log4J vulnerabilities?
In addition to SCA tooling, the RCE vulnerability found in Log4j may be detected in running applications with a testing method referred to as Out of Band Application Security Testing (OAST). This is a third service that an affected client would reach out to indicating that it is vulnerable as described in the image below.
The StackHawk Log4Shell Detection Beta is here!
As you may know, Log4Shell is a recently discovered vulnerability that affects the popular Java logging framework Log4j2.
What makes StackHawk’s Log4Shell detection different? Tests are simple to configure with a YAML file and run independently of your normal StackHawk scans so they can execute quickly. Most importantly, instead of just telling you that you have an out-of-date library, we can detect whether your application actually has a discoverable and exploitable Log4Shell vulnerability, and can give you confidence that you’ve successfully mitigated it.
To see how to configure your own Log4Shell test, check out the docs here.
You can also use ZAP to check running applications for the presence of the Log4J vulnerability using the newly released Log4J Test Plugin and setting up OAST services with ZAP as per the ZAP blog post.
