At the tail end of last year, a vulnerability was found in Log4j, an open-source logging library commonly used by apps and services across the internet. Log4shell is a critical vulnerability in the widely used logging tool Log4j, which is used by millions of computers worldwide running online services. A wide range of people, including organisations, governments and individuals are likely to have been affected by it.

The problem is that, with time passing, the sense of threat diminishes and with it the urgency to ensure that this vulnerability has been dealt with properly. The crucial factor here is that, although fixes have been issued, they will still need to be implemented and it appears that this has been far from universal.

What happens, if no action has been taken yet? "If left unfixed, attackers can break into systems, steal passwords and logins, extract data and infect networks with malicious software, the NCSC points out. "Log4j is used worldwide across software applications and online services, and the vulnerability requires very little expertise to exploit. This makes Log4shell potentially the most severe computer vulnerability in years."

USED ACROSS MANY APPLICATIONS
Log4j is an open-source Java logging library developed by the Apache Foundation. It is widely used in many applications and is present in many services as a dependency. This includes enterprise applications, including custom applications developed within an organisation, as well as numerous cloud services.

The Log4j library is frequently used in enterprise Java software and is included in Apache frameworks, including: Apache Struts2, Apache Solr, Apache Druid, Apache Flink and Apache Swift. Other large projects including Netty, MyBatis and the Spring Framework also make use of the library.

In December 2021, a number of vulnerabilities were reported in Log4j:

• CVE-2021-44228 - referred to as the 'Log4shell' vulnerability, affects Log4j versions 2.0-beta9 to 2.14.1. It allows remote code execution and information disclosure if exploited
• CVE-2021-45046 - affects versions 2.0-beta9 to 2.15.0, excluding 2.12.2 and was originally reported as a Denial of Service when organisations are running a vulnerable non-standard configuration. Later research found that the same vulnerable configuration allowed a bypass of the mitigations to Log4shell, allowing remote code execution and information disclosure
• CVE-2021-45105 - affects Log4j versions from 2.0-beta9 to 2.16.0 - A similar denial of service issue to CVE-2021-45046 when organisations are running a vulnerable non-standard configuration.

"An application is impacted by these vulnerabilities, if it consumes untrusted user input and passes this to a vulnerable version of the Log4j logging library," adds the NCSC. "Version 1 of the Log4j library is no longer supported and is affected by multiple security vulnerabilities. Developers should migrate to the latest version of Log4j."

WHO IS AFFECTED BY THIS?
Almost all software will have some form of ability to log (for development, operational and security purposes), and Log4j is a very common component used for this. "For individuals, Log4j is almost certainly part of the devices and services you use online every day. The best thing you can do to protect yourself is make sure your devices and apps are as up to date as possible and continue to update them regularly, particularly over the next few weeks."

For organisations, it may not be immediately clear that your web servers, web applications, network devices and other software and hardware use Log4j, points out the NCSC. This makes it all the more critical for every organisation to ensure they are not exposed to any potential threats from the logging tool and make all the necessary mitigations to ensure they do not become targeted.

MASSIVE SHAKE-UP
"The LogJam (or Log4Shell) debacle shook the world to its knees," says Niels Hofmans, head of security at Intigriti. "Open-source software is incorporated everywhere into the software we use on a daily basis. However, we often don't know what software 'materials', such as Log4j, are built into the code libraries and tools we operate-or even develop."

The good news is that a new standard, called Software Bill of Materials (SBOMs), will hopefully bring some resolution to this problem, where a 'bill of materials' can be (securely) delivered along with packaged software releases, he adds. "This important bill will improve our supply chain security issues, at least by tenfold, since we will be able to track our software in a uniformed way. At the same time, software developers will be able to understand contents more clearly, identify all (transitive) dependencies, and match everything to any security vulnerabilities later on."

At the least, companies should consume threat intelligence feeds (TI feeds) that describe the latest attacks, trends and patches so they stay on top of threats and prioritize accordingly. "And when cyberattacks do happen, a modern Web Application Firewall can stop web attacks from reaching your server; even better, if it allows you to tweak its settings to catch the latest attacks."

Configuration hardening is the practice of disabling and tweaking aspects in a system to improve its security, which could have prevented this logging library from being exploited, advises Hofmans. "And, even if it's too late, endpoint detection & response should stop or alert any exploitation attempts and trigger you to go into red alert based on any abnormal system behaviour. Finally, to ensure an infected machine can only go so far, network segregation [akin to the Zero Trust Model] will limit its blast radius to only authorised peers and not the whole network."

