Salesforce Products Hit by Log4j2 Security Flaw

By Prashanth Samudrala

A security flaw was identified on December 9th, 2021 that has the potential to affect a large portion of the Salesforce development world.

Apache’s Java-based logging utility, Log4j, was found to have a security vulnerability officially known as CVE 2021-44228, or informally as Log4Shell or LogJam.

Apache Log4j is commonly used—most notably in Salesforce’s data loader. This was found as part of AutoRABIT’s research into the Log4Shell vulnerability and its impact on the Salesforce application development supply chain in the repository on Github. And as this data loader is potentially present in the software of every developer within a company’s team, it creates multiple potential points of entry for hackers.

Log4Shell is a Remote Code Execution (RCE) class vulnerability that allows bad actors to input arbitrary code into an application by exploiting the Java Naming and Directory Interface (JNDI).

Even inexperienced hackers have the ability to successfully execute this type of intrusion. From there, hackers are able to introduce their own lines of code by adding a single string to the log, enabling full control over the server.

Why Should I Be Concerned About Log4Shell?

The Common Vulnerability Scoring System (CVSS) rates the “characteristics and severity of software vulnerabilities” on a scale of 1 to 10, with 10 being the most severe.

Log4Shell has been rated as critical—10 out of 10.

For comparison, the SolarWinds hack cost the company around $18 million in the first few months of 2021 alone and resulted in 30,000 hacks. It was rated a 9 on the CVSS scale.

Log4Shell has already been linked to over 900,000 hacks.

The SolarWinds event was a supply chain attack similar to Log4Shell but with a major difference. SolarWinds was targeted by creating a backdoor to their system during the build process. This singular entry point was then exploited.

Log4Jam could potentially involve millions of entry points.

The Salesforce Data Loader Connection

Salesforce’s data loader can be used by any user with the correct permissions and is otherwise available in the open-source git repository. It is widely used by Salesforce professionals to load data into the CRM. This tool utilizes Log4j which means every instance of Salesforce’s data loader is vulnerable to Log4Shell.

To put it another way, a team of 200 developers that all utilize Salesforce’s data loader creates 200 individual potential entry points for hackers.

The data loader has recently been updated to protect against this vulnerability, but anybody running a version more than a couple of days old is susceptible to a hack.

Those who utilize a data loader that either doesn’t use Log4j or is protected by a multi-tiered security approach is safe. Otherwise, steps will need to be taken to protect yourself.

What Can I Do If Log4Shell Impacts My System?

The first step is to quantify your exposure. Audit your system to learn how many of your developers are utilizing Salesforce’s data loader.

Certain code scanning tools have the ability to take an overview of your Salesforce environment to see if Log4j exists elsewhere in your system.

Deploy rules to your IDS/IPS systems to stop and prevent the exploit. Scan developer desktops and platforms on a regular basis as part of your normal development process to ensure Log4J or other vulnerabilities are not present and putting your development supply chain at risk.

Those exposed to the vulnerability need to update their Salesforce data loader to the most recent version. Go through your entire development team and manually update the software. Even one instance that isn’t updated can result in widespread issues.

Users can also leverage a secure and scalable data loader from other sources to enable their whole team and eliminate the need for desktop software altogether.

It’s important to note that Log4Shell is still very fresh, and more vulnerabilities are emerging. Apache has released a patch to shore up these vulnerabilities but keep yourself informed as the situation progresses.

Stay up to date with this Salesforce Knowledge Base article, and stay safe!

The Author

Prashanth Samudrala

Prashanth is a former Salesforce Developer and architect now leading, Product management for AutoRABIT's DevSecOps Products.


    Clay Morse
    December 16, 2021 6:41 pm - As of 12/16, the in-app dataloader corresponds with the winter release. Forcedotcom Github is has the patched dataloader release.
    December 17, 2021 6:28 pm
    What software on the following page is tied to the data loader? Why has salesforce not released a fix for the data loader?
    Ric Palmer
    December 20, 2021 9:54 pm
    Thank you for posting this article. We were not aware that dataloader was affected and could potentially be a risk from any machine running Apex Dataloader.
    Arun Kumar
    December 21, 2021 3:03 pm
    But data loader is not a web application. Can an attacker still be able to exploit the vulnerability? If yes, how?
    Simina Roman
    December 31, 2021 12:40 pm
    Does anyone know whether this also affects Salesforce' command line Data Loader or does this vulnerability only apply to the UI portion of the Data Loader?
    B R
    January 03, 2022 7:25 am
    Thank you for the article. I would love to read a bit on how the actual flow of using the vulnerability for attacks would look like. As per my understanding, the log4j library would need to "log" a certain string containing the affected lookup function to actually load code from a web server. So to use this attack with data loader, a developer would need to import a set of data where field values actually contain malicious strings containing the lookup format. In a real world example, a Lead Upload containing some Leads from a Website registration form could be a potential risk. But besides that, I see no risk without the developer actually performing an upload with "bad data". Do you agree?
    January 19, 2022 4:28 am
    Is Salesforce ANT migration tool impacted?

Leave a Reply