In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Simon Humbert and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the XWiki free wiki software platform. This bug was originally discovered by Michael Hamann with public Proof-of-Concept (PoC) code provided by Manuel Leduc. Successful exploitation of this vulnerability would allow an authenticated attacker to perform an arbitrary code injection on affected systems. The following is a portion of their write-up covering CVE-2023-35150, with a few minimal modifications.

---

A code injection vulnerability has been reported in the XWiki.Org XWiki. The vulnerability is due to improper input validation when rendering a link in the Invitation Application.

A remote, authenticated attacker can exploit this vulnerability by sending crafted requests to the target server. Successful exploitation could result in arbitrary code injection.

The Vulnerability

XWiki is a second-generation wiki, which provides wiki functionality as well as an application development platform. XWiki offers the features expected from a wiki (such as powerful access rights and user management) and the possibility to create new applications on top of the platform. The XWiki interface can be accessed over HTTP on port 8080 by default.

XWiki includes a robust scripting feature set. Scripting allows users to create basic to complex web applications at the XWiki page (or view) layer without the need for compiling code or deploying software components. In other words, users can use scripting syntax in addition to wiki markup inside the content of an XWiki page. XWiki supports a variety of scripting languages including Velocity, Groovy, and Python enabled by default. XWiki implements the JSR-223 scripting platform to support the evaluation of script code. XWiki implements a script macro that evaluates script code and has the following form:

Script code for the default enabled languages can be declared directly with the language name as follows:

XWiki includes an “Invitation Application”. The “Invitation Application” is used to configure a wiki to send email notifications to users to request registration with the server. The user can then access a provided link to register with the server.

A code injection vulnerability has been reported in XWiki. The vulnerability is due to insufficient validation of user data rendered by the “Invitation Application”. Requests to the “Invitation Application” typically consist of many request parameters, with the action parameter used to determine what actions to take for the request. If the action parameter is not present the server will display a link to the “Invitation Application” based on the contents of the request-URI. However, the request-URI is not sanitized before rendering the link. An attacker could include script code in the request-URI that will then be evaluated when the link is rendered. An example of a malicious requestURI is shown below:

Source Code Walkthrough

The following code snippet was taken from XWiki version 14.10.3. Comments added by Trend Micro have been highlighted.

From xwiki-platform-core/xwiki-platform-invitation/xwiki-platform-invitation-ui/src/main/resources/Invitation/InvitationGuestActions.xml:

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following ports:
         -- HTTP, over port 8080/TCP
         -- HTTPS, over port 8443/TCP

Note that traffic may be SSL encrypted and should be decrypted before applying the following guidance. The detection device must monitor for HTTP requests to XWiki endpoints with a request-URI that contains the string:

         /xwiki/bin/view

