Double Checking your Sitecore for log4j Vulnerability

With the recent emergency update released by the Apache Foundation regarding log4j vulnerability and with it having a Common Vulnerability Scoring System (CVSS) rating of 10, it means it’s that bad, and businesses are ensuring that their systems or web properties are not at risk for exploits like Remote Code Execution (RCE) this vulnerability presents. The purpose of this article is to give you and your clients peace of mind that your Sitecore-based projects are in a relatively good place to avoid possible attacks emerging from this alarm.

You may sit back, relax and think that your Sitecore runs on .NET so you’re safe, but think again. If your Sitecore uses Solr for searching, which is running on Java, and you’re not availing a managed search service provider like SearchStax, it’s imperative that you double check the log4j version running in your Solr instance is safe.

Sitecore Security Bulletin

Sitecore released KB1001391 article and it’s where we can see which Sitecore and Solr versions are in danger:

If your Sitecore versions based on Solr versions are affected, follow the mitigation steps detailed in this Solr page section. If you’re lucky enough to have not yet upgraded your Solr to 9.2 (like us), you may rejoice, lower your defenses and give your clients a quick screenshot or link of this article. However, how sure are you that the log4j version that your cloud-installed Solr uses is safe from all these ruckus? Have you been aware of all the information and history of your Solr instance like patches done by a Developer or DevOps engineer or how they may have spun up Docker containers or VMs to contain your Solr? For a brief context, we’re running our web properties on Sitecore XP 9.1 so I can assume that we’re not that affected by downloading a Solr 7.2.1 installer and checking the default log4j version included in it but then again, for prudence’s sake, double checking everything will give our clients’ peace of mind.

Manually Check log4j Version in Azure Solr App Service

• In you Azure PaaS, verify the name of the Solr instance that your Sitecore CM/CD is using by accessing the /wwwroot/App_Config/ConnectionStrings.config via App Service Editor. Get the value of the connectionString in the node for “solr.search“.
• Navigate to that App Service. In our case, a Docker instance in a Linux environment is running our Solr Cloud.
• Under the Development Tools section, click on the SSH and Go -> to open up a web-based terminal for bashing.

• Run bash commands to go to the root and search for instances of log4j in the server.

cd /
ls -al #optional just to check the listings for context

find . -name "log4j*.jar"

• The * wildcard will accommodate for any log4j version the instance might have but check whether the results for this library is relevant to Solr or not. In our case, the relevant log4j version is 1.2.17.

The versions affected by CVE-2021-44228 starts in log4j 2 versions 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. and since our log4j 1 has reached its end of life, we could stop here are assume that our Solr uses a relatively safe version of log4j. This 1.x version has some vulnerabilities but there are undergoing discussions about this here. But if you’re a bit more cautious like me and want to further scan the whole system, continue with the additional steps below.

Further Scan using log4j-detector

There’s a great tool built by juliusmusseau and ovdm called log4j-detector available via github. According to the contributors, it is a:

Scanner that detects vulnerable Log4J versions (CVE-2021-44228, CVE-2021-45046, etc) on your file-system within any application. It is able to even find Log4J instances that are hidden several layers deep.

While still in the SSH terminal of your App Service instance, download the scanner file of the log4j-detector and run it in the root level. To do that:

• Go over to the log4j-detector github page. Click on the latest version of the .jar file (at the time of this writing, the latest one is the log4j-detector-2021.12.22.jar)

• Copy the direct link of the .jar file by right-clicking the Download or View raw link.

• Go back to the SSH terminal and download the .jar file via wget. It’s worth checking first if you have the wget tool installed in that machine. If not, install it via apt-get install.

wget https://github.com/mergebase/log4j-detector/raw/master/log4j-detector-2021.12.22.jar

Note that curl may not be able to download the binary correctly. Downloading via wget is particularly handy especially when you’re running Solr in a Docker instance because FTPing to it directly (e.g. via FileZilla, WinSCP, etc.) from the credentials found in the App Service Deployment Center will only give you access to the file system of that Docker container and not to the Linux environment. You may choose to enable the SSH connection to the container instance too, but personally I find the wget approach easier. You may also try getting it via git clone but in my case, I’ve ran into an option prompt to upgrade my perl-base library when trying to install git and since upgrading this might affect my Solr instance negatively, I chose the safest route.

• Optional: For file organization, you may move this .jar into a folder.

mkdir log4j-detector
mv log4j-detector-2021.12.22.jar log4j-detector

• Run the scanner from to the root folder.

java -jar log4j-detector-2021.12.22.jar /

• To understand the results, you may check the github documentation here. Also, aside from Solr, check all other third-party systems your Sitecore is integrated with.

I hope this helps!