❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayZero Day Initiative - Blog

CVE-2022-40300: SQL Injection in ManageEngine Privileged Access Management

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Justin Hung and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched SQL injection vulnerability in Zoho ManageEngine products. The bug is due to improper validation of resource types in the AutoLogonHelperUtil class. Successful exploitation of this vulnerability could lead to arbitrary SQL code execution in the security context of the database service, which runs with SYSTEM privileges. The following is a portion of their write-up covering CVE-2022-3236, with a few minimal modifications.


ManageEngine recently patched a SQL injection vulnerability bug in their Password Manager Pro, PAM360, and Access Manager Plus products. The vulnerability is due to improper validation of resource types in the AutoLogonHelperUtil class. A remote attacker can exploit the vulnerability by sending a crafted request to the target server. Successful exploitation could lead to arbitrary SQL code execution in the security context of the database service, which runs with SYSTEM privileges.

The Vulnerability

Password Manager Pro is a secure vault for storing and managing shared sensitive information such as passwords, documents, and digital identities of enterprises. The product is also included in other two similar ManageEngine products: PAM360 and Access Manager Plus. A user can access the web console on these products through HTTPS requests via the following ports:

The HTTP request body may contain data of various types. The data type is indicated in the Content-Type header field. One of the standardized types is multipart, which contains various subtypes that share a common syntax. The most widely used subtype of multipart type is multipart/form-data. Multipart/form-data is made up of multiple parts, each of which contains a Content-Disposition header. Each part is separated by a string of characters. The string of characters separating the parts is defined by the boundary keyword found in the Content-Type header line. The Content-Disposition header contains parameters in “name=value” format. Additional header lines may be present in each part; each header line is separated by a CRLF sequence. The last header line is terminated by two consecutive CRLFs sequences and the form element’s data follows. The filename parameter in a ContentDisposition header provides a suggested file name to be used if the element's data is detached and stored in a separate file.

A user with admin privileges can add/edit a resource type via Password Manager Pro web interface by clicking the menu “Resources” -> “Resource Types” -> “Add” (or “Edit”) and a HTTP multipart/form-data request will be submitted to the “AddResourceType.ve” endpoint, as an example shown below:

where several form-data parts are transferred in the request, like “TYPEID”, “dnsname_label”, “resLabChkName__1”, etc. The data carried in the multipart/form-data part with a name parameter value of “resourceType” represents the name of the resource type, which is relevant to the vulnerability in this report.

An SQL injection vulnerability exists in Password Manager Pro. The vulnerability is due to a lack of sanitization of the name of the resource type in the Java class AutoLogonHelperUtil. The AutoLogonHelperUtil class is used by several controller classes, like AutologonController and PasswordViewController, to construct a partial SQL statement related to the query for existing resource types. For example, if a user clicks the menu “Connections” on the web admin interface, a request will be sent to “AutoLogonPasswords.ec” endpoint, and the includeView() method of ViewProcessorServlet class is called. The includeView() method will use AutologonController class to handle the request. The AutologonController class is derived from the SqlViewController class and its updateViewModel() method is called to process the request. The updateViewModel() method will first call the initializeSQL() method to get an SQL statement. It then calls the getAsTableModel() method of the SQLQueryAPI class to execute the SQL statement.

In the initializeSQL() method, it will call the getSQLString() method of the AutologonController class to get the SQL statement, which will invoke the getFilledString() method of the TemplateAPI class. In the getFilledString() method, it will call the getVariableValue() method of the AutologonController. The getVariableValue() method will use the getOSTypeCriteriaForView() method of the AutoLogonHelperUtil class to construct a partial SQL statement. The getOSTypeCriteriaForView() will call the getOSTypeCriteria() method, which uses getOSTypeList() to read all resource types from the database. It then uses these resource types to build a partial SQL statement as below:

PTRX_OSTYPE in ( <resource type 1>, <resource type 2>, ..., <resource type n> )

where <resource type n> represents a resource type name queried from a database by the getOSTypeList() method. Then, this partial SQL statement will be returned to getOSTypeCriteriaForView() and then be returned to the getFilledString(). The getFilledString() will use this partial SQL statement to generate the final complete SQL statement and return it back to getSQLString().

However, the getOSTypeCriteria() method of the AutoLogonHelperUtil class does not sanitize the name of the resource type (returned from getOSTypeList()) for SQL injection characters before using it to create a partial SQL statement. An attacker can therefore first add a new resource type (or edit an existing resource type) with a crafted resource type name containing a malicious SQL command, and then click a menu such as “Connections” to invoke the methods of the AutoLogonHelperUtil class which will use the malicious resource type name to construct a SQL statement. This could trigger the execution of the injected SQL command.

A remote authenticated attacker can exploit the vulnerability by sending a crafted request to the target server. Successful exploitation could lead to arbitrary SQL code execution in the security context of the database service, which runs with SYSTEM privileges.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the ports listed above. Note that the traffic is encrypted via HTTPS and should be decrypted before performing the following steps.

The detection device must inspect HTTP POST requests to a Request-URI containing the following string:

        /AddResourceType.ve

If found, the detection device must inspect each part of the multipart/form-data parts in the body of the request. In each part, the detection device must search for the Content-Disposition header and its name parameter to see if its value is “resourceType”. If found, the detection device must continue to inspect the data carried in this multipart/ form-data part to see if it contains the single-quote character “' (\x27)”. If found, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway. An example of malicious requests is shown below:

Additional notes:

• The string matching for the Request-URI and “POST” should be performed in a case-sensitive manner, while other string matching like “name”, “resourceType” and “Content-Disposition” should be performed in a case-insensitive manner.
• The Request-URI may be URL encoded and should be decoded before applying the detection guidance.
• It is possible that the single quote “' (\x27)” is naturally found in the resource type name resulting in false positives. However, in normal cases, the possibility should be low.

