Top three questions about the Log4j vulnerability

1. Why the urgency to mitigate and remediate Log4j vulnerability?

It is critical that organisations take immediate actions to identify systems with the Apache Log4j vulnerability, implement mitigation measures, continually monitor, and remediate them. The initial Apache Log4j vulnerability on 9 Dec 2021, which was assigned a maximum CVSS (common vulnerability scoring system) score of 10, led to massive reconnaissance and exploitation activity by threat actors leveraging the bug.

The wide use of the Apache Log4j framework in many software applications and services, coupled with the ease of exploit, has led to many successful exploits such as data exfiltration, malware injects, botnets and ransomware deployments.

As the vulnerability is easy to exploit, there has been massive reconnaissance activity and attempted exploits. Between 9 and 21 Dec 2021, Symantec’s intrusion detection system blocked more than 93 million Log4j-related exploitation attempts on more than 270,000 unique machines.

So far, successful, publicly known cyber attacks that leveraged the Log4j vulnerability had affected organisations such as Belgium’s Ministry of Defence, which discovered an attack on its computer network with internet access on 16 December 2021. It did not confirm if it was a ransomware attack but explained that “quarantine measures” were quickly put in place to “contain the infected elements”.

Microsoft also reported that state-sponsored hackers from China, Turkey, Iran, and North Korea were testing, exploiting and using the Log4j vulnerability to deploy a variety of malware, including ransomware.

Another high-profile cyber attack was launched on one of the largest Vietnamese crypto trading platforms, Onus, that was running a vulnerable version of Log4j.

The threat actors successfully planted backdoors to exfiltrate sensitive databases before the system was patched on 13 December 2021. They demanded a $5m ransom which Onus refused to pay. The threat actors eventually put data of nearly 2 million Onus customers up for sale on forums.

2. Why is there so much patching to do?

As the bug is being exploited in the wild, and Apache addressing four Log4j-related CVEs in less than a month, IT professionals are experiencing déjà vu patching Log4j.

On top of that, as the Apache Log4j framework is used in many software applications and services, affected third-party application and service providers are releasing short-term mitigation measures and patches that need to be tested before any production deployment.

3. Do we need to scan our systems using various Log4j scanners?

Due to the severity of the Log4j vulnerability, a system with any installed instance of Log4j, regardless of whether it is part of a running application or service, should be treated as vulnerable.

Out-of-date Log4j versions need to be updated immediately. To identify vulnerable systems, internal and external vulnerability scanning tools, which contain signatures or plugins for identifying Log4j instances, can be used.

Open-source vulnerability toolsets can also be leveraged, such as https://github.com/fullhunt/log4j-scan and https://github.com/jfrog/log4j-tools.

Also, check if mitigation against CVE-2021-44228 was implemented correctly, and if the configuration does not allow for exploitation of CVE-2021-45046, which came about because of an incomplete fix for CVE-2021-44228 in certain non-default configurations.

Organisations should also evaluate the use of the open source tools and test them before running them on any production environment.

If there is no change to the software installed on the server, it is not necessary to run Log4j scanners to detect the presence of Log4j. However, vulnerability assessment scans should be conducted periodically as part of any vulnerability management process.

Organisations can also leverage endpoint detection and response (EDR) tools to scan for JAR files, class files (JndiLookup.class), or process execution events associated with Log4j.

To detect potential exploitation attempts, Ensign has stepped up monitoring operations since the disclosure of the Log4j vulnerability. Under Ensign’s heightened alert posture, it has also reached out to clients to request for their public-facing web portals to check against its intelligence sources to detect any exploitation attempts.