Even though CISA officials stated earlier this month that the Log4j security vulnerability (CVE-2021-44228) has not resulted in any major compromise—other than the cyberattack on the Belgian Defense Ministry—there has been concerning cyber activity that should keep organizations on guard. For example, nation-state activity groups from China, Iran, North Korea, and Turkey have been observed using the zero-day remote code vulnerability for various experimentation and integration activities. More recently, Log4j attacks have been zeroing in on Horizon Servers.
What is even more concerning is how attackers in the wild have been migrating to encrypted versions of the Log4Shell attack using certain encrypted protocols. It is an example of how malicious actors continue to weaponize encryption to avoid detection at various stages of an attack.
BRIEF OVERVIEW OF ENCRYPTED LOG4J ATTACKS
The Log4j flaw allows the Log4j framework to be used to execute any code on vulnerable devices or to infiltrate any application directly. An attacker is able submit a malicious JDNI request to obtain a Java class. This code is located on an external domain controlled by the attacker. Such requests can be easily detected in plaintext traffic. However, in encrypted traffic the requests are concealed, hidden from most security detection and investigation solutions. In a successful Log4j attack, the exploited services will download and execute code from that internet source controlled by the malicious user, typically providing secretive access and full control of the server. After infiltration, the attacker can deposit ransomware, exfiltrate data and more.
There are many encrypted protocols being used for encrypted Log4Shell attacks, including HTTPS on port 443. It is targeting naming and directory services from several available service providers including LDAP, RMI IIOP, NDS, CORBA and NIS.
Applications and services that are written in Java are potentially vulnerable to a Log4j attack. A majority of organizations either directly or indirectly use the Log4j library for logging tasks and to configure applications. It is the global use of the Java framework as well as Log4j’s capability for nesting and lookups that make it a powerful tool for both developers and malicious actors.
LOG4J VULNERABILITY MAKES SOFTWARE SUPPLY CHAINS EVEN MORE VULNERABLE
The high profile Kaseya VSA Supply Chain ransomware attack demonstrated the long and damaging reach of software supply chain attacks. There is a very real potential for the Log4j exploit to cause just as much or more havoc than the supply chain attacks or critical infrastructure attacks in recent years.
Because the use of Log4J is so prevalent, many vendors (and by default their customers) are at risk of attacks as the vulnerability presents too many opportunities for attackers not to exploit it. It makes it all that more important for all organizations to ensure that they and their vendors are doing what is necessary to protect themselves.
The Apache Software Foundation, which manages the Log4j software, has released a security fix for organizations to apply. However, even this presents another complication for software supply chains. The structure of the software supply chain organization means that many organizations rely on their vendors to ensure their software is up to date. There is also the fact that many organizations simply lack awareness of which their applications are vulnerable.
ENCRYPTED LOG4J ATTACKS PROTECTION
Malicious actors can successfully use some encryption protocols to hide malicious code if the right safeguards are not in place. In addition to applying software patches as soon as they are available, organization can also protect their systems and sensitive data against encrypted Log4j attacks and others like them by incorporate the right principles and tools:
Use The Right Tools To Decrypt Traffic. Security tools with decryption capabilities that allow the secure decryption of traffic without violating privacy or security regulations should be used. In the case of Log4Shell attacks, not only should the inbound traffic be examined to spot the JNDI requests that signal a possible exploit, it is also necessary to scrutinize the streams leaving the system as outbound traffic to a random internet site is a feature of Log4j attacks that set it apart from other types of arbitrary code execution attacks.
Use Multi-Factor Authentication. MFA is also needed to reduce the likelihood that stolen credentials can be used to access a system and continue the exploit chain.
Apply The Principle Of Least Privilege. As a requirement of Zero Trust, segmenting off devices, software, servers and restricting access of users to only the systems and data necessary to execute their tasks can significantly reduce the threat surface. It can limit access to resources by ensuring the proper protocols are used.
Use Encryption. The illegitimate use of encryption does not negate the need to use the technology to secure network systems and sensitive data. In fact, it makes the use of quantum-safe encryption even more essential. Organizations should use it as a core element of their data protection, using it in tandem with the appropriate policies. For example, access to decrypted sensitive data should be regulated by users’ rights and privileges and MFA.
XSOC CORP PROVIDES DATA SECURITY SOLUTIONS
The Log4j vulnerability will continue to be exploited for years. Organizations not only have to prioritize determining which of their applications are susceptible and applying the software patches as necessary, they also have to continue to leverage the solutions that will help protect their sensitive data in case of a breach. Contact us for a demonstration and advice on how our cryptography and encryption solutions can enhance your data protection.