Log4j Vulnerability - TheCyberDelta

A vulnerability in the open source Log4J logging service used by developers to monitor their Java applications first came to light, leaving enterprises scrambling to patch affected systems.

Since then, the vulnerability dubbed CVE-2021-44228 has been highly exploited in the wild with massive reconnaissance activity, according to Steven Ng, CIO and executive vice-president of Ensign Infosecurity, a Singapore-based managed security services provider.

Ng said attackers could use the vulnerability to load arbitrary Java code and take control of a server, making it a highly attractive vulnerability for cyber perpetrators.

“In the wake of the vulnerability disclosure, financially motivated actors involved in cryptocurrency mining were among the first to exploit targets,” Ng said. “It is anticipated that there will be more monetisation-centred exploitation activities moving forward, including data theft, ransomware deployment and multifaceted extortion.”

In Singapore, the Cyber Security Agency had sent out alerts to critical information infrastructure sectors and businesses to patch their systems and reached out to ASEAN member states’ Computer Emergency Response Teams to exchange information and gather updates.

In a threat advisory published recently, Ensign shed light on the Log4j vulnerability and answered the top three questions about its impact on enterprises

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

It is critical that organizations 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, the 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 cyberattacks that leveraged the Log4j vulnerability had affected organizations 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, which 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 applications 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.

Organizations should also evaluate the use of the open-source tools and test them before running them in 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.

Organizations 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.