Cyber security is, undoubtedly, one of the most crucial issues requiring attention in today’s digital era. Understanding this ecosystem and preparing to adapt to the circumstances with the right team is a key component to thrive and develop a successful and safe ecommerce business. 

When the Log4j vulnerability (Log4Shell) was found, it became clear that this was the most severe large-scale computer vulnerability in years. But what is Log4j and why was the potential reach of Log4Shell so enormous?

Log4j is an open source logging library, written in Java and developed by the Apache Software Foundation. A library that millions of computers worldwide use, including not only individuals, but also organizations and even governments. 

Furthermore, millions of applications or services across the internet use it (Steam or iCloud, for instance). Therefore it is fair to say that the impact of the vulnerability could, in this regard, be disastrous. The fact that it requires little expertise to be exploited makes this vulnerability a very dangerous one. If left unfixed, attackers can break into systems, steal passwords or data, and even infect networks with malicious software.

The exploit allows the use of remote code execution (RCE) in vulnerable systems, which means attackers can gain total control of them (they can quickly and easily force a system to execute any code they use). An ecommerce example of the repercussions of this vulnerability is Amazon. Since its servers have Java embedded into them, it was required to take actions in order to prevent Log4j from severely affecting the company, such as the hotpatch released on December 12th.

How can Log4Shell affect your business?

Any business using a vulnerable Log4j library to parse log data in their backend systems is vulnerable. User data and company information may also be stolen and sold. This situation is particularly bad for merchants, since it might have negative implications for their brand reputation, causing buyers to lose their trust and therefore, reducing income obtained from sales. And if we dive even deeper into the repercussions of this issue, it is immediately understandable for anyone that it is crucial to fix this vulnerability as soon as possible.

All applications and software that implement Java can be affected by it, and the estimated potentially affected systems can easily reach into the billions. Internet routers, enterprise software, Microsoft or Twitter servers have Java embedded into them, therefore they are not untouched by this issue. Adobe made some fixes in order to address the vulnerability on Magento Cloud, whereas in other services like Salesforce’s it was necessary to carry out some patches and mitigations.

Even devices like phones are potentially vulnerable. Their backend systems likely communicate with the Log4j library through APIs. Therefore a malicious string sent to an iPhone could lead to compromise. Software with this type of vulnerability doesn’t need, in fact, to be directly exposed to the Internet in order to impact us negatively. Furthermore, if your third-party vendors have web applications and backend software that run vulnerable Log4j versions, your ecosystem might be exposed to third-party breaches.

How do we approach Log4Shell?

We, in Interactiv4, were aware of the direness of the situation, therefore we approached it as soon as possible in order to protect not only our company, but also our customers from any damage Log4Shell could cause.

Alongside our partner Teradisk, we investigated how we could be affected by this vulnerability, and came to the conclusion that a service we use called ElasticSearch (a search engine our customers often use in their stores to provide buyers with relevant search results), used Log4j. We needed to evaluate the situation and act accordingly in order to avoid any damage that could be caused.

In order to do this and protect our customers, we proceeded to assess the situation and act as appropriate with the following procedures regarding ElasticSearch services running in our infrastructure:

  • If version was 5.x.x: vulnerable “.cass” files should be removed.
  • If the version was 6.x.x: it is necessary to update to 6.8.21 version or higher.
  • If the version was 7.x.x: it is necessary to update to 7.16.1 version or higher.

The use of Log4j was also checked in our Jenkins servers, and in this case we weren’t required to make any changes. We, therefore, approached this critical vulnerability as quickly as possible to protect ourselves and our clients from Log4Shell. It has become clear, then, that it is absolutely crucial to approach security as one of the main issues of our time, since if overlooked, it can compromise not only our own company, but also our clients’.