If found, the detection device must look for a request parameter with the name sheet with a value of “Invitation.InvitationGuestActions” and a request parameter with the name xpage with a value of view. If found, the request-URI should be inspected for the characters {{ (or the URL encoded equivalent %7B%7B, case insensitive). If found, the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway.

Note that the string matching of the request-URI and parameter names should be performed in a case-insensitive manner.

Conclusion

This vulnerability has been addressed in XWiki versions 14.4.8, 14.10.4, and 15.0. In their announcement of the fix, the XWiki team also showed the steps to reproduce this bug, which essentially serves as a public PoC. No other mitigations are listed beyond upgrading to a fixed version, so it is recommended all XWiki users upgrade to a non-impacted version as soon as possible.

Special thanks to Simon Humbert and Lucas Miller 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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in Progress MOVEit Transfer. This bug was originally discovered by Trend Micro Vulnerability Researcher Guy Lederfein and is the same type of vulnerability being used by the Cl0p ransomware gang to exfiltrate data. A crafted request can trigger the execution of SQL queries composed from a user-supplied string. An attacker can leverage this vulnerability to execute code in the context of the “moveitsvc” user. The following is a portion of their write-up covering CVE-2023-36934, with a few minimal modifications.

---

An SQL injection vulnerability has been reported for Progress MOVEit Transfer. This vulnerability is due to insufficient validation of encrypted query parameters sent to the server. A remote, unauthenticated attacker could exploit this vulnerability by sending crafted requests to the target server.

A successful attack would result in arbitrary SQL command execution against the database on the target server, which can lead to arbitrary code execution under the security context of the running service.

The Vulnerability

MOVEit provides collaboration and automated file transfers of sensitive data and advanced workflow automation capabilities without the need for scripting. Encryption and activity tracking enable compliance with regulations such as PCI, HIPAA, and GDPR. MOVEit can be accessed via an API or a web interface accessed over HTTPS.

MOVEit supports the encryption of sensitive HTTP query parameters when generating redirection URLs. For example, if a request is made to the “/human.aspx” endpoint over plaintext HTTP, the user is redirected to the HTTPS endpoint. To generate the redirected URL, method MakeEncryptedURLIfNec() of class MOVEit.DMZ.ClassLib.SILGlobals will encrypt all HTTP query parameters in the original request and set the encrypted value in the ep HTTP query parameter of the new redirected URL. When this redirected request is read by the server, method GetEncryptedQueryParameters() of class MOVEit.DMZ.ClassLib.SILGlobals decrypts the ep HTTP query parameter, and the decrypted parameters are set to the server's global variables.

In addition, some redirects call method SaveArgumentsToSessionForRedirect() of class MOVEit.DMZ.ClassLib.SILGlobals to save the global variables to the current session. These variables are stored in the sessionvars SQL table. When another request is made to the server with the HTTP cookie ASP.NET_SessionId set to the same session ID, the global variables will be loaded in method LoadArgumentsFromSessionIfNeeded() by reading them from the sessionvars table.

An SQL injection vulnerability exists within MOVEit Transfer. This vulnerability is due to insufficient validation of encrypted query parameters sent to the server.

As mentioned above, if a request is made to the “/human.aspx” endpoint over plaintext HTTP, the server will redirect to the HTTPS endpoint with all HTTP query strings in the original request encrypted in the ep HTTP query parameter. This allows generating arbitrary encrypted query strings. When another request is made to the “/human.aspx” endpoint with the ep HTTP query parameter set to the encrypted query string returned by the server from the initial request, the value will be decrypted and read in method GetEncryptedQueryParameters(). If the decrypted string contains the query string username, its value will be sanitized using the method SILUtility.XHTMLClean(), and then URL-decoded using the method HttpUtility.UrlDecode(). Note that due to the order of these operations, if the value contains a URL-encoded quote character (%27), it will not be sanitized by SILUtility.XHTMLClean() and will be successfully decoded to a quote character ('). This improperly sanitized variable is written to the SILGlobals.LoginName variable. If this request also contains an InitialPage HTTP cookie with a value matching the regular expression “[a-z0-9]+\.aspx”, the SILGlobals.LoginName variable will be saved to the sessionvars table with a session ID generated by the server and returned in the response.

If a subsequent call is made to the “/machine.aspx” endpoint with the same session ID, the SILGlobals.LoginName variable will be loaded by method LoadArgumentsFromSessionIfNeeded(). Later, the method ProcessPreAuthXMLRequest() of class MOVEit.DMZ.WebApp.SILMachine will be called. In case the SILGlobals.Transaction variable is set to “passchangerequest”, the method UserProcessPassChangeRequest() of class MOVEit.DMZ.ClassLib.UserEngine will be called with the value of the SILGlobals.LoginName variable set as the MyLoginName argument. In this method, the MyLoginName argument is used when building an SQL Select query using the MOVEit.DMZ.ClassLib.SQLBasicBuilder class. Specifically, the argument is concatenated to the query using the AddAndToWhere() method, which does not perform any sanitization on the argument, leading to SQL injection.

A remote, unauthenticated attacker could exploit this vulnerability by sending crafted requests to the target server. Specifically, an initial request can be made to the “/human.aspx” endpoint with a crafted URL-encoded value in the username HTTP query string. Another request can be made to the “/human.aspx” endpoint with the encrypted query strings returned in the first response set in the ep HTTP query parameter, and a “.aspx” page set in the InitialPage HTTP cookie, leading to the crafted username value being decrypted, URL-decoded, saved to the SILGlobals.LoginName variable, and saved to the sessionvars table. Finally, a request can be made to the “/machine.aspx” endpoint with the same session ID returned by the second response. This will lead to the crafted value being loaded from the sessionvars table and used in the vulnerable SQL query.

A successful attack would result in arbitrary SQL command execution against the database on the target server. This would allow an attacker to inject a session into the activesessions SQL table, allowing the attacker to authenticate as an arbitrary user. In addition, an arbitrary value may be set in the state field of the fileuploadinfo SQL table, which is decrypted and deserialized using BinaryFormatter. Setting this field to a crafted encrypted value would lead to insecure deserialization, which can lead to arbitrary code execution under the security context of the running service.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the ports used by MOVEit Transfer.

Note that traffic may be SSL/TLS encrypted and must be decrypted before applying the following guidance.

The detection device must monitor for HTTP requests to the MOVEit Transfer endpoint “/human.aspx”. If found, the detection device must parse the HTTP query parameters from the following URIs:

       -- Request-URI of the HTTP request
       -- An InitialPage HTTP cookie value (only applicable if the value matches the regular expression “[a-z0-9]+\.aspx”)

After parsing the query parameters from both sources, the detection device must search for the “username” query parameter name. If found, and the value of the query parameter contains a URL-encoded single quote character (%27), the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway.

Please also note the string matching of the “username” query parameter name, the “human.aspx” endpoint, and the “InitialPage” cookie name should be done in a case-insensitive manner.

Conclusion

Progress patched this vulnerability along with two others in early July 2023. As of now, we have not seen any evidence this bug is being used in active attacks. However, similar bugs have been used by ransomware gangs to exfiltrate data from targets. Progress offers no other mitigations other than applying the update. It is recommended that all MOVEit users test and deploy the patch as soon as possible.

Special thanks to Guy Lederfein and Lucas Miller 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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Jonathan Lein and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in VMware Aria Operations for Logs (formerly vRealize). This bug was originally submitted to the ZDI program by an anonymous researcher. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of root. Similar bugs are reported as being exploited in the wild. The following is a portion of their write-up covering CVE-2023-20864, with a few minimal modifications.

---

An insecure deserialization vulnerability has been reported in VMware Aria Operations for Logs. The vulnerability is due to improper validation of user data in the InternalClusterController class. A remote unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation could result in arbitrary code execution under the security context of the root user.

The Vulnerability

VMware Aria Operations for Logs is a log management solution, formerly developed under the name vRealize Log Insight. It can be used to collect log files from remote machines to a central server for storage and processing. Administrators can then access a web-based user interface to create dashboards to visualize the data, create reports, and manage the log data. In addition to the web user interface, the application contains an API to manage the server. The API is accessible on port 9000/TCP through HTTP, or port 9543/TCP via HTTPS.

Aria Operations for Logs can be run as a stand-alone appliance running on a single node, or multiple instances can be configured together to run in a cluster. The APIs impacted by this vulnerability are designed to be used between two instances of Aria Operations for Logs during setup to add the application to the cluster. The API “applyMembership” is used by a server to send a request to join a cluster. If the primary server accepts the request to join the cluster, it will use the API “approveMembership” to send configuration data to the server needed to join the cluster, and the API “setToken” to send a token to apply to the server. The HTTP POST request body for each API call will contain a serialized Java object containing data to pass to the API. Each serialized object will have a different class, depending on which API it was sent to. Java allows the serialization of objects, enabling them to be represented as a compact and portable byte stream. This byte stream can then be transferred via the network and deserialized for use by the corresponding servlet or applet. The following example illustrates how a class is serialized and then later extracted:

All Java Objects that are serializable implement the Serializable interface. This interface enforces the writeObject() and readObject() methods, which are called when serializing and deserializing objects respectively. These methods can be modified to implement custom behavior during the serialization and deserialization of Java Objects. A serialized Java object begins with the following structure:

An insecure deserialization vulnerability has been reported in VMware Aria Operations for Logs. The vulnerability is due to improper validation of user data in multiple methods in the InternalClusterController class. Aria Operation for Logs defines three API functions in the file “routes” to assist in the management of clusters: “applyMembership”, “setToken”, and “approveMembership”. When the server receives a call to any of these APIs, a method corresponding to the API name will be called in the class InternalClusterController. Regardless of the API used, the method will first pass the body of the HTTP request to the method SerializationUtils.deserialize() as a byte array. The deserialize() method will then convert the byte array to a ByteArrayInputStream object and then pass it to deserialize() again. The method will then convert the user data to an ObjectInputStream object and call readObject() on it to deserialize it. After the user data has been deserialized, it will be passed to another method to finish handling the user’s request to the API. However, the serialized objects in the body of requests to the APIs are not validated before they are deserialized. A remote, unauthenticated attacker could exploit this vulnerability by sending an API request containing a crafted serialized object. Such a crafted object can be created with the ysoserial tool using the “CommonsBeanutils1” gadget chain. Successful exploitation could result in arbitrary code execution under the security context of the root user.

Source Code Walkthrough

The following code snippet was taken from VMware Aria Operation for Logs version 8.10.2. Comments have been added by Trend Micro researchers.

From /usr/lib/loginsight/application/lib/api-play-service_2.13-1.0.jar!routes:

From decompiled Java class /usr/lib/loginsight/application/lib/api-play-service_2.13-1.0.jar!controllers/InternalClusterController.class:

From decompiled Java class /usr/lib/loginsight/application/lib/lib/commons-lang3.jar!org/apache/commons/lang3/SerializationUtils.class:

From decompiled Java class /usr/lib/loginsight/application/lib/lib/commons-lang3-3.1.jar!org/apache/commons/lang3/SerializationUtils.class:

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on TCP ports 9000 and 9543. Note that traffic may be encrypted and will need to be decrypted prior to applying this detection guidance. The detection device must parse Java serialized objects in HTTP requests. Java allows the serialization of objects, enabling them to be represented as a compact and portable byte stream. This byte stream can then be transferred via the network and deserialized for use by the corresponding servlet or applet. A serialized Java object begins with the structure shown above.

The detection device must inspect incoming HTTP POST requests to the following URIs:

If found, the detection device must inspect the request body for a Java serialized object. The detection device can inspect the request for the magic bytes “\xac\xed” followed by a 2-byte stream version “\x00\x05” to find a serialized object. The detection device must then inspect the serialized object beginning at offset 0x04 and look for the following bytes, corresponding to TC_OBJECT, TC_CLASSDESC, and then the length of the Class Name, immediately followed by a Class Name depending on which API endpoint the request to going to:

If the Class Name in the serialized object in the request does not match the expected Class Name, the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway. Note that it is possible the expected class name for each API could change in future versions of the software.

Conclusion

VMware patched this bug in April with VMSA-2023-0007. To date, we have not seen any evidence this bug is being used in active attacks. However, similar bugs have reportedly been detected in the wild. It is recommended that Aria users test and deploy this update quickly.

Special thanks to Jonathan Lein 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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Quinton Crist, Guy Lederfein, and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Network File Service (NFS). This bug was originally discovered by Wei in Kunlun Lab with Cyber KunLun. The vulnerability is triggered when handling incoming NFSv4.1 calls containing utf8strings when the server is low on memory. A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted call to an affected server. The following is a portion of their write-up covering CVE-2023-24941, with a few minimal modifications.

---

A remote code execution vulnerability has been reported in Microsoft Network File System (NFS). The vulnerability is triggered when handling incoming NFSv4.1 calls.

The Vulnerability

Microsoft Windows ships with several network features, some of which can be used to communicate with non-Windows file shares. One of these modules is NFS.

Network File System (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 RFC 3530 (released April 2003). 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, it 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.

In the NFS4 protocol, a utf8string is transferred in the following format:

A remote codes execution vulnerability has been reported in Microsoft Network File System. The vulnerability is triggered when handling incoming NFSv4.1 calls containing utf8strings when the server is low on memory. When a server is parsing a received string, a buffer is allocated to store the string data. The code does not properly handle the allocation failing, resulting in the null termination byte still being written to the end of an invalid buffer.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted call to the victim Network File System service. Successful exploitation of this vulnerability can result in remote code execution.

Source Code Walkthrough

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

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on ports 2049/TCP and 2049/UDP.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the table above) 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. The vulnerable method XdrDecodeString can only trigger this vulnerability when called from Nfs4SvrXdrpDecode_STRING.

The following fields are parsed using Nfs4SvrXdrpDecode_STRING and are defined in RFC 3530:

The detection device should monitor the above fields in all NFS4 messages. Any valid field value could trigger this vulnerability, but an attacker would request a large buffer to increase the probability of the failed allocation happening during the string processing. String lengths greater than 0x1000 should be considered suspicious. If found, an attack exploiting this vulnerability is likely underway.

Note that the detection of strings larger than 0x1000 is based on the typical allowed limit of file path strings and can be adjusted higher or lower to account for various server configurations.

Conclusion

Microsoft patched this bug in May as CVE-2023-24941. In their write-up, they note that disabling NFSv4.1 and downgrading to NFSv2 or NFSv3 can be used as a temporary mitigation for this vulnerability. However, they also note that you should not employ this mitigation unless you have already installed CVE-2022-26937 from the May 2022 Windows security updates. The better option is to test and deploy the latest patch for NFSv1 to completely address this vulnerability.

Special thanks to Quinton Crist, Guy Lederfein, and Lucas Miller 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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Windows DHCPv6 Service. This bug was originally discovered by YanZiShuang@BigCJTeam of cyberkl. The vulnerability results from the improper processing of DHCPv6 Relay-forward messages. A network-adjacent attacker can leverage this vulnerability to execute code in the context of the DHCP service. The following is a portion of their write-up covering CVE-2023-28231, with a few minimal modifications.

---

A heap-based buffer overflow has been reported in Microsoft DHCPv6 Server. The vulnerability is due to improper processing of DHCPv6 Relay-forward messages. A remote attacker can exploit this vulnerability by sending crafted DHCPv6 Relay-forward messages to the target server. Successful exploitation could result in the execution of arbitrary code with administrative privileges.

The DHCPv6 Protocol

The Dynamic Host Configuration Protocol (DHCP) protocol is used to centrally manage and automate the assignment of IP addresses on a network. DHCPv6 is the Dynamic Host Configuration Protocol for IPv6. Although IPv6's stateless address auto-configuration can also be used to acquire an IPv6 address, DHCPv6 may be a more suitable solution to assign addresses, name servers and other configuration information that are configured with DHCP for IPv4.

DHCPv6 uses UDP on ports 547 and 546 for communication. The DHCPv6 protocol is described in RFC 8415. A typical DHCPv6 transaction consists of several DHCPv6 messages exchanged between the client and the server:

Briefly, the way DHCPv6 work is as follows: before a client obtains an IPv6 address, it sends a Solicit message to the link-scoped multicast address to find a DHCPv6 server. For the DHCPv6 protocol, the value of the link- scoped multicast address is "FF02::1:2". Any DHCPv6 server on the local network may respond with an Advertise message. If the client selects the DHCPv6 server, it sends a Request message to get an IPv6 address and other configuration information. The server responds with a Reply message containing the IPv6 address and other configuration.

The general structure of DHCPv6 messages between clients and servers is shown below:

The msg-type field is DHCPv6 message identifier. The value of the msg-type field for Solicit, Advertise, Request, Renew, and Reply messages are 1, 2, 3, 5, and 7, respectively. The options field of a DHCPv6 message contains a sequence of option fields.

The general structure of an option field is as follows:

To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client's link will relay messages between the client and server. This relay agent acts as an intermediary to deliver DHCP messages between clients and servers. In certain configurations, there may be more than one relay agent between clients and servers, so a relay agent may send DHCP messages to another relay agent.

The general structure of messages between a relay agent and other relay agents and servers is shown below:

This format is shared by the two relay agent messages: Relay-forward and Relay-reply. Specifically, for Relay-forward messages, the msg-type field is set to RELAY-FORW (12) and the options field must include a Relay Message option. The Relay Message option has its option-code field set to OPTION_RELAY_MSG (9), and its option-data contains the received message.

The Vulnerability

A heap-based buffer overflow has been reported in Microsoft DHCPv6 Server. The vulnerability is due to improper processing of DHCPv6 Relay-forward messages. The DHCPv6 server runs as a svchost.exe service and follows the DHCPv6 protocol to supply IPv6 addresses for the network devices on the system. When the server receives a Relay-forward message, it is processed by the function ProcessRelayForwardMessage() within dhcpssvc.dll. This function initializes a 1664-byte heap buffer, which is an array of 32 structures of size 52 bytes for each nested Relay- forward message encountered. The function also initializes a counter used to count the number of nested Relay- forward messages encountered. While processing the outer Relay-forward message, each time a nested Relay- forward message is encountered within a Relay Message option, the array of structures is filled at the appropriate offset and the counter is incremented. However, no validation is done to ensure that the counter does not exceed the maximum expected number of hops, 32. Therefore, if more than 32 nested Relay-forward messages are included in a Relay-forward message, the function will write to an offset exceeding the size of the allocated buffer, resulting in a buffer overflow.

A remote attacker can exploit this vulnerability by sending crafted DHCPv6 Relay-forward messages containing more than 32 nested Relay-forward messages to the target server. Successful exploitation could result in the execution of arbitrary code. Since the service runs as NETWORK SERVICE, after a compromise, an attacker could escalate to SYSTEM.

Source Code Walkthrough

The following code snippet was taken from dhcpssvc.dll version 10.0.17763.3469. Comments added by Trend Micro have been highlighted.

From function ProcessRelayForwardMessage():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on UDP ports 546 and 547 and be capable of inspecting DHCPv6 packets on UDP port 547.

The general structure of DHCPv6 messages between clients and servers and the general structure of an option field is shown above. The general structure of messages between a relay agent and other relay agents and servers is also shown above.

If a DHCPv6 Relay-forward message is found, meaning the value of its msg-type field is 12, the detection device must iterate through each option present in the options field. For each option, if the option is of type Relay Message, meaning the value of its option-code field is 9, the detection device must parse its option-data field as a new message. If the total number of Relay-forward messages encountered is greater than 32, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Note that all multi-byte values are in network byte order.

Conclusion

Microsoft addressed this vulnerability in April 2023 and assigned the vulnerability CVE-2023-28231. While they state that exploitation is unlikely, we do have working Proof-of-Concept (PoC) code available. Microsoft provides no other workaround apart from applying the available fix. This is the only suggested action to address the vulnerability. While DHCP is not a routable protocol, it is still recommended to apply the update once tested.

Special thanks to Guy Lederfein and Lucas Miller 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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Justin Hong and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the SolarWinds Network Performance Monitor. This bug was originally discovered and reported by ZDI Vulnerability Research Piotr Bazydło. The vulnerability results from the lack of proper validation of user-supplied data, which can result in the deserialization of untrusted data. An authenticated attacker can leverage this vulnerability to execute code in the context of SYSTEM. The following is a portion of their write-up covering CVE-2022-38108, with a few minimal modifications.

---

An insecure deserialization vulnerability has been reported in SolarWinds Network Performance Monitor. The vulnerability is due to insufficient validation of user-supplied data in the BytesToMessage function. A remote, authenticated attacker could exploit the vulnerability by sending crafted requests to an affected server. Successful exploitation can result in arbitrary code execution under the security context of SYSTEM. This vulnerability has been patched by SolarWinds and assigned CVE-2022-38108.

The Vulnerability

The SolarWinds Orion Platform is the base platform used by numerous SolarWinds products. The platform is designed to seamlessly integrate all Orion-based products into a single interface. Network Performance Monitor (NPM) is one of these SolarWinds products and is used to monitor multi-vendor network devices and servers.

The SolarWinds Orion platform adapts RabbitMQ, an open-source message broker, to send and receive messages between various software components and agents. RabbitMQ supports Advanced Message Queuing Protocol version 0-9-1 (AMQP 0-9-1), which is used by the SolarWinds platform. The SolarWinds Information Service (SWIS) is one of the modules that uses RabbitMQ to communicate with other services in the SolarWinds Orion Platform.

To send a message to SWIS, a sender can place message content in AMQP frames with the routing-key set to “SwisPubSub” and send these frames to RabbitMQ via TCP port 5671. The details of AMQP 0-9-1 frame format will be described in the detection section below.

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 comprises of zero or more items delimited by a comma (",") character.
— An item comprises 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. Valid types include string, number, JSON object, array, boolean or nul
— An array is an object enclosed in square braces [].
— An array comprises of zero or more string, number, JSON object, array, boolean or null type-objects delimited by a comma (",") character.

An example JSON object is as follows:  

         {"name":"bob", "age":30}

An insecure deserialization vulnerability exists in SolarWinds NPM. The message content sent to SWIS via RabbitMQ contains Json.NET serialized objects. When receiving the message content, the DeserializeMessage() method of the .NET class EasyNetQ.DefaultMessageSerializationStrategy is called to process the message content. The method will call the BytesToMessage() method of the .NET class SolarWinds.MessageBus.RabbitMQ.EasyNetQSerializer to deserialize the message content. BytesToMessage() will call the DeserializeObject() method of the .NET class SolarWinds.Newtonsoft.Json.JsonConvert, which will eventually call the Deserialize() method of the .NET class SolarWinds.Newtonsoft.Json.Serialization.JsonSerializerInternalReader to deserialize the Json.NET serialized object.

However, all the methods mentioned above have no proper validation of the message content to see if the given object type is safe to be deserialized. Although SolarWinds already has a .NET class BlackListBinder that checks a given object type against suspicious type names, the SWIS application does not utilize BlackListBinder when processing message content from RabbitMQ. An attacker can send a message to the SWIS application via RabbitMQ and the message content contains a malicious Json.NET serialized object derived from known Json.NET deserialization gadgets from YsoSerial.Net and trigger arbitrary code execution on the server.

A remote attacker who has the credentials to access the RabbitMQ message broker could exploit the vulnerability by sending crafted messages to the target application via RabbitMQ. Successful exploitation can result in arbitrary code execution under the security context of SYSTEM.

Source Code Walkthrough

The following code snippet was taken from SolarWinds NPM version 2020.2.6. Comments added by Trend Micro have been highlighted.

In decompiled .NET class EasyNetQ.DefaultMessageSerializationStrategy:

In decompiled .NET class SolarWinds.MessageBus.RabbitMQ.EasyNetQSerializer:

In decompiled .NET class SolarWinds.Newtonsoft.Json.Serialization.JsonSerializerInternalReader:

Exploit Detection

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on TCP port 5671. Note that traffic is encrypted via SSL/TLS and should be decrypted before performing the following steps.

The detection device must first determine if the client is attempting to initiate an AMQP 0-9-1 connection by looking for the protocol header as the format shown below:

If such an AMQP protocol header is found, the detection device must continue to monitor the traffic and look for AMQP 0-9-1 frames.

AMQP 0-9-1 frames

AMQP 0-9-1 frames carry protocol methods, message content, and other information. All frames have the same general format: frame header, payload, and frame end. The frame end is represented by the byte value \xCE. The general frame format is shown as below:

There are four frame types in AMQP 0-9-1: Method, Content header, Content body, and Heartbeat frames. Each frame type has its own frame payload format. The payload format of Method, Content header, and Content body frame are related to this report and will be described in the following paragraphs. Note that, in the following paragraphs, the "Offset" value is relative to the beginning of the frame payload (offset 0x07 in the general frame format shown above).

 The payload format of the Method frame is as shown below:

The Method Arguments List field, depending on its Method id, can contain zero or more data values of various data types. Each data type is represented in its own specification. The data types include integer, bits, string, timestamp, and field table (key/value pair). The details of each data representation will not be described in this report.

The payload format of the Content header frame is as shown below:

The user data that a sender wants to send to the receiver can be carried in one or more Content body frames following the Content header frame. That is, the user data can be split into several Content body frames. The Body size field of the Content header frame is to record the total size of the original user data (before being split) sent by the sender.

The payload format of the Content body frame is as shown below:

The Binary content field carries the whole (if not split) or a part of user data that the sender wants to send to the receiver.

The detection device must first look for the Method frame which contains the routing-key “SwisPubSub”. To do this, the detection device must check each frame to see if its frame type is \x01 and Class id is \x3c (Basic class) and Method id is \x28 (Publish) and its Method Argument List field contains the string “SwisPubSub”. If such a frame is found, the detection device must continue to look for the Content body frame and inspect its Binary content field as JSON-format data to see if it contains a malicious serialized object. Note that the JSON-format data could be split into multiple Content body frames and the detection device must be able to assemble all Binary content fields together from these Content body frames before inspecting it.

The JSON-format data must be inspected using any suitable parsing method below:

Method 1 - The detection device can parse JSON

The detection device must search for the “$type” key and check if its value begins with any of the following strings:

If found, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway.

Using the class names (like “System.Windows.Data.ObjectDataProvider”) as the indication of the exploitation of this vulnerability is based on the observation that this insecure deserialization vulnerability relies on the use YsoSerial.Net gadget that works with Json.NET, and also based on the fix from the SolarWinds NPM program update, which uses a deny-list method to verify the type of the serialized object.

Method 2 - String-based detection

The detection device must check if the JSON-format data contains a string that can be matched with the regular expression as below:

If found, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway. Below is an example of a malicious serialized object in JSON-format:

Note that all string matching should be performed in a case-insensitive manner.

Conclusion

SolarWinds addressed this vulnerability with the release of SolarWinds Platform version 2022.4 RC1 and later. In addition to installing the updated version, enterprises can also protect themselves by blocking the affected ports from external network access if they are not required. The vendor also recommends applying proper segmentation controls on the network where you have deployed the SolarWinds Platform and SQL Server instances. This should also be considered a best practice and a part of a robust defense-in-depth strategy. They also recommend that customers follow the guidance provided in the SolarWinds Secure Configuration Guide. Finally, ensure only authorized users can access the SolarWinds Platform. 

Special thanks to Justin Hong and Lucas Miller 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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Lucas Miller and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in Adobe ColdFusion. This bug was originally reported to the ZDI program by a researcher known as rgod. The vulnerability is due to the lack of proper validation of user-supplied data, which can result in a memory corruption condition. Successful exploitation could lead to arbitrary code execution at the level of SYSTEM. The following is a portion of their write-up covering CVE-2022-35690, with a few minimal modifications.

---

A memory corruption vulnerability exists in Adobe ColdFusion. This vulnerability is due to the lack of proper validation of user-supplied data, which can result in a memory corruption condition. Adobe addressed this bug with a patch released in October 2022.

A remote, unauthenticated attacker could exploit this vulnerability by sending a maliciously crafted request to a target service. The vendor lists the base CVSS at 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). In the worst case, successful exploitation could result in arbitrary code execution with privileges of SYSTEM.

The Vulnerability

Adobe ColdFusion is an application development platform by Adobe Systems. It is an IDE used to develop web applications and supports a full scripting language, ColdFusion Markup Language (CFML). Since ColdFusion MX 6.0, the server component runs within a Java Runtime Environment (JRE).

The ColdFusion Administrator organizes information about all ColdFusion server database connections in a single location. ColdFusion provides a number of supplied drivers for connecting to variable databases including Apache Derby Client, DB2, Microsoft Access, Microsoft SQL Server, MySQL, ODBC Socket, Oracle, and Sybase. The ODBC Socket driver is the data source relevant to the understanding of this vulnerability.

When a user configures data sources for an ODBC Socket, a packet is sent to the ODBC server and ODBC agent. The ODBC agent listens on port 20009/TCP. The agent communicates with the client using the GIOP protocol (version 1.1). General Inter-ORB Protocol (GIOP) is the abstract protocol by which object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG). IIOP (Internet Inter-ORB Protocol) is the implementation of GIOP for TCP/IP. It is a concrete implementation of the abstract GIOP definitions.

A Request message allows a client application to invoke an operation on a remote server. A GIOP Request message begins with a GIOP message header, followed by a Request header and Request body.

A GIOP message header (version 1.1) has the following format, defined in OMG IDL:

If the Message Type is set to 0, the request message follows the GIOP message header. The request message header is specified as follows:

All multi-byte values are in big-endian order.

Note that the ODBC Agent in Adobe ColdFusion does not fully follow the specification of the request header as documented here. The above structure was determined by reverse engineering the ODBC Agent executable swagent.exe. For instance, the fields ServiceContext and Principal are assumed to be set to 0, otherwise, the code stops processing the request GIOP packet and exits.

In GIOP version 1.1, request bodies are marshaled into the Common Data Representation (CDR) encapsulation of the containing Message immediately following the Request header. Different requests do not share a generic request body structure.

It has been observed that one ODBC Agent GIOP request message may contain multiple opcode and opcode-specific data. The specification of these messages is not documented; however, Trend Micro Security Research has determined the following structure of the request body:

The structure of the body of the message is as follows:

All multi-byte values are in big-endian byte order. Note that if the value of the Size field is 0, then field Unknown2 is not present in the structure.

There can be several opcodes in the Opcodes structure. The opcodes are processed in a loop that stops when the number of bytes processed in Opcodes is greater than 0x3b or if opcode 9 is encountered.

The general structure of each opcode is as follows:

The size of the Opcode related data field, shown as Y, will be dependent on the value of the Opcode field. If the Opcode field is set to 2 or 5, then Y will be 2. If the Opcode field is set to 3, then Y will be 3. If the Opcode field is set to 4, then Y will be 9.

The structure of opcodes 7 and 8 is as follows:

In the case an invalid Opcode is provided, that is, if the value of Opcode field is less than 2, greater than 9, or equal to 6, then it is handled as follows. If this is the first opcode processed in the loop, then the rest of the data is not processed. Otherwise, this invalid opcode is processed by skipping 1 byte in the case the previous opcode was 7 or 8, 2 bytes in the case the previous opcode was 5 or 2, 3 bytes in the case the previous opcode was 3 and 9 bytes in the case the previous opcode was 4. Note that if another/second unknown opcode is encountered then the number of skipped bytes remains the same as in the previous iteration of the loop.

A heap-based and stack-based buffer overflow vulnerability exists in Adobe ColdFusion ODBC Agent component. When the component receives the GIOP packet, it first calls the function swagent.exe+0x92700() to check that Magic Bytes is set to "GIOP". Next, function swagent.exe+0x91cb0() is called, which checks if ServiceContext and Principal fields are set to 0. This function also checks that Object Key is set to "IIOP:slx::" and Operation is set to "SSP". Next, function swagent.exe+0x95560() is called, which checks the Unknown3 field in the request body. Then the opcodes are processed, one at a time, in a loop in the function swagent.exe+0x92fa0(). In this loop, the vulnerable opcodes 7 and 8 will be examined. If opcode 8 is encountered, the C library function memmove() will be called, using the OpcodeDataSize field as the size parameter, to copy the bytes in the Data field to a heap buffer. By supplying an OpcodeDataSize value larger than 38, the vulnerable heap-buffer will be overrun.

Also, if the opcode 7 is encountered, the C library function memmove() will be called using the OpcodeDataSize field as the size parameter to copy the bytes in the Data field to a heap buffer. Later, in the function swagent.exe +0x96d20(), another memmove() call is made, copying the bytes from the previously-mentioned heap buffer into a fixed-sized stack buffer. By supplying an OpcodeDataSize value larger than 22, the vulnerable stack-buffer will be overrun. By sending a crafted GIOP request message, a remote unauthenticated attacker can exploit this vulnerability to execute arbitrary code under the security context of the SYSTEM user. An unsuccessful attack would crash the targeted process, causing a denial of service condition.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on port 20009/TCP. The detection device must detect the GIOP messages. A GIOP Request message begins with a GIOP message header, followed by a Request header and Request body. The format for these messages is listed above.

As mentioned above, the ODBC Agent in Adobe ColdFusion does not fully follow the specification of the request header as documented. The structure listed above was determined by reverse engineering the ODBC Agent executable swagent.exe. For instance, the fields ServiceContext and Principal are assumed to be set to 0, otherwise, the code stops processing the request GIOP packet and exits.

In GIOP version 1.1, request bodies are marshaled into the Common Data Representation (CDR) encapsulation of the containing Message immediately following the Request header. Different requests do not share a generic request body structure. It has been observed that one ODBC Agent GIOP request message may contain multiple opcode and opcode-specific data. The format of these messages and opcodes are detailed above.

In the case an invalid Opcode is provided, that is, the value of Opcode field is less than 2, or greater than 9 or it is equal to 6 then it is handled as follows. If this is the first opcode processed in the loop then the rest of the data is not processed. Otherwise, this invalid opcode is processed by skipping 1 byte in the case the previous opcode was 7 or 8, 2 bytes in the case the previous opcode was 5 or 2, 3 bytes in the case the previous opcode was 3 and 9 bytes in the case the previous opcode was 4. Note that if another/second unknown opcode is encountered then the number of skipped bytes remains the same from the previous iteration of the loop.

The detection device must first check that Magic Bytes field is set to “GIOP” and check that Message Type field is set to 0 (indicating Request message). The detection device should also ensure that ServiceContext and Principal fields are set to 0. Next, the detection device must check that the Object Key field is set to “IIOP:slx::” and that the Operation field is set to "SSP\x00". Next, the detection device must examine the request body and parse it as documented above.

The detection device must parse the Opcodes by following the structure described above and look for all Opcode 7 and Opcode 8 structures before the number of bytes processed is less than or equal to the value in the 0x3b or before opcode 9 is encountered. While parsing the Opcodes fields, the detection device must keep track of the number of bytes processed and it must stop processing the Opcodes field once 0x3b bytes of data are examined in this field. If the OpcodeDataSize field of Opcode 7 is larger than 22 or OpcodeDataSize field of Opcode 8 is larger than 38 or if the value in the OpcodeDataSize field is greater than the remaining number of bytes to be processed in the Opcodes (i.e., if the OpcodeDataSize > 0x3b - number of bytes processed so far in the Opcodes field), the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway.

Conclusion

Adobe patched this vulnerability in October 2022 with APSB22-44. They also recommend updating the ColdFusion JDK/JRE to the latest version of the LTS releases for JDK 11. Applying the ColdFusion update without a corresponding JDK update will NOT secure the server. They also recommend those running ColdFusion apply the settings listed on the ColdFusion Security page and apply the recommendations in the ColdFusion 2018 or 2021 lockdown guide.

Special thanks to Lucas Miller 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.

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.

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.

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.