IronPython - Reflection

As per IronPython site,

IronPython is an open-source implementation of the Python programming language which is tightly integrated with .NET. IronPython can use .NET and Python libraries, and other .NET languages can use Python code just as easily.  IronPython is an excellent addition to .NET, providing Python developers with the power of the .NET. Existing .NET developers can also use IronPython as a fast and expressive scripting language for embedding, testing, or writing a new application from scratch.

 

IronPython has been used by threat actors like Turla to run their tools/malware. Below is an example script that loads assembly into the memory and reflectively invoke the method.

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.

Quick Analysis - CVE-2019-2725 Payload

Since few days now there has been a constant hammering of the weblogic honeypots with the exploits targeting a deserialization vulnerability leading to remote code execution vulnerability identified by CVE-2021-2725. 

The initial request to exploit the vulnerability looks like below,

The payload is a base64 string that gets decoded and saved to "servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/4dde4d88.jsp". Below is the decoded version of the base64 blob.

Following the 1st request a 2nd request is sent to the server. It looks like below ,

Reading the ".jsp" file it is clear that this blob in the 2nd request is base64 encoded and encrypted using AES. The key for decryption is hardcoded in the jsp file. They key can be identified as "fc5e038d38a57032". Using the key the blob in the 2nd request can be decrypted. It turns out the 2nd blob is a class file. The key is also saved in the session using "session.putvalue" into the variable "u". Below is the decrypted version using cyberchef.

Decompiling the class to source we can get an understanding of what's happening in the background. The class gets information about filepath, os, architecture, path, drivelist (line 70-80) encrypts using the same key (line 93 or 109 or 125) and posts it as a response.

Analyzing Apache HTTP Server Information Disclosure Vulnerability - CVE-2021-42013

It was found that the fix for CVE-2021-41773 in Apache HTTP Server 2.4.50 was insufficient. An attacker could use a path traversal attack to map URLs to files outside the directories configured by Alias-like directives. If files outside of these directories are not protected by the usual default configuration "require all denied", these requests can succeed. If CGI scripts are also enabled for these aliased paths, this could allow for remote code execution. 

This issue only affects Apache 2.4.49 and Apache 2.4.50 and not earlier versions. 

To address CVE-2021-41773 the following patch was added.

As you can see the code handles exploit that looks like - "/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd". 

But attackers found ways to bypass this patch and came up with the following uri - "/cgi-bin/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/etc/passwd".

When the URL enters the vulnerable function ap_normalize_path it looks like below,

After normalizing the URL the path looked like below,

The code then enters unescape_url which further normalizes path.

Looking at the function's code we can understand it decodes percent encoded characters to ascii version.

And half way during the function execution we can take a look at the memory and see the percent encoded characters getting replaced to their respective ascii characters.

The parsed uri now becomes.

Later the absolute path is built based on the request path and the path to the file is built. After concatenating the document root with the request path the file path becomes like,

The path is then further resolved based on directory traversal and becomes,

This is the new path where the file gets served/read from.

Nullify AMSI Scanner with PowerShell

 AMSI as per Microsoft is: "The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product that's present on a machine. AMSI provides enhanced malware protection for your end-users and their data, applications, and workloads."

AMSI is being used by multiple antimalware products and is known to cause headache to the malicious actors. Hence malicious actors and red teamers started finding ways around disabling AMSI.

Below is one such PowerShell snippet that's making rounds in the wild made use by the actors to nullify AMSI scanner.

The PowerShell code initially gets hold of the "AmsiScannerBuffer" API and changes the memory protection. Post that it replaces the initial '7' bytes of the function with these bytes - "66B80100C21800". When checking the function now the prologue looks much different.

The overwritten bytes made changes in AmsiScanBuffer so that it always returns '1' (AMSI_RESULT_NOT_DETECTED) denoting that the script that is being scanned is not detected, thus nullifying the effect of AMSI.

References

• https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/
• https://docs.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-amsiscanbuffer