Conclusion

ManageEngine patched this and other SQL injections in September. Interestingly, the patch for PAM360 came a day after the patches for Password Manager Pro and Access Manager Plus. The vendor offers no other workarounds. Applying these updates is the only way to fully protect yourself from these bugs.

Special thanks to Justin Hung and Dusan Stevanovic of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

CVE-2022-40300: SQL Injection in ManageEngine Privileged Access Management

CVE-2022-3236: Sophos Firewall User Portal and Web Admin Code Injection

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched code injection vulnerability in the Sophos Firewall. The bug is due to improper validation of JSON keys submitted in the “JSON” parameter sent to the Controller endpoint. Successful exploitation of this vulnerability could result in remote code execution with the privileges of the root user. The following is a portion of their write-up covering CVE-2022-3236, with a few minimal modifications.


Sophos recently patched a code injection vulnerability in Sophos Firewall v19.0 MR1 (19.0.1) and previous. This vulnerability is due to improper validation of JSON keys submitted in the “json” parameter sent to the Controller endpoint. A remote, unauthenticated attacker could exploit this vulnerability by sending a specially crafted request to an affected server. Successfully exploiting this vulnerability could result in remote code execution with the privileges of the root user.

The Vulnerability

Sophos Firewall is a network security solution, which can be deployed on purpose-built devices, on a cloud network (AWS/Azure), on a virtual device, or as a software appliance on x86 Intel hardware. The firewall application supports multiple network security features, including application-aware routing, TLS inspection, deep packet inspection, remote access VPN, logging, and reporting. Sophos Firewall exposes a web admin console for managing the device’s configuration via HTTPS on TCP port 4444. In addition, Sophos Firewall exposes a user portal for updating a user’s details or downloading authentication clients via HTTPS on TCP port 443.

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like this:

A corresponding HTTP request using the POST method might look like this:

JavaScript Object Notation (JSON) is a data-interchange format used for creating machine parseable, human-readable output. A JSON object has the following syntax:

• An object is enclosed in curly braces {}.
• An object is comprised of zero or more items delimited by a comma (“,”) character.
• An item is comprised of a key and a value. A key is delimited from its value by a colon (“:”) character.
• A key must be a string enclosed in quotes.
• A value must be a valid type. JSON defines seven value types: string, number, object, array, true, false, and null.
• An array is an object enclosed in square braces [].
• An array is comprised of zero or more strings, numbers, JSON objects, arrays, boolean, or null type-objects delimited by a comma (“,”) character.

An example JSON object is as follows:

      {“name”:”bob”, “age”:30}

The web admin and user portal web interfaces exposed by Sophos Firewall both run on a Jetty server behind an Apache httpd server. Configuration and diagnostic requests issued through these interfaces are submitted via requests to the Controller servlet. This servlet retrieves the appropriate EventBean object based on the mode HTTP request parameter. For example, if the mode HTTP request parameter is set to 151 or 451, the WebAdminAuth or UserPortalAuth classes are called to process the request, respectively. In each of these classes, the generateAndSendAjaxEvent() method of the CSCClient class is called. This method parses the json HTTP request parameter and modifies specific fields from the parsed object. The send() method is then called, which in turn calls _send(), which adds the mode JSON parameter according to the mode of the associated EventBean object. It then sends the created JSON object as a string, including appropriate headers, to the local CSC server over TCP or UDP port 299.

When the CSC server receives the JSON object submitted by the Jetty server, it validates the JSON object submitted via the validateJSON() method in the Perl script CyberAPIArch.pm. If the JSON object contains a key named _discriminator, the getValidationHash() method is called. This method iterates over each key of the _discriminator Perl hash, representing field names. Each field name is associated with a JSON object describing the mapping between field values and object names. Some Perl objects resolved when parsing the JSON object received (natrule, securitypolicy, hotspot, etc.) contain a template with a _discriminator key containing such a mapping for specific field names between field values and their associated objects. The method iterates over the field values to check whether the submitted JSON object contains a field with the referenced name and value. If so, it retrieves the associated object name and attempts to resolve it to an object using the eval function.

A code injection vulnerability has been reported for Sophos Firewall. This vulnerability is due to improper validation of JSON keys submitted in the “json” parameter sent to the Controller endpoint. Specifically, the _discriminator key can be set in the HTTP request. This JSON object is sent, after some modification, to the CSC server. However, the _discriminator key set is sent unmodified. Once the validateJSON() method of the Perl script CyberAPIArch.pm is called, it will detect this key and call getValidationHash(). The Perl method iterates over the $hashObj hash object, which contains a key named _discriminator whose value is a nested hash with a value key set with the value set for the _discriminator key in the original request sent. This value key is treated as a nested hash containing field values mapped to object names. Therefore, if the originally submitted JSON object contains a key named value with its value set to one of the values in this nested hash, the associated object name will be resolved using the eval function. Since the _discriminator key in the original request can be set to a JSON object with an arbitrary mapping between values and object names, a malicious object can be submitted to be concatenated into the eval function, resulting in code injection.

Sophos attempts to perform input validation on request parameters, including the JSON object, using the RequestCheckFilter Java object. This filter detects request parameters and JSON keys with non-ASCII printable characters. However, arbitrary request parameters and JSON keys containing ASCII printable characters can still be submitted, including the _discriminator key.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successfully exploiting this vulnerability could result in arbitrary Perl commands being run on the server, resulting in remote code execution with the privileges of the root user.

Source Code Walkthrough

The following code snippet was taken from Sophos Firewall version 19.0.1 with additional comments added by Trend Micro.

