Mitigate Apache Log4Shell vulnerability (CVE-2021-44228) using custom scripts

This article is a continuation of our previous post on Log4Shell vulnerability. In this article, we discuss the steps to mitigate log4shell vulnerability in affected web server applications with Vulnerability Manager Plus server using custom script. For steps to detect the affected web server installations in your network systems, refer to our previous post. The custom script discussed in this post performs the mitigation steps suggested by apache which can be referred here. This mitigation is applicable for vulnerable web server applications/software whose vendors haven't provided patches or mitigation to resolve Log4jshell vulnerability in their applications/software. Note: It is recommended to verify with the application/software vendor and qualify the impact of the this mitigation before applying it.

The custom script performs the following mitigation operations:

1. Stops the web server application service that is using the vulnerable Log4j versions.
2. Locates the log4j-core-x.jar files. 'x' indicates the vulnerable Log4j versions.
3. Removes the "jndilookup.class" file from the jar files that match vulnerable Log4j versions.
4. Starts the web server application service back.

The custom script for windows can be downloaded from this link.

The custom script for Linux can be downloaded from this link.

Note: Since we do not have any option to deploy custom scripts directly with Vulnerability Manager Plus, we are going to deploy a dummy patch with a deployment policy where we can include the custom script while configuring pre-deployment activities.This custom script will run on affected machines before deploying the dummy patch. This dummy patch don't introduce any changes in your network systems.

Please follow the below steps in the Vulnerability Manager Plus web console.

Steps to add the custom script:

1. Navigate to Deployment -> script repository
2. Click on add script
3. Click on Browse and locate the downloaded custom script.
4. Select the custom script and click Open to Upload it
5. Specify the exit code as 0
6. Select platform as Windows or Linux accordingly.
7. Give an appropriate description and click add to add the custom script to script repository.

Steps to create a deployment policy and include the custom script:

1. Navigate to Deployment-> Deployment policies.
2. Click on create policy to initiate the deployment policy workflow. Give an appropriate name to the policy.
3. Based on your needs, fill in the deployment schedule settings depending on when you wish to deploy the custom script. However, it is recommended to select all weeks and all days for deployment, and keep the deployment window as broad as possible.
4. Click save and continue to move to the Pre-deployment Activities section.
5. In the Pre-deployment Activities section, drag and drop the custom script tile in the box under Pre-deployment Activities title and click on custom script. This will open up a page where you can select and configure custom script.
6. In the Script Name field, type in the download custom script, and select the script.

7. • If you're deploying the script for Windows, specify the below arguments in the Script Argument field:

     Note: Windows script needs two arguments. Argument 1 locates the vulnerable Log4j jar files from affected web sever. Argument 2 is used to stop and start the web server application service.

     • Argument 1 : Specify the home directory path or the exe path of the vulnerable web server application within double quotes. For example, the exe path can be specified in this format - "C:\sample test server\log4j vulnerable server\apache\bin\httpd.exe", or the home directory path can be specified in this format - "C:\Test server\Vulnerable test server". Note: To get the home directory path or the exe path of the vulnerable web server application from the Vulnerability Manager Plus console, refer to the previous post on Log4Shell vulnerability
     • Argument 2 : Specify the service name of the vulnerable web server application within double quotes. The argument 1 and argument 2 must be specified in a single line and separated by a space. For example, the two arguments must be specified in this format - "C:\Test server\Vulnerable test server" "SERVICE_NAME". The service name of the vulnerable web server application can be obtained from services.msc. Open services.msc in the affected Windows machine and locate the service name of the vulnerable web server application. Double click on the service name and in the resulting popup window, you can find the service name.

     Note: For Windows, only one path and one service name can be specified at a time. Separate configuration deployments have to be created to mitigate different web server applications using custom script.

   • If you're deploying the script for Linux, specify the below arguments in the Script Argument field:

     Note: Linux script needs 2 arguments. Argument 1 is used to stop and start the vulnerable web server application service. Argument 2 locates the vulnerable Log4j jar files from affected web sever.

     • Argument 1 : Specify the service name of the vulnerable web server application(s) within double quotes. If you're specifying services of multiple web server applications, separate them with a comma. For example, service names of multiple web servers can be specified in this format - "tomcat9,apache2". Note : To get the vulnerable web server installations in your network as well as their home directory path or the exe path from the Vulnerability Manager Plus console, refer to the previous post on Log4Shell vulnerability.
     • Argument 2 : Specify the home directory path of the vulnerable web server application within double quotes. For example, the home directory path can be specified in this format - "/var/lib/tomcat9". Directory paths for multiple web servers can be specified in this format - "/var/lib/tomcat9,/etc/apache2". The argument 1 and argument 2 must be specified in a single line and separated by a space in the following format - "tomcat9,apache2" "/var/lib/tomcat9,/etc/apache2"
8. Leave the Dependency files field empty
9. Specify the exit code as 0.
10. Enable the checkbox "Proceed only if the script is executed successfully" and click save and continue
11. Configure notification settings according to your need and click save and continue
12. No post deployment action is required, so you can skip that step and click save and continue.
13. This will open up a summary of the deployment policy you've now created. Verify the details once and click save and continue. Now a deployment policy with a custom script is created. The next step is to map this policy to a manual patch deployment task with a dummy patch, so that the custom script will get deployed along with the dummy patch to your target machines. As we've mentioned before, the dummy patch will not introduce any changes in your network systems.

Steps to create the manual patch deployment task:

1. Go to patches -> Supported patches.
2. Search for the patch id "109162" (For windows) or "890003" (For Linux). The name of the dummy patch should read "log-4j mitigation helper" (For Windows) or "Pre-Deployment Script" (For Linux).
3. Select the dummy patch and click on Install Patch to initiate the Patch Deployment workflow.
4. Give an appropriate title.
5. Under deployment settings, select the deployment policy with custom script which you've just created.
6. Select the Windows/Linux targets depending on the OS platform for which you're deploying the script. Only the systems with web server installations having the same service name and the path given in the arguments in the custom script workflow while creating the deployment policy should be selected. Note: To find the affected systems from the Vulnerability Manager Plus web console refer to the steps mentioned in our previous post on Log4Shell vulnerability.
7. Configure retry settings based on your needs and click deploy or deploy immediately

Note: In order to deploy the custom script to another target, you can edit the already created deployment policy and change the custom script arguments based on the web server installations in the target (provided there aren't any patch deployments in "in-progress" or "yet to apply" state which uses this deployment policy) or you can create separate deployment policies with different custom script arguments and map to patch deployments with corresponding targets. It is recommended to create deployment policies with names of system that will be mapped to avoid confusion.