As the head of security for Intigriti and part-time bug bounty hunter, Hofmans warns that this type of creative attack certainly won't be the last. "However, there are many accessible controls software users can proactively implement now, rather than waiting for the next attack to happen."

SERIOUS FLAWS MOUNT UP
According to John Graham-Cumming, CTO at Cloudflare, Log4Shell is the third serious flaw that has affected a wide range of Internet services: Heartbleed in 2012, ShellShock in 2014 and now Log4Shell in 2021. "The Log4Shell vulnerability allows an attacker to execute code on a remote server, a so-called Remote Code Execution (RCE). The vulnerability was particularly serious, because of the widespread use of Java and Log4j. Importantly, even non-Internet facing software that uses Java could have been exploitable as data gets passed from system to system.

"When vulnerabilities like this are disclosed, it's important for companies to do two things: make sure their firewall is configured to block the attacks - and talk to their firewall vendor to see if they've rolled out a specific blocking rule - and patch the vulnerability as soon as possible."

Other best practices he recommends include filtering and logging DNS queries to block queries made to known malicious destinations, securing network traffic leaving your infrastructure with an updated, and inspecting and filtering HTTP traffic, which can block attacker attempts to reach their destinations.

DANGER ON THE HORIZON
While Tim Mackey, principal security strategist at the Synopsys CyRC (Cybersecurity Research Center), recognises how Log4Shell would have impacted businesses on many levels, he emphasises most of all how any attack targeting Horizon could represent a disruptive threat to operations for those who are running VMware Horizon as part of a remote work programme. "As background, many VMware products include Apache log4j2 as their logging mechanism," he states, "and, as the evolution of the log4j2 patches occurred, VMware was proactive in their patch and mitigation efforts." Patch and mitigation information has been available for Horizon since December.

"From a risk management perspective, focusing attention on VMware Horizon, or any other individual product that uses log4j2, misses the real business risk associated with Log4Shell. If your patch management process missed Log4Shell or you had to manually scan each system to identify log4j2 usage, then that patch management process isn't really prepared for a world where open source technologies power business. That's unfortunate, as multiple reports hold that upwards of 70% of commercial software is based on open source libraries."

Of course, if your team patched Horizon, or any other application using log4j2, that doesn't mean the risk is mitigated, he warns. "In the early days of a major vulnerability like Log4Shell, attackers know that they're in a race against the patch management team and will quickly be locked out of vulnerable systems as they are patched. To solve for this problem, they compromise the vulnerable systems and install software that they control. That software can take many forms, but its objective is to provide an entry point for the attackers to mount the second phase of their attack - potentially weeks or even months later."

OUT OF CONTROL
It is that second phase where the real damage is done and why patch management is only part of the puzzle, he adds. "Any system where the owner of the system doesn't have a complete inventory of all running and runnable software or where such an inventory does exist, but isn't validated against an approved bill of materials for the software on the system, can't claim to be in complete control of that system. Put another way, if an attacker knows more about what software is on a computer system than the owner does, then the attacker is in control."

As far as VMware Horizon is concerned, one way to mitigate this risk is for all Horizon components to be provisioned from golden VM images where all patches are pre-applied. "Of course, that still leaves the problem of patch management," states Mackey, "and, where open source is involved, that's a problem best solved using technology known as Software Composition Analysis, and the best tools work with both binary and source files."

THE THREAT HAS NOT GONE AWAY
In the immediate wake of the Log4Shell debacle, the Scottish Business Resilience Centre (SBRC) was quick to call on all organisations in Scotland to ensure their systems and devices were updated to mitigate the impact. It was just one more serious issue that organisations needed to be aware of.

Speaking of the vulnerability now, Jude McCorry, CEO of SBRC, comments: "Exploitation of Log4Shell has peaked, but there will still be cases where the vulnerability may not be uncovered, due to more obscure entry points or them already being embedded in proprietary software, both of which are not as trivial to identify.

"When a vulnerability of this scale is identified, organisations can't just assume that it is only work devices that are on the line - personal devices are also at risk and so must be part of the updating process. Acting quickly and looking into other services that are used - including third-party software - helps to provide peace of mind.

"Log4Shell had enormous public exposure and in parallel we saw a huge volume of attempts to discover the presence of the vulnerability across infrastructure, both ethical and malicious. Given the current threat landscape, it is not enough to only remediate critical vulnerabilities when they are found," adds McCorry. "There must be a concerted effort to search for indicators of compromise to ensure that organisations have not already been breached before having a chance to patch any such vulnerability. Individuals and organisations must turn to trusted sources to keep up to date on credible threats to operations like this. The SBRC app provides push notifications within minutes of the insight being received, covering cyber threats with accurate guidance."