We can all agree at this point that the Log4Shell vulnerability (CVE-2021-44228) can rightfully be categorized as a celebrity vulnerability. Security teams have been working around the clock investigating whether they have instances of Log4j in their environment. You are likely very familiar with everything regarding Log4Shell, but if you are looking for more information, you can check out our Everyperson’s Guide to Log4Shell (CVE-2021-44228). In this blog, we will share how Rapid7 customers can test for Log4Shell with InsightAppSec.
Testing for Log4Shell with InsightAppSec
With InsightAppSec, our dynamic application security testing (DAST) solution, customers can assess the risk of their applications. InsightAppSec allows you to configure various attacks of your applications to identify response behaviors that make your applications more vulnerable to attacks. These attacks are run during scans that you can customize based on your needs. In this case, we’ve introduced a new default attack template for Out of Band Injection specific to Log4Shell attacks.
What’s this mean? Customers can now run an Out of Band Attack Injection from our default template, which includes an attack type for Log4Shell. The new default Out of Band attack template in InsightAppSec will perform sophisticated web application attacks that do not rely on traditional HTTP request-response interactions. Our Log4Shell vulnerability detection will simulate an attacker on your website. InsightAppSec will validate the exploitability of the application and the associated risk.
How to run a Log4Shell attack in InsightAppSec
You can scan for this new Out of Band attack using either a new attack template we have created or by creating your own custom attack template and selecting this new attack module. We have added some highlights below, but you can find a detailed guide via our help docs.
Out of Band Injection attack template
Out of band Log4Shell attack module
Run a scan
Depending on the choice of either using the new Out of Band Injection attack template or creating your own custom attack module, you now need to choose this template on your scan config and run a scan against your selected app(s).
Now you run your scan, you can review your scan results to see if your app(s) have any findings that could be exposed as per the details in CVE-2021-44228.
Though official mitigation steps are changing as new information arises, we recommend that applications upgrade Log4j to at least version 2.3.1 for Java 6, 2.12.3 for Java 7, or 2.17.0 for Java 8 and later, but preferably the latest version available to fix any new issues as they are discovered. If upgrading Log4j is not an option, the Apache Software Foundation advises that in any release other than 2.16.0, you can remove the JndiLookup class from the log4j-core class path, but we recommend only using this method when upgrading is not possible. If you’re looking to validate any fixes have been implemented, feel free to run a validation scan with InsightAppSec to verify the fixes have been made.
If you’re looking for additional information on how Rapid7 can help support you during this time, check out our Log4j resource hub.