What’s Next After Log4Shell?

How To Deal With the Next Open-Source Vulnerability Using Custom Scripts

A critical vulnerability in Apache’s Log4j Java-based logging utility (CVE-2021-44228) was previously referred to as the “most critical vulnerability of the last decade.”

In the wake of Log4Shell exploits, many security professionals are concerned about the next potential open-source vulnerability. The ubiquitous nature of open-source libraries makes this threat viable and dangerous. Since so many applications could be using an affected library, detection can be difficult if not impossible.

You could have a Log4j issue hiding somewhere in an application and not be aware of the threat as it might be buried in a Java class. Therefore, a simple search for Log4j will not suffice. A deep scan of a host’s filesystem is required to identify Java applications and libraries with vulnerable Log4j code.

A key thing to remember with open-source vulnerabilities like Log4Shell is that integrating this open-source into another application can be done in many ways. Detection becomes more difficult and time consuming, requiring a full search for the vulnerable library across all assets. In some cases, also inside archives such as .war and .jars. Most open-source vulnerabilities share the same characteristics as Log4Shell, and as a result, require specialized deep scanning on the right device at the right time. Any solution used must be able to share detection findings with a vulnerability management product and be able to efficiently remediate any vulnerabilities in a timely and efficient manner.  You need precise detection utilities to manage such situations. That’s the only way to ensure fast and effective response when the next open-source vulnerability becomes a threat.

A few questions to also consider include:

• Does your security team have enough time and resources to invest in writing effective utilities?
• How do you analyze or derive any context from the script output?
• Do you need to rely on your IT team to execute scripts?
• How would you execute such scripts on a large scale across thousands of assets?

Qualys CAR is your most effective scripting solution to augment your current vulnerabilities scans

QIDs as part of your regular VM scans are an efficient and accurate method of detecting open-source vulnerabilities. However, as those scans are designed to be efficient and accurate a full, in depth scan of your entire file system in order to find all instances of an open source vulnerability is not recommended to be part of those VM scans.

Qualys Custom Assessment and Remediation (CAR) has been designed to augment those types of zero-day open source exploits, including Log4j-style. It allows you to create custom scripts and empowers security teams to execute custom logic to detect vulnerable libraries deeply embedded in applications and all of this is possible with the same Qualys agent that is already deployed in your environment for Vulnerability Management, Detection and Response (VMDR) or Compliance.

Assess Your Environment Using Your Own Scripts and Out-of-the-Box Detection Utilities Provided by Qualys CAR

Qualys CAR offers numerous scripts as part of a Script Library, so all you need to do is import and execute. This can greatly reduce your Mean Time to Respond (MTTR) and allow you to take action before a vulnerability becomes an incident.

As a first responder to a zero-day attack, a security analyst must have the right solutions to reduce IT tickets and dependencies on IT teams. This can eliminate the need for data analysis spreadsheets in critical situations and automate most processes to derive conclusions.

CAR can allow you to execute a script on X number of hosts and determine how many are vulnerable with a single query. Unlike other scripting solutions where the script is executed, outputs are pushed to a csv, require manual efforts to understand any context or derive conclusions, Custom QIDs (vulnerability IDs) can be evaluated in Qualys VMDR to assess risk scores.

Augment Your Detection QIDs With Qualys CAR

QIDs as part of your regular VM scans are an efficient and accurate method for detection. However, the downside is that they may miss some applications that do not use the vulnerable libraries in standard ways. In-depth scanning is required to detect vulnerable instances, regardless of the deployment method. This is a more accurate way to detect such open-source vulnerabilities but may require intensive computation and more time to scan.

You can easily execute such detection utilities via Qualys CAR using the same agent.

Evaluate Your Compliance Posture Using Script-Based, User-Defined Controls (UDCs)

User defined controls can also be created in Qualys Policy Compliance (PC) to determine your compliance posture – all based on script output.

By integrating with Qualys VMDR (in the near future), you’ll now be able to create custom QIDs and flag them based on conditions within the CAR app. This will allow you to create your own QIDs for various use cases, such as zero-day detection utilities, based on your own logic. Also, check for misconfigurations or versions of custom apps, etc. Moreover, you’ll see these QIDs in the Script Library as well.

What’s next after Log4Shell is anyone’s guess, but you no longer need to lie awake at night wondering if you’re prepared to deal with the next open-source vulnerability. With Qualys CAR, you can avoid the serious consequences of this type of zero-day exploit with ease.

Learn More: