Everything You Need To Know About Apache Log4j Vulnerability

It’s a very rare occasion that a client rings your personal phone number on a Sunday. Last weekend was one of those days. I answered in trepidation hoping that any issue worth disrupting anyone’s weekend was a technical fault and not a human error – and that was the first I heard about the log4j security concerns. This security breach – a result of a hackers exploiting a chink in the armour of Apache’s logging utility – could have widespread impact so it was no surprise that our own clients were concerned.

What is log4j?

The Log4j framework allows software developers to record activity in their applications. It’s used by a large percentage of Java programs to track and store notes on behaviours, such as logins and attempted logins, system information and actions across billions of applications including cloud-based and bespoke, in-house platforms. It’s an open source framework which means it’s publicly available for use and modification (subject to review and approval), and it also has the flexibility to send and receive data from a remote server.

Log4Shell? Explaining the log4j vulnerability

On Friday, a vulnerability (nicknamed Log4Shell, to save you remembering code) was identified in the open source framework as attempts were made to exploit it. Attackers were able to access affected machines, giving them the ability to delete, encrypt or download files to be held at ransom. Any asset functioning with the log4j framework was vulnerable without discrimination – even the Mars Rover helicopter mission!

The impact of log4j vulnerability 

It affects a huge number of programmes that utilise Java, from bespoke intergalactic research missions to everyday WordPress plug-ins. Many of our clients use Adobe programmes that utilise Java so we jumped straight into action to see who and what may have been impacted and how we could mitigate risk.

Immediately after a problem had been identified, Apache released an update to the software (version 2.15.0-rc2) which completely removes this vulnerability. We’ve been advising affected clients of Apache’s recommendations, and Adobe has supported by implementing patches for most of their major products. While we can’t physically remedy the situation, we can support our clients IT teams in doing so. Our current understanding is that Marketo, Adobe Campaign Standard, Adobe Analytics and Adobe Audience Manager pose no risk. Adobe Campaign Classic hosted by Adobe is also not vulnerable as it doesn’t use log4j but use on-premise (hosted by the user) may be at risk dependent on their infrastructure.

Detailed technical recommendations can be found here.

Why is it a big deal?

With updates and patches available the impact could be minimal but, in practice, it’s been estimated that it will take two years for the risk to be phased out of operational technology completely. This isn’t because of a lack of solution, but moreso the speed in which companies are able to make it happen. Companies with a holistic technology infrastructure could respond quickly, deploying the new version across all applications. However some companies will have hundreds of independently affected systems and devices requiring manual intervention for every instance. Over the last couple of days, we’ve seen some companies bypass the usual bureaucratic sign-off processes to kickstart their recovery as soon as possible.

How to be cyber resilient

Protecting your business and its data from the threat and exploitation of sophisticated malware is a necessity. Preventing every attack is impossible. Those with the intention to do so will continue to find new ways to break code and take advantage of unauthorised access. However, there are best practice measures every company can take:

–        Design well. A well designed network takes security seriously, for example not excessively using development features in a product environment, including strict firewalls, and implementing methods to only connect to approved destinations.

–        Update regularly. As mentioned earlier, updating to the latest version of any software reduces risk. Due to company guidelines (some companies wait a couple of months to update so any bugs have been fixed) and infrastructure, this can’t always be immediate but there should always be a process in place.

–        Keep an audit trail. This is more an investigative measure than preventative, but should your technology be exposed to risk, it could help you identify how and help you find a fix. For example, if you logged all connections to and from your server (ironically this is what log4j did!) you could spot how and when a file had been exploited.

–        Lean on your tech support. Whether you work with an agency, tech consultant or Customer Success Manager, they should be able to highlight potential risks and support recovery.

If you’re concerned the log4j breach affects you, please get in touch to discuss how we can help.