Rewterz Threat Alert – log4j Being Used to Exploit Unifi Networks – Active IOCs

Severity

High

Analysis Summary

Unifi Network applications are being targeted in a similar way to the VMWare Horizon that were being attacked through the Log4j vulnerability.

CVE-2021-44228:

Vulnerability Details:

A high severity vulnerability impacting multiple versions of Apache Log4j. The vulnerability allows for unauthenticated remote code execution. The attacker sends specially crafted HTTP requests to the servers running Apache Log4j 2. Normally the logging frameworks consider all the messages that they receive as text and handle them accordingly with basic formatting, however, Log4j 2.0 added the lookup to add values to the logs.

Multiple types of lookups were provided in Log4j 2.0 like “Context Map Lookup”, “Date Lookup”, “JVM Input Arguments Lookup (JMX)”, “web Lookup”, “JNDI Lookup”, etc. The Java Naming and Directory Interface (JNDI) is a Java API to access a variety of naming and directory services like LDAP, DNS, etc.

The JNDI lookups were not restricted to the local environment. An attacker sends a specially crafted HTTP request to trigger the JNDI lookup. When the lookup is triggered, the server running the Log4j will go over the internet to look up the request which will be the attacker server downloading the malicious code/payload.

Exploits and Proof of Concept (PoC):

Exploits and Proof of Concept were published online for the CVE-2021-44228 vulnerability. Environments with user input hosted on a Java application with unpatched and vulnerable versions of log4j 2.15.0 and lower run the risk of being attacked. 

Attack Flow:

The attack has 2 phases. In the first phase, the attacker sends the specially crafted HTTP request to the server having the JNDI lookup to the attacker server. In the second phase, the malicious payload is downloaded from the attacker server to the victim.

Impact

• Remote Code Execution
• Ransomware
• Local Code Execution
• Denial of Service

Indicators of Compromise

IP

• 179[.]60[.]150[.]32

MD5

• d25c8193771762965e2542adfc9f7e33
• b037f58d8941d533e5f3366d78d59b94
• acd510f56440619e8e03752734f8688c
• 775edd35f6c628fac81963d0e709d911

SHA-256

• cccd16f0c8e1f490f9cf8b0a42d61b52185f0e44e66e098c4f116b3e19f75b1c
• 2275247244f03091373f51d613939f5a96c48481c60832d443c112611142ceba
• 5e53ee9c3299a60b313bdfa3d8b8aaafae67d70eb565a7999e42139d51614462
• 079089176ad528393c0641a630d90ca90a353a3c1765fb052e8c43ed45a29506

SHA-1

• 90e28b7439111e6902d773e9db4c39c1ccb7f3d2
• 160ea6b40f42ef384437482d1456f9ac8aef37f5
• 72d7f701fe6f4a7b079ccbc719a48ae11880bf1a
• 66a7a11314f7ab2d5facfeaa1ec1fae7a37e0090

Remediation

CVE-2021-44228 Mitigation:
Permanent Mitigation:
Version 2.16.0 has been released without the vulnerability. Upgrade to Log4j Version 2.16.0.
https://logging.apache.org/log4j/2.x/index.html
https://logging.apache.org/log4j/2.x/download.html
https://logging.apache.org/log4j/2.x/security.html
Temporary Mitigation:
If upgrading to version 2.16.0 is not possible at the moment, then the following workarounds can be done for mitigating the
vulnerability:
As the lookups are done using the Java packages for JNDI API (com.sun.JNDI.ldap.object.trustURLCodebase) or by
(InitialContext().lookup(“lookup address”)) by creating an instance using (org.apache.naming.factory.BeanFactory), we have
to disable the lookups functionality for the remote serves to mitigate the vulnerability.

1. For Log4j version >= 2.10, the vulnerability can be mitigated by setting either the system property
   “log4j2.formatMsgNoLookups” or environmental variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” to “true” by adding –
   Dlog4j2.formatMsgNoLookups=True when starting the Java Virtual Machine.
2. For Log4j version between 2.0 to 2.10 the vulnerability can be mitigated by removing the “Jndilookup” class from the
   class-path “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”