Log4Shell - VMware Horizon

VMware Horizon (formerly called Horizon View) is a commercial desktop and app virtualization product developed by VMware, Inc for Microsoft Windows, Linux and macOS operating systems.

VMware Horizon provides virtual desktop and app capabilities to users utilizing VMware's virtualization technology. A desktop operating system - typically Microsoft Windows - runs within a virtual machine on a hypervisor. VMware Horizon product has a number of components which are required to provide the virtual desktops.

One of the component is Connection Server. This component is the connection broker that manages secure access to virtual desktops.

In the initial phase attackers send the crafted HTTP request with the embedded JNDI lookup path to a malicious RMI server. The Connection Server has the vulnerable log4j module that in turn send a request the attacker controlled RMI server. The response to the JRMI request contains the instructions to load the malicious class from attacker controlled server, part of the response looks like below.

The malicious class file in this case is 'RuntimeIinit' that's downloaded from the https server and loaded. The contents of the class file looks like below.

Analyzing the class file we can see that code has a large base64 encoded blob and there are certain hardcoded paths. The code does the following,

1. It creates a new file under path - "..\\broker\\webapps\\portal\\WEB-INF\\classes\\com\\vmware\\vdi\\installer\\listener\\ResourceAccessListener.class"
2. Decodes the base64 encoded data and writes it to the above file path
3. Replaces parts of web.xml, particularly "</listener-class>" to "</listener-class>\r\n      <listener-class>\r\n         com.vmware.vdi.installer.listener.ResourceAccessListener\r\n      </listener-class>"

The default contents of the web.xml (listener tags) looks like below.

The attacker also loads multiple other malicious class files using the log4shell exploit. The attacker atleast loaded 3 other class files to gather information about the target. Some of the other class files that were loaded were,

• DiaLocal.class
• Dialog.class
• LDAPAuthentication.class

The LDAPAuthentication.class file has code to extract information about

• Domain name
• Computer name
• Enumerated information from LDAP server
• Directory structure of 
• C:\Program Files
• C:\Program Files (x86)

We are yet to look at the encoded base64 blob. This base64 encoded blob is in reality a class file that gets written to "..\\broker\\webapps\\portal\\WEB-INF\\classes\\com\\vmware\\vdi\\installer\\listener\\ResourceAccessListener.class". Part of the decompiled version of the class file looks like below (only relevant code included),

Based on the cookie name (calculated using hash of userdomain & computer name which the attacker had already harvested using LDAPAuthentication.class or default hardcoded values) the assigned value can either be a full blown class file that gets loaded using ClassLoader or a malicious expression that gets executed using ScriptEngine.

Look out or block connections JRMI or LDAP requests that are bound to the internet from process "WS_TOMCATSERVICE.EXE". It probably can be a good indicator to find exploitation attempts. There are also multiple free scanner that can help find vulnerable instances of log4j on systems. Use them to find vulnerable systems and patch them ASAP.

Btrace - Tracing JndiLookups - Log4jShell Exploitation Attempts

 BTrace is a safe, dynamic tracing tool for the Java platform.BTrace can be used to dynamically trace a running Java program. BTrace dynamically instruments the classes of the target application to inject tracing code ("bytecode tracing").

BTrace can be used to define trace points that the user is interested to track and when the trace point is reached the user can perform their tasks of interest - such as printing arguments, stack trace etc. 

BTrace can be used to trigger in one of the following scenarios,

OnMethod

OnTimer

OnError 

OnExit 

OnEvent 

OnLowMemory

OnProbe

 OnMethod is what we will be using. BTrace can be used to trace specific method in specific class making it an ideal tool to trace specific functions of interest instead of debugging the Java code.

The class that we are interested to track is org.apache.logging.log4j.core.lookup.JndiLookup and the method is lookup. Using this information we can create the probe file that can be fed to BTrace tool. The probe will have the action to perform once the trace point is hit. Lets create a probe file that will print out the arguments passed to the lookup function. Looking up the definition of lookup function we can understand that argument 2 holds the information about JNDI resource name.

public String lookup(LogEvent event, String key)

Parameters:

event - The current LogEvent (is ignored by this StrLookup).

key - the JNDI resource name to be looked up, may be null

Returns:

The String value of the JNDI resource.

The above code will set the function lookup as trace point and prints the arguments passed to the function. The probe can be run using BTrace like - btrace -v -o <output log> <pid> <path to probe>. The below video shows BTrace's live action. 

CVE-2021-44228 - Retrieving Payload

CVE-2021-44228 tracks a remote code execution vulnerability in Apache Log4j. An attacker who can control the logging message has the ability to execute arbitrary code loaded from attacker controlled JDNI related endpoints such as LDAP, RMI, DNS, HTTP etc.

LDAP Payloads

A typical LDAP attack request can look like this,

To download the payload defenders can resort to using curl. The payload can be downloaded like,

Now that we have the response from the attacker's LDAP server we can understand where the javaCodeBase is located - which is actually a malicious class file that contains code to run malicious commands. Lets follow the class file. The URL to class file can be formed by combining javaCodeBase & javaFactory which becomes http://<attacker_server>:8082/Exploit.class. 

The downloaded class file reveals the attacker's intentions clearly.

You can now further payloads seen in the Java class above.

RMI Payloads

A typical RMI attack request can look like this,

To download payload from the RMI server we can resort to python. I've written a simple python code that can be used to download payload RMI payload from attacker server.

The script can be executed like - python rmi_client.py <attacker_ip> <port> <rmi_endpoint>. Once executed the RMI server should spill out the payload like below.

You can now further payloads seen in the response from the attacker controlled RMI server.