From the decompiled Java class cyberoam.sessionmanagement.RequestCheckFilter:

From the Perl script CyberAPIArch.pm:

Detecting Attacks

To detect an attack attempting to exploit this vulnerability, the detection device must monitor and parse traffic on ports 443/TCP and 4444/TCP. Note that the traffic is encrypted with SSL/TLS. The detection device must decrypt the traffic before proceeding through the next steps.

Based on the TCP ports monitored, the detection device must inspect HTTP GET and POST requests to a Request- URI containing the following string:

Requests to the Webadmin Controller endpoint (TCP port 4444) can use the multipart/form-data encoding.

Multipart/form-data is made up of multiple parts, each of which contains a Content-Disposition header. Each part is separated by a string of characters. The string of characters separating the parts is defined by the boundary keyword found on the Content-Type header line, which is set to “multipart/form-data”. The Content-Disposition header contains a name parameter describing the form element being returned. Additional header lines may be present in each part. Each line is separated by a new line sequence. The header is terminated by two consecutive new lines. The form element's data follows. The filename parameter provides a suggested filename to be used if the entity is detached and stored in a separate file. The following is a sample Content-Disposition header for a file item, where the boundary keyword is “TMSR”:

If a request to one of the above endpoints is found, the detection device must parse its parameters according to the encoding described in the Content-Type header and search for the json parameter. If found, the detection device must inspect the json parameter value using any suitable methods below.

Method 1: If the detection device is capable of parsing JSON, it must parse the json parameter as a JSON object. The detection device must parse any items (potentially nested) whose key is the string “_discriminator”. If found, the traffic should be considered malicious as an attack exploiting this vulnerability is likely underway.

Method 2: If the detection device is not capable of parsing JSON, it must inspect the json parameter as a string and check if it contains the string “_discriminator”. If found, the traffic should be considered malicious as an attack exploiting this vulnerability is likely underway.

Additional things to note:

• Parameter names and values may be URL-encoded and must be decoded before applying the above detection guidance.
• String matching for the URI and parameter names (“json”) and values (“_discriminator”) must be performed in a case-sensitive manner.
• String matching for HTTP header names (i.e., “Content-Type”) and values (i.e., “multipart/form-data”) must be performed in a case-insensitive manner.

Conclusion

There are reports that this vulnerability is being used to target a small group of organizations and that Sophos has “informed each of these [affected] organizations directly.” This bug is also similar to a previous vulnerability, CVE-2022-1040, that that Volexity and The Record claim was used by a Chinese APT crew in March 2022. Regardless, this bug has a CVSS base score of 9.8 and should be remediated immediately. Sohpos users who don’t have hotfixes enabled or are on legacy versions should patch immediately as outlined in Sophos’s advisory. You should also consider blocking the affected ports from external network access if it is not required.

Special thanks to Guy Lederfein and Dusan Stevanovic of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

 

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter or Instagram for the latest in exploit techniques and security patches.

CVE-2022-3236: Sophos Firewall User Portal and Web Admin Code Injection

CVE-2022-34715: More Microsoft Windows NFS v4 Remote Code Execution

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Quintin Crist and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Windows operating system, originally discovered and reported by the researcher known as Arimura. The bug is the result of a dynamically allocated buffer created by an NFS function and is present only on Windows Server 2022. An unauthenticated attacker could exploit this bug to execute arbitrary code in the context of SYSTEM. This is the third such NFS vulnerability in as many months. The following is a portion of their write-up covering CVE-2022-34715, with a few minimal modifications.


A remote code execution vulnerability exists in Windows Network File System. The vulnerability is due to incorrect validation of fields within an NFS request. A remote attacker can exploit this vulnerability by sending malicious RPC calls to a target server. Successful exploitation results in arbitrary code execution in the context of SYSTEM. Unsuccessful exploitation may result in a crash of the target system.

The Vulnerability

Microsoft Windows ships with several network features designed to communicate and interact with non-Windows file shares. One of these modules is called Network File System (NFS).

NFS is a protocol originally developed by Sun Microsystems in 1984. Version 2 is documented in RFC 1094. Version 3 is documented in RFC 1813. Version 4 was developed by the IETF and is documented in RFC 3010 (released December 2000) and revised in RFC 3530 (released April 2003) and RFC 7530 (released March 2015). NFS allows users to access remote file shares in the same way that the local file system is accessed. Different access levels and permissions can be set on shares, such as read-write and read-only. Additionally, IP/UID/GID/Kerberos security can be used. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. ONC RPC was originally developed by Sun Microsystems and can also be referred to as Sun RPC.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the following table) that specifies the length of the message. This allows the receiver to distinguish multiple messages sent over a single TCP session. Other protocols such as UDP do not use this field. Note that all multi-byte values are encoded in big-endian byte order.

The structure of ONC RPC request messages, in general, is as follows:

The Credentials structure in a Sun-RPC message has the following structure:

The Flavor field in the above structure serves as a type identifier of the Contents data. Security flavors have been called authentication flavors for historical reasons. There are multiple security flavors defined in the RPC specification, such as AUTH_NONE(0), AUTH_SYS(1), AUTH_SHORT(2), AUTH_DH(3), and RPCSEC_GSS(6).

The Contents field for the flavor RPCSEC_GSS has the following structure:

There are four types defined for the GSS Procedure field: RPCSEC_GSS_DATA(0), RPCSEC_GSS_INIT(1), RPCSEC_GSS_CONTINUE_INIT(2), and RPCSEC_GSS_DESTROY(3). Also, for the GSS Service field, there are three types: rpc_gss_svc_none(1), rpc_gss_svc_integrity(2), and rpc_gss_svc_privacy(3). When using RPCSEC_GSS to authenticate RPC clients, a security context must be created by using RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT RPC messages. First, the RPC client sends an RPCSEC_GSS_INIT message to start the creation of the context. Then, the RPC server decides whether it needs another token for the creation. If so, the server replies with a GSS_S_CONTINUE_NEEDED message, and the client needs to send an RPCSEC_GSS_CONTINUE_INIT message to continue.

