By: Vijay Raghunaathan, Head of Sales and Solutions for LTIMindtree’s Digital Security, North America

Our global community has tackled multi-faceted threats to humanity over many centuries and has thrived through countless incidents. Getting back to near normalcy in the face of Covid-19 was no small feat for governments, enterprises, businesses, and the common man. In these situations where the most important realization always points back to an approach that emphasizes staying alert, maintaining hygiene, and being prepared for adverse situations. The same applies to digital threats and LTIMindtree has been helping businesses across the world overcome the challenges of digital security.

Just at the last mile of overcoming the global pandemic, on the way into 2022, we are faced with a similar challenge in responding to a serious threat to all digital enterprises with the Log4j vulnerability. It is one of the most massive vulnerabilities uncovered to date. As per the NIST, it has a Base Score of 10, underscoring the importance of action. It has hit everyone hard as they try to get back to work and gaze at the unknown complexities of our cyber world.

This vulnerability in the system poses a huge threat as it is allowing multiple nation-state activity groups to exploit it and operationalize ransomware affecting systems worldwide as well.

Nation-state activity

Various nation-state activity is being observed by the Microsoft Threat Intelligence Center (MSTIC) for the use of the Log4j CVE-2021-44228 vulnerability, mainly originating from North Korea, China, Iran, and Turkey. This activity ranges from various experimentations during the development phase and payload deployment with the vulnerability integrated to achieve the threat actor’s objective by exploiting the targets.

The MSTIC also stated that they have observed an Iranian actor PHOSPHORUS which has been actively deploying ransomware while making modifications to the Log4j exploit. It has been assessed that these modifications have been operationalized by PHOSPHORUS.

Furthermore, a Chinese threat actor group, i.e., HAFNIUM, has been seen broadening its scope of attack by exploiting this vulnerability to attack virtual infrastructure. HAFNIUM-affiliated servers were seen using a DNS service generally associated with the testing activity to fingerprint systems in these broad virtual infrastructure attacks.

What is Log4j?

Log4j is typically the most frequently used logging library for Java. This critical vulnerability is easy to exploit by allowing remote code execution.

Why is this different from any other vulnerability?

The problem is not only that Log4j (versions 2.0 to 2.14.1) might be used directly in the software, but also that there might be other tools using Log4j. This means that a plethora of other systems such as monitoring, alerting, logging, and even dashboard solutions could make use of Log4j. This exponentially widens the scope of the vulnerability with the potential for even more harm.

Malicious actors are using these exploits for coin mining, and credential theft and this can even lead to ransomware threats. On the Operations Technology (OT) network, any components enabled with Lightweight Directory Access Protocol (LDAP) for password management and sensitive access data are susceptible to attack. If this is exploited the energy and utility sectors might have a very widespread impact.

According to researchers, more than 35,000 Java packages are affected per Maven Central, the largest Java package repository. Only about 14% of packages that were initially found vulnerable are fixed. The direct and indirect dependency in the Java packages suggests that it will be a few more years until the entire ecosystem is patched and secured.

What is the challenge?

100% discovery of vulnerable assets is extremely challenging; therefore, it is very likely that applications with the Log4j vulnerability will be encountered many months later in different systems.

In this connected world, the accessible exploits and tools are constantly evolving and new methods to attack the enterprise are being constantly developed by adversaries. Incident response and threat hunting are left with many unknowns and need improved methods to track and tackle the growing attack vectors.

Moreover, Log4j is used inside other frameworks, like Elasticsearch, Kafka, and Flink, on which many websites and services are based. This prevalence and fragmented use of Log4j means that it is often quite challenging to check the environment for a version with Log4j vulnerability because:

• This library is widely used across software and applications. It is utilized externally by various products. However, certain standalone Java applications utilize it by embedding it in their executables.
• The standalone applications may also have Java Runtime Environment (JRE) embedded in them.
• Applications may have interdependency to Log4j, which means another library that the application is dependent on can use Log4j.

What are the rapid mitigation measures?

Stage 0 – Safeguard the assets through patching
Address the known environment and identified systems running Log4j and Java applications. The most immediate action one should take is to patch the systems based on your tech stack or product partner advisories. It is crucial that the impact is reduced by addressing this on zero-day.

To quickly identify any Log4j packages in your systems, you may use the commands shown below.

On Linux-based machines:
dpkg -l | grep liblog4j
dpkg -l | grep log4
find / -name log4j-core-*.jar
locate log4j|grep -v log4js

On Windows:
dir c: /S /b | findstr /C:”log4″

Stage 1 – Secure all public-facing assets that are critical
Detecting every vulnerable asset in your network is a difficult and time-consuming task. It is best to reinforce security by addressing the internet-facing critical assets to limit the attack surface. Black-box external scanning is not very effective when it comes to Log4j vulnerabilities.

However, we must note that the attack surface is much larger than the applications that are focused on external scans. The attack surface is more than the externally facing IP and ports. Due to the rise of digitization, the points of entry into the organization are multi-fold. Having this clear distinction and value point of a robust platform to deliver the attack surface management results is key.

According to the US Cybersecurity and Infrastructure Agency (CISA), the very first need is to have clear visibility of the external facing assets and secure them.

Stage 2 – Strengthen the network security protection
The Log4Shell signatures are continually updated by WAF and IPS vendors, which can be used as an immediate but temporary response for blocking known exploits. Although WAFs are often intended to protect publicly exposed assets, there are internal exploit paths and situations to this vulnerability that would not be stopped by a WAF. This can also be used as an additional defense layer while performing other mitigations.

It is highly recommended to review and update signatures across your WAF, load balances, and IPS systems that can check different parts of HTTP requests, different JNDI naming services, and prevent bypass methods using keywords. Continuous vigilance of your first line of defense will prove effective in containing the impact.

Stage 3 – Simulate attacks and reinforce operations
With the challenges of morphing Log4j exploits, it is essential that our defense tactics should adapt abilities to simulate attacks and consistently update the security controls in place.

The attacks should be simulated to understand whether the security devices are able to prevent the attacks or not. To accurately measure the actual effectiveness of the security systems against Log4j vulnerability exploits, all valid variants of Log4j exploits must be tested, including evasive payloads. You must:

• Simulate Log4j vulnerability exploit (Log4Shell) attacks.
• Test IPS, WAF, and NGFW for Log4j attacks to uncover gaps.
• Configure prevention signatures to address gaps and block Log4j attacks.
• Secure the network against Log4j attacks.
• Ensure continuous validation of the security controls and Log4j resilience.

Stage 4 – Stronger operational resiliency
Having a cohesive function to address this mayhem will be vital. You must establish an operational mechanism to bring together the leadership, business, cybersecurity, application, systems, cloud, change management, and cross-functional teams. This is of paramount importance.

Conclusion

The cyber community has been emphasizing zero trust with the hindsight that there could be a zero-day at any time. Coming together and staying strong is the key to addressing this. As mentioned in this blog, there are organizations taking the requisite steps we have outlined in one form or another. Getting back to zero vulnerability is a long battle and may not be the right target to chase. However, it is imperative to work together and zero in on the fundamentals to secure your business against the Log4j vulnerability. This is the necessity now and will be for the future as well.

Click to read more about our Digital Security services

References

1. https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/#Sentinel-queries
2. https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance