Is AEM Susceptible to log4shell?

Many people in the technology sector have heard a lot recently about a large-scale security breach called log4shell. As far as IT security goes, this is considered one of the biggest security risks we’ve seen in the last 10 years. In fact, security breaches are ranked on a scale of 0.0-10.0, with 10.0 being considered potentially catastrophically dangerous for businesses and governments alike - log4shell has been given a CVSS score of 10.0. 

While there is a lot of bad news accompanying this breach, there is still good (great, actually) news for users of Adobe Experience Manager (AEM). We can state, unequivocally, that AEM, as it is out-of-the-box, has never been vulnerable to log4shell because it doesn’t use the vulnerable Java library. Of course, customizations to Experience Manager software may have introduced this vulnerability - but AEM, out of the box, is safe. 

When we look at what log4shell is and evaluate why AEM isn’t susceptible, we need to understand a little history. Log4shell is a vulnerability in the log4j code library, a tremendously pervasive, unsponsored, open-source Java library used by many (perhaps even the majority) of business and government enterprises. 

Surprisingly, this vulnerability wasn’t brought to light by talented hackers with highly nefarious goals in mind. No, it was uncovered by ever-industrious Minecraft players out to seek vengeance on their enemies. Seriously…we’re not even kidding. Players were looking for ways to access other Minecraft accounts so they could destroy another player’s creations. While their goals seem like child’s play in the grand scheme of things, these players highlighted a significantly larger problem. 

The vulnerability in log4j allows an attacker to run arbitrary code on almost any java service. Meaning they can inject their own code and make any server running log4j do whatever they want. Alarmingly, this means that a hacker could easily create user accounts, add new system administrators, exfiltrate data, or even delete an entire database. 

Yeah, we feel slightly nauseated reading that list too. 

This level of access has the potential to be catastrophic - and what makes it even more challenging is that because of the nature of this vulnerability, it may be nearly impossible to determine if a hacker had access to your system, how long they had access, or what they may have accessed. For companies that were not logging certain log4j calls, there is no way to definitively verify if they were exploited or which systems were subject to an attack. 

This leads us to our next question: if so many businesses were vulnerable, why was AEM spared? AEM does not use log4J, they use an alternative code library, log4j-over-slf4j (slf4j), which is a simplified version of log4J. When slf4j wrote their implementation of log4j, they removed some of its complexities and dropped the section of vulnerable code. Thus, systems that are using slf4j as an alternative to log4j are not susceptible to this specific type of attack.

For AEM users wondering if their customizations need to be evaluated for a log4j vulnerability, reach out to your AEM implementation partner to look in the System Console to see if there are any bundles providing log4j instead of log4j-over-slf4j.

As of right now, many businesses who use log4j are taking appropriate steps to address this vulnerability, including patching the susceptible code and attempting to find ways to address any system breaches that may have occurred within their systems. 

If you need more information about this security vulnerability, please don’t hesitate to contact our team here at Hoodoo. We have a team of experts on hand who specialize in system administration and security. 

Are you looking for an implementation partner who knows the ins and outs of system administration and security? 

We do. We’re Hoodoo.