If the GSS Service field is set to 2 (rpc_gss_svc_integrity), the Program-specific data field is prefixed with the following structure:

If the GSS Service field is set to 3 (rpc_gss_svc_privacy), the Program-specific data field is encrypted.

When the Program field is set to 100003 (NFS) and the Procedure field is set to 1 (Compound), the Program-specific data field has the following structure:

In the request data, for each operation in the message:

Operation data for opcode OP_CREATE(6):

Operation data for opcode OP_OPEN(18):

Operation data for opcode OP_SETATTR(34):

Attributes Data (fattr4) has the following format:

Attributes Data for ACL ( Bit12, 0x1000 ):

A buffer overflow vulnerability exists in the Windows implementation of NFS. The vulnerability is due to incorrect validation of the of the ACE_Count field when processing ACL attribute data in Nfs4SrvAclBuildWindowsAclsFromNfsAcl.

This function is only vulnerable when setting ACL attribute data using opcodes 6, 18, 34.

The server allocates a response buffer of size (ACE_Count << 5). This size is stored as a uint64_t in Nfs4SrvAclBuildWindowsAclsFromNfsAcl. A buffer of this size is created using NfsMemMgrBufferAllocate. However, NfsMemMgrBufferAllocate only takes a uint32_t for the buffer size, so the upper 32 bits of the requested size is ignored.

This allows an attacker to specify an ACE_Count such that (ACE_Count << 5) & 0xFFFFFFFF < ACE_Count. This will result in a buffer overflow later in the function when the buffer is used.

In particular, ACE_Count values above 0x8000000 will trigger this vulnerability.

Note that ACE_Count = 0x8000000 itself is not vulnerable since NfsMemMgrBufferAllocate will error when the requested length is zero.

An attacker can use this vulnerability to overflow a heap buffer. Successful exploitation may result in arbitrary code execution in the context of SYSTEM. Unsuccessful exploitation will result in a crash of the target system.

Source Code Walkthrough

The following code snippet was taken from nfssvr.sys version 10.0.20348.825. Comments have been added by Trend Micro researchers.

Detecting Attacks

The detection device needs to check if the Program field in an RPC request message has the value 100003 (NFS), Procedure field has the value 1 (COMPOUND), and Program Version field has the value 4 (NFS4). If found, the device must inspect the Program-specific data in the ONC RPC messages.

The detection device should check for the vulnerable opcodes (6, 18, 34) in each operation. If present the device should check the operation for ACL attribute data. If ACL attribute data is present, the device should check for an ACE_Count field above 0x8000000.

There is no fixed offset into the message that can be used to ignore non-vulnerable opcodes since NFS operations do not consistently contain a length of the operation data. The full message must be processed to determine if there is any ACL attribute data.

If the ACE_Count field is greater than 0x8000000, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Conclusion

This bug was patched by Microsoft in August 2022 and assigned CVE-2022-34715. Their advisory lists the vulnerability as not requiring authentication. However, all known exploitation paths require file creation or modification privileges. In their write-up, they also list disabling NFSv4.1 as a method to mitigate attacks. However, this could lead to a loss of functionality. Applying the NFS-related updates is the best method to fully address the multiple NFS bugs patched in recent months.

Special thanks to Quintin Crist and Dusan Stevanovic of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter or Instagram for the latest in exploit techniques and security patches.

CVE-2022-34715: More Microsoft Windows NFS v4 Remote Code Execution

CVE-2022-30136: Microsoft Windows Network File System v4 Remote Code Execution Vulnerability

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Quintin Crist of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Windows operating system, originally discovered and reported by Yuki Chen. The bug is found in the implementation of Network File System (NFS)and is due to improper handling of NFSv4 requests. An unauthenticated attacker could exploit this bug to execute arbitrary code in the context of SYSTEM. The following is a portion of their write-up covering CVE-2022-30136, with a few minimal modifications.


A remote code execution vulnerability exists in Windows Network File System. The vulnerability is due to improper handling of NFSv4 requests.

A remote attacker can exploit this vulnerability by sending malicious RPC calls to a target server. Successful exploitation results in arbitrary code execution in the context of SYSTEM. Unsuccessful exploitation may result in a crash of the target system.

The Vulnerability

Microsoft Windows ships with several network features designed to communicate and interact with non-Windows file shares. One of these modules is called Network File System (NFS).

NFS is a network file system protocol originally developed by Sun Microsystems in 1984. Version 2 is documented in RFC 1094. Version 3 is documented in RFC 1813. Version 4 was developed by the IETF and is documented in RFC 3010 (released December 2000) and revised in RFC 3530 (released April 2003) and RFC 7530 (released March 2015). NFS allows users to access remote file shares in the same way that the local file system is accessed. Different access levels and permissions can be set on the share, such as read-write and read-only. Additionally, IP/UID/GID/Kerberos security can be used. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. ONC RPC was originally developed by Sun Microsystems and can also be referred to as Sun RPC.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the following table) that specifies the length of the message. This allows the receiver to distinguish multiple messages sent over a single TCP session. Other protocols such as UDP do not use this field. Note that all multi-byte values are encoded in big-endian byte order.

The structure of ONC RPC request messages, in general, is as follows:

The Credentials structure in a Sun-RPC message has the following structure:

The Flavor field in the above structure serves as a type identifier of the Contents data. Security flavors have been called authentication flavors for historical reasons. There are multiple security flavors defined in the RPC specification, such as AUTH_NONE(0), AUTH_SYS(1), AUTH_SHORT(2), AUTH_DH(3), and RPCSEC_GSS(6).

The Contents field for the flavor RPCSEC_GSS has the following structure:

There are four types such as RPCSEC_GSS_DATA(0), RPCSEC_GSS_INIT(1), RPCSEC_GSS_CONTINUE_INIT(2), and RPCSEC_GSS_DESTROY(3) defined in the GSS Procedure field. Also, in the GSS Service field, there are three types: rpc_gss_svc_none(1), rpc_gss_svc_integrity(2), and rpc_gss_svc_privacy(3). When using RPCSEC_GSS to authenticate the RPC clients, a security context must be created by using RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT RPC messages. First, the RPC client sends an RPCSEC_GSS_INIT message to start the creation of the context. Then, the RPC server decides whether it needs another token for the creation. If so, the server replies with a GSS_S_CONTINUE_NEEDED message, and the client needs to send an RPCSEC_GSS_CONTINUE_INIT message to continue.

If the GSS Service field is set to 2 (rpc_gss_svc_integrity), the Program-specific data field is prefixed with the following structure:

If the GSS Service field is set to 3 (rpc_gss_svc_privacy), the Program-specific data field is encrypted.

When the Program field is set to 100003 (NFS) and the Procedure field is set to 1 (Compound), the Program-specific data field has the following structure:

A buffer overflow vulnerability exists in the Windows implementation of NFS. The vulnerability is due to incorrect calculation of the size of response messages. The server calls the function Nfs4SvrXdrpGetEncodeOperationResultByteCount() to calculate the size of each opcode response, but it does not include the size of the opcode itself. This results in the size of the response buffer being too small by OP Count * 4 bytes. A corresponding buffer is allocated with OncRpcBufMgrpAllocate. When the response data is written to the buffer, the response data overflows. Due to the function only being used for NFS version 4, only NFS4 is vulnerable.

OncRpcBufMgrpAllocate() will actually allocate the data with either OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer(), when the request is under 0x800 bytes in size, or OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation(), which is used otherwise.

OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer() returns a buffer in a static 0x800 bytes inside the descriptor. The descriptor structure has 0x50 bytes of space that appears to be unused after the static buffer.

OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation() returns a buffer allocated with ExAllocatePoolWithTag(). The number of bytes allocated is equal to the following:

This means that for either buffer type, more than 0x48 bytes must be overflowed to get past the padding in either buffer type. Since the number of overflowed bytes is OP Count * 4, a minimum of 19 operations must be performed in a compound message for the overflow to have any impact.

An attacker can use this vulnerability to send a crafted request with many operations, producing a large size miscalculation, resulting in a buffer overflow. Successful exploitation results in arbitrary code execution in the context of SYSTEM. Unsuccessful exploitation may result in a crash of the target system.

Detecting Attacks

Much of this information is largely seen earlier in this post. It is reposted here for your convenience.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the following table) that specifies the length of the message. This allows the receiver to distinguish multiple messages sent over a single TCP session. Other protocols such as UDP do not use this field. Note that all multi-byte values are encoded in big-endian byte order.

The structure of ONC RPC request messages is shown above, as is the Credentials structure in a Sun-RPC message. As shown above, the Flavor field in the above structure serves as a type identifier of the Contents data. Security flavors have been called authentication flavors for historical reasons. There are multiple security flavors defined in the RPC specification, such as AUTH_NONE(0), AUTH_SYS(1), AUTH_SHORT(2), AUTH_DH(3), and RPCSEC_GSS(6).

As a reminder, the Contents field for the flavor RPCSEC_GSS has the following structure:

There are four types such as RPCSEC_GSS_DATA(0), RPCSEC_GSS_INIT(1), RPCSEC_GSS_CONTINUE_INIT(2), and RPCSEC_GSS_DESTROY(3) defined in the GSS Procedure field. Also, in the GSS Service field, there are three types: rpc_gss_svc_none(1), rpc_gss_svc_integrity(2), and rpc_gss_svc_privacy(3). When using RPCSEC_GSS to authenticate the RPC clients, a security context must be created by using RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT RPC messages. Firstly, the RPC client sends an RPCSEC_GSS_INIT message to start the creation of the context. Then, the RPC server will decide whether it needs another token for the creation. If so, the server will reply with a GSS_S_CONTINUE_NEEDED message, and the client needs to send an RPCSEC_GSS_CONTINUE_INIT message to continue.

If the GSS Service field is set to 2 (rpc_gss_svc_integrity), the Program-specific data field is prefixed with the following structure:

If the GSS Service field is set to 3 (rpc_gss_svc_privacy), the Program-specific data field is encrypted and must be decrypted before continuing.

The detection device needs to check if the Program field in an RPC request message has the value 100003 (NFS), the Procedure field has the value 1 (COMPOUND), and the Program Version field has the value 4 (NFS4). If found, the device must inspect the Program-specific data in the ONC RPC messages.

The data format of NFS COMPOUND has the following structure:

The buffer overflow is only triggered if at least 19 operations are present in the NFS reply. Since the NFS reply has the response for each operation in the NFS request, request messages should be monitored for an OP Count field greater than 18.

If a packet with greater than 18 operations is detected, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Note that all multi-byte values are expressed in network (big-endian) byte order. Also, this detection method may generate false positives if normal traffic contains similar NFS COMPOUND requests.

Conclusion

This bug was patched by Microsoft in June 2022 and assigned CVE-2022-30136. In their write-up, they also list disabling NFSv4.1 as a method to mitigate attacks. However, this could lead to a loss of functionality. Also, Microsoft notes the update to address this bug should not be applied unless the fix for CVE-2022-26937 is installed. Applying both updates in the appropriate order is the best method to fully address these vulnerabilities.

Special thanks to Guy Lederfein and Quintin Crist of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2022-30136: Microsoft Windows Network File System v4 Remote Code Execution Vulnerability

CVE-2022-26937: Microsoft Windows Network File System NLM Portmap Stack Buffer Overflow

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Jason McFadyen of the Trend Micro Research Team detail a recently patched code execution vulnerability in the Microsoft Windows operating system. The bug was originally discovered and reported to Microsoft by Yuki Chen. A stack buffer overflow vulnerability exists in Windows Network File System. A remote attacker can exploit this vulnerability by sending specially crafted RPC packets to a server, resulting in code execution in the context of SYSTEM. The following is a portion of their write-up covering CVE-2022-26937, with a few minimal modifications.


A stack buffer overflow vulnerability exists in Windows Network File System. The vulnerability is due to improper handling of crafted RPC responses to Portmap requests made by the Network Lock Manager (NLM) RPC program.

A remote attacker can exploit this vulnerability by sending malicious RPC calls to a target server. Successful exploitation may result in arbitrary code execution under the context of SYSTEM. Unsuccessful exploitation results in a crash of the target system.

The Vulnerability

Microsoft Windows ships with several network features designed to communicate and interact with non-Windows files shares. One of these modules is called Network File System (NFS).

NFS is a network file system protocol originally developed by Sun Microsystems in 1984. Version 2 is documented in RFC 1094. Version 3 is documented in RFC 1813. Version 4 was developed by the IETF and is documented in RFC 3010 (released December 2000) and revised in RFC 3530 (released April 2003) and RFC 7530 (released March 2015). NFS allows users to access remote file shares in the same way that the local file system is accessed. Different access levels and permissions can be set on the share, such as read-write and read-only. Additionally, IP/UID/GID/Kerberos security can be used. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. ONC RPC was originally developed by Sun Microsystems and can also be referred to as Sun RPC.

The Network Lock Manager (NLM) protocol is an extension of NFS versions 2 and 3, which provides a System V style of advisory file and record locking over the network. Since NFS versions 2 and 3 are stateless protocols, the NLM protocol was developed to manage the state of locks on files stored on NFS shares. The NLM protocol supports both synchronous and asynchronous procedures to implement locking and file-sharing functionality. Similar to NFS, NLM also uses ONC RPC to exchange control messages.

ONC RPC uses XDR packets, which can be transmitted over UDP or TCP. Over UDP, the XDR packet is contained within the UDP payload. Over TCP, XDR packets are preceded by a Fragment header (as illustrated in the following table). The most significant bit of the Fragment header indicates whether the packet is the last fragment, and the remaining 31 bits are the length of the Fragment that follows. The Fragment itself contains the XDR packet.

The structure of an ONC RPC call is as follows:

The Program field of the RPC message specifies what RPC service the message is sent to. Windows NFS server implements the NLM protocol via RPC with Program type set to 100021. It supports multiple RPC procedures, which can be specified in the Procedure field in the RPC message. A list of synchronous and asynchronous procedures supported by the NLM protocol version 3 follows:

Microsoft Windows runs the RPCBIND RPC program, which implements the Port Mapper protocol, documented in RFC 1833. The RPCBIND program converts RPC program numbers into universal addresses, which can then be used by programs to communicate over UDP or TCP. Briefly, the way it works is that when a program wishes to use RPC, it registers its ports with the host's Port Mapper. A client that wishes to issue RPC calls connects to the Port Mapper, uses various RPC calls such as GETPORT, GETADDR etc. to obtain a port on which the RPC service is available, and connects to the desired RPC service. Standard RPC program numbers have been defined and maintained by IANA and they include portmapper (100000), nfs (100003), mount daemon (100005) and hundreds of other less commonly used programs. Only the portmapper service and NFS service have standard ports of 111 and 2049 respectively.

Windows implements the RPCBIND protocol via RPC with Program type set to 100000. It supports multiple RPC procedures, which can be specified in the Procedure field in the RPC message. One of the procedures supported by the RPCBIND program when Program Version is set to 3 or 4, is GETADDR, which is procedure number 3. The reply to this RPC call contains the Universal Address associated with the callee. The format for the returned Universal Address is XDR_String, which has the following format:

A stack buffer overflow vulnerability exists in Windows Network File System. More specifically, the vulnerability is due to incorrect handling of the Universal Address field returned in GETADDR RPC replies. When Windows NFS responds to an NLM call in an asynchronous manner, the NlmGetClientAddressAndConnection() function is called. This flow is triggered either as a response to an asynchronous NLM call, such as NLM_TEST_MSG, NLM_LOCK_MSG, NLM_UNLOCK_MSG, or when the server sends an `NLM_GRANTED` call to the client, after a previous (synchronous or asynchronous) call by the client to create a lock returned the status `LCK_BLOCKED`. If the IPv6 protocol is used for communication over the ONC RPC protocol, the server will issue a GETADDR RPC call to the client to retrieve its IP address. When the Universal Address field returned by the client in the GETADDR reply is processed by the NFS server, the field is copied using memmove() into a buffer of size 96 bytes. In addition, this buffer is later referenced at an index equal to the Universal Address field’s string size and set to 0. However, the NlmGetClientAddressAndConnection() function does not verify the size of the returned Universal Address string. Therefore, if the string provided by the client is 96 bytes or longer, the buffer will be written past its boundary, resulting in the stack buffer overflow condition.

A remote attacker can exploit this vulnerability by sending an NLM request triggering an asynchronous response by the NFS server. When the server sends a GETADDR RPC request, the attacker can respond with a crafted GETADDR reply. Successful exploitation may result in arbitrary code execution under the context of SYSTEM. Unsuccessful exploitation results in a crash of the target system.

Source Code Walkthrough

The following code snippet was taken from nfssvr.sys version 10.0.17763.1999. Comments added by Trend Micro have been highlighted.

 In function NlmGetClientAddressAndConnection():

Detecting Attacks

ONC RPC uses XDR packets, which can be transmitted over UDP or TCP. Over UDP, the XDR packet is contained within the UDP payload. Over TCP, XDR packets are preceded by a Fragment header (as illustrated in the following table). The most significant bit of the Fragment header indicates whether the packet is the last fragment, and the remaining 31 bits are the length of the Fragment that follows. The Fragment itself contains the XDR packet.

The detection device must inspect all outgoing ONC RPC calls, which have the following structure:

The detection device must check if the Message Type field is 0 (Call), the Program field is 100000 (portmap), the Program Version field is larger than 2, and the Procedure field is equal to 3 (GETADDR). If found, the device must inspect the Program-specific data object. This object uses the rpcb structure, which has the following format:

If the Program Number field is set to 100021 (NLM), the detection device must inspect all incoming ONC RPC replies, which have the following structure:

The detection device must check if the XID field is equal to the XID field of the GETADDR RPC call detected, and the Message Type field is 1 (Reply). If found, the device must inspect the Program-specific data object. This object uses the XDR_String structure, which has the following format:

If the String Length field is larger than 95, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Conclusion

This bug was patched by Microsoft in May 2022 and assigned CVE-2022-26937. In their write-up, they also list disabling NFSV2 and NFSV3 as a method to mitigate attacks. However, this could lead to a loss of functionality. Applying the security update is the best method to fully address this vulnerability.

Special thanks to Guy Lederfein and Jason McFadyen of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2022-26937: Microsoft Windows Network File System NLM Portmap Stack Buffer Overflow

CVE-2021-44790: Code Execution on Apache via an Integer Underflow

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Dusan Stevanovic of the Trend Micro Research Team detail a recent code execution vulnerability in the Apache webserver. The bug was originally discovered and reported by the researcher named Chamal. A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser, which could lead to code execution in the context of the security process. The following is a portion of their write-up covering CVE-2021-44790, with a few minimal modifications.


An integer underflow vulnerability has been reported in the mod_lua module of Apache httpd. The vulnerability is due to improper validation of the request body in the module's multipart parser, called via the r:parsebody() function in Lua scripts. A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation could lead to remote code execution under the security context of the server process, while an unsuccessful attack could lead to a denial-of-service condition.

The Vulnerability

The Apache HTTP server is the most popular webserver used on the Internet. The server is capable of being utilized with many different options and configurations. A wide variety of runtime loadable plug-in modules can be used to extend its functionality.

One of the official plug-in modules is the mod_lua module. As with all other modules, it can be compiled as a separate shared library with a “.so” extension. The purpose of this module is to allow the extension of the HTTP server with scripts written in the Lua programming language. If this module is loaded in the HTTP server configuration file, the lua-script handler can be set for files ending in “.lua”. The following demonstrates such a sample configuration:

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character.Parameters can be passed from the client to the server as name-value pairs in either the Request-URI, or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like this:

A similar request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

        var1=value1&var2=value2&var3=value3...

The data in the Body of HTTP POST requests can be encoded using various standardized or proprietary methods. One of the standardized methods is multipart/form-data, defined in RFC 2388. Multipart/form-data is made up of multiple parts, each of which contains a Content-Disposition header. Each part is separated by a string of characters. The string of characters separating the parts is defined by the boundary keyword found on the Content-Type header line. The Content-Type must also be set to multipart/form-data. The Content-Disposition header contains a name parameter describing the form element being returned. Additional header lines may be present in each part; each line is separated by a new line sequence. The header is terminated by two consecutive new lines. The form element's data follows. The filename parameter provides a suggested filename to be used if the entity is detached and stored in a separate file.

One of the built-in functions supported by the mod_lua module is r:parsebody(). This function allows Lua scripts to parse the body of HTTP POST requests sent to the server. The function returns two Lua tables containing the parameter names and values parsed from the body. This function also supports HTTP POST requests encoded using the multipart/form-data content type.

An integer underflow vulnerability exists in the Apache HTTP server. When the mod_lua module is enabled and the r:parsebody() function is called from within a Lua script parsed by the server, the function req_parsebody() is called. This function checks if the HTTP POST request received by the server contains a Content-Type header beginning with the string "multipart/form-data; boundary=", indicating that the request body is encoded using the multipart/form-data content type. If found, the function searches for the boundary string defined in the ContentType header, saved to the multipart variable. After each match of the multipart string, the function searches for the first occurrence of two consecutive CRLF sequences, stored to the CRLF variable. If this match is found, the function searches in the following content for another occurrence of the multipart variable, stored to the end variable, indicating the end of the form element's data.

Later, the size of the form element's data is calculated by taking the end variable, subtracting the CRLF variable, then subtracting 8 (representing the two CRLF sequences before the element's data, and the CRLF and "--" characters at the end of the element's data). However, if the form element is not properly formatted, such that the end boundary string appears within less than 8 characters after the beginning of the two CRLF sequences, this subtraction would result in a negative number. The result of the subtraction is stored in a variable named vlen of type size_t. Therefore, if the subtraction results in a negative number, it will be converted into a large positive number before being stored in the vlen variable, resulting in an integer underflow. Specifically, if the subtraction results in -1, the vlen variable will contain the maximum size of size_t. Later, a buffer named buffer is allocated on the heap with a size of vlen+1. In the case described, this will result in an integer overflow, resulting in the allocation of a buffer of size 0. Later, the memcpy() function is called to copy the element's data into the buffer variable, with a size of vlen, resulting in a buffer overflow.

A remote, unauthenticated attacker could exploit this vulnerability by sending an HTTP POST request with a crafted body, encoded using the multipart/form-data content type, to the target server. Successful exploitation could lead to remote code execution under the security context of the server process, while an unsuccessful attack could lead to a denial-of-service condition.

Detection of Generic Attacks

The detection device must inspect all HTTP POST requests to URLs resolving to Lua scripts hosted on the Apache server. The detection device must then inspect the Content-Type header and check if it is set to “multipart/formdata”. If found, the detection device must inspect all instances of the boundary string from the Content-Type header in the HTTP body. For each instance of the boundary string found, the detection device must search for the first instance of two consecutive CRLF sequences following the found boundary. If found, the detection device must search for the next instance of the boundary string. If found, the detection device must calculate the number of characters between the beginning of the two consecutive CRLF sequences and the following boundary string. If the number of characters is less than 8, the traffic should be considered malicious; an attack exploiting this vulnerability is likely underway.

A sample malicious request, with 7 characters between beginning of the two consecutive CRLF sequences and the end boundary string, follows:

Note that the string matching must be performed in a case-sensitive manner

Conclusion

This bug has been patched by Apache with HTTP Server 2.4.52. They do not list any mitigating factors, so applying the update is the only method to fully address this vulnerability.

Special thanks to Guy Lederfein and Dusan Stevanovic of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-44790: Code Execution on Apache via an Integer Underflow

CVE-2021-45105: Denial of Service via Uncontrolled Recursion in Log4j StrSubstitutor

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein of the Trend Micro Research Team details a Denial-of-Service (DoS) bug discovered in Apache Log4j. This vulnerability should not be considered a variant of the bug known as “Log4Shell” (CVE-2021-44228), although it does abuse a similar attack vector. They are similar in that this bug also abuses attacker-controlled lookups in logged data. However, in this case, non-JNDI lookups can be abused. The following is a portion of his write-up covering the root cause CVE-2021-45105 with a few minimal modifications.


The Apache Log4j API supports variable substitution in lookups. However, a crafted variable can cause the application to crash due to uncontrolled recursive substitutions. An attacker with control over lookup commands (e.g., via the Thread Context Map) can craft a malicious lookup variable, which results in a Denial-of-Service (DoS) attack. This has been tested and confirmed on Log4j versions up to and including 2.16.0.

The Vulnerability

When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. However, when the nested variable references the variable being replaced, the recursion is called with the same string. This leads to an infinite recursion and a DoS condition on the server. As an example, if the Pattern Layout contains a Context Lookup of ${ctx.apiversion}, and its assigned value is ${${ctx.apiversion}}, the variable will be recursively substituted with itself.

The Code Flow

The StrSubstitutor.substitute() method is called with the variable to be substituted:

The StrSubstitutor.substitute() method is called with the original variable lookup (i.e., ctx.apiversion):

In this call to StrSubstitutor.substitute(), a call to StrSubstitutor. checkCyclicSubstitution() is made:

Note that the method StrSubstitutor. checkCyclicSubstitution() attempts to detect cyclic substitutions of variables by maintaining a priorVariables list and comparing the current variable to the list:

Later, the variable is resolved to its value (i.e., ${${ctx:apiversion}}) and a recursive call to StrSubstitutor.substitute() is made:

Once again, we detect the variable in the value being parsed. However, the recursive call to StrSubstitutor.substitute() does not include the priorVariables list. Therefore, the StrSubstitutor. checkCyclicSubstitution() method will fail to detect the cyclic substitution and an infinite recursion will occur:

Note too that even if the cyclic substitution is caught by StrSubstitutor. checkCyclicSubstitution(), the exception thrown will only be caught by AppenderControl.TryCallAppender(), resulting in a failed write to the log:

Patch Analysis

In version 2.17.0, two classes were created that inherit from StrSubstitutor: ConfigurationStrSubstitutor, which only parses string substitutions in configuration parameters, and RuntimeStrSubstitutor, which parses strings that may contain user-provided input. With RuntimeStrSubstitutor, no recursive evaluation is allowed. This is enforced by the StrSubstitutor.substitute() method:

In addition, all recursive calls to StrSubstitutor.substitute() maintain the list of priorVariables, allowing to catch cases of cyclic substitutions by the StrSubstitutor.isCyclicSubstitution() method:

Proof of Concept

For demonstration purposes, we created a typical vulnerable application named log4j-vulnerable-app.jar, compiled with log4j version 2.16.0. The application is configured with a custom Pattern Layout, which contains a Context Lookup (${ctx:apiversion}). The application implements an HTTP server and sets the received X-Api-Version header as the value of the apiversion variable in the Thread Context Map. Afterwards, it logs a message.

The vulnerable app can be run as follows on the target server:
          java -jar log4j-vulnerable-app.jar

The poc.py script can be run as follows:
          python poc.py client <host>

where is the host running the vulnerable application.

Upon running the script, an HTTP request with the X-Api-Version header set to a value of ${${ctx:apiversion}} will be sent to the vulnerable application. When attempting to log the message, the vulnerable application will crash with the following stack trace:

Conclusion

 A patch for this bug was released by Apache on December 18, 2021. While Apache does list mitigating factors, we recommend upgrading to the latest version to ensure this vulnerability is completely addressed. This component has received quite a bit of attention this week, so it would not be a surprise to see further bugs disclosed – with or without a patch.

Special thanks to Guy Lederfein of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-45105: Denial of Service via Uncontrolled Recursion in Log4j StrSubstitutor

❌
❌