Normal view

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

CVE-2023-36049: Microsoft .NET CRLF Injection Arbitrary File Write/Deletion Vulnerability

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Justin Hung and Yazhi Wang of the Trend Micro Research Team detail a recently patched privilege escalation vulnerability in .NET Framework and Visual Studio. This bug was originally discovered by Piotr Bazydło of Trend Micro’s Zero Day Initiative (ZDI). Successful exploitation of this vulnerability would allow a remote attacker to write or delete files in the context of the FTP server. The following is a portion of their write-up covering CVE-2023-36049, with a few minimal modifications.


A remote command execution vulnerability has been reported in the Microsoft .NET Framework and Visual Studio. This vulnerability is due to improper validation of user input. An attacker could exploit this vulnerability by sending malicious requests to the FTP servers. Successful exploitation could allow the attacker to write or delete files in the context of the FTP server.

The Vulnerability

The .NET Framework is a software framework for Microsoft Windows that provides development and execution tools for software applications. Applications written for the .NET Framework are executed in the Common Language Runtime (CLR) environment. The CLR takes .NET applications as Common Intermediate Language (CIL) object code and uses a just-in-time (JIT) compiler to compile the CIL object code to native code for the target platform.

FTP is the File Transfer Protocol described in RFC 959 and other RFCs. FTP uses two separate TCP connections - one for control and another for data transfer. A connection to the listening port from the FTP client forms the control stream on which FTP service commands are passed from the FTP client to the FTP server and on occasion from the FTP server to the FTP client. FTP service commands are used for authentication, file transfer, file system functions, etc. FTP commands have the following syntax:

         <command> <SP> [parameters] <CRLF>

where is the string of the command name, and [parameters] are optional or multiple depending on the command. represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and represents a space character that splits the command and parameters or parameters themselves. The following is an example of an RETR command, which is used to begin the transmission of a file from the remote host.

         RETR remote-filename

A separate TCP connection is used for the transfer of data when a command, such as STOR, RETR, LIST, and so on, is received. Information, such as command results, the content of the transferred file, and so on are exchanged via this data stream connection. This data stream connection can be initiated by the client or the server. The client can issue the PASV command to request the FTP server to open an ephemeral port to wait for connections from the client. If the client wishes to wait for connections from the server instead, a PORT command is issued.

A command injection vulnerability exists in Microsoft .NET Framework. The vulnerability is due to insufficient validation of FTP command parameters and FTP URI requests. More specifically, the .NET Framework implements a class FtpControlStream to handle basic FTP control connections. In the implementation, it calls an internal function FormatFtpCommand() to form a valid FTP command with command and parameters as arguments. However, when the vulnerable function handles the FTP parameters, it fails to validate if the parameters include CRLF characters. It will form the following FTP commands when the command is "RETR" and the parameter is "onefile<CRLF>DELE otherfile\<CRLF>":

Similarly, another internal function FtpWebRequest() fails to validate if the URI argument contains or not. A malicious FTP URI could make the vulnerable function send malicious FTP command after the FTP connection established.

The attack vector depends on how the vulnerable .NET functions are used in the FTP applications. An attacker could exploit this vulnerability by sending malicious requests to the FTP server. Successful exploitation could allow the attacker to write or delete files in the context of the FTP server.

Source Code Walkthrough

The following code snippet was taken from .NET commit 0ed0438152b25a8a19bcc87eb335fa8a089ac8db. Comments added by Trend Micro have been highlighted.

In src/libraries/System.Net.Requests/src/System/Net/FtpControlStream.cs:

In src/libraries/System.Net.Requests/src/System/Net/FtpWebRequest.cs:

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse all FTP traffic, which is on TCP port 21 by default.

The detection device must inspect if there are multiple FTP commands (multiple CRLF) sent in one packet. If found, the traffic should be considered suspicious, and an attack exploiting this vulnerability is likely underway.

Note that since most FTP servers accept multiple FTP commands in one packet, there might be false positives using this detection guidance in normal FTP traffic.

Conclusion

Microsoft addressed this vulnerability by releasing a patch in November, however, it has been revised multiple times. The most notable revision adds PowerShell versions 7.2, 7.3, and 7.4 as affected platforms. If you are unable to apply the patch, you can prevent exploitation by refusing to accept FTP URIs from untrusted peers or otherwise filtering FTP traffic. Still, it is recommended to apply the vendor fix to fully resolve this vulnerability.

Special thanks to Justin Hung and Yazhi Wang 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-2023-46263: Ivanti Avalanche Arbitrary File Upload Vulnerability

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 the Ivanti Avalanche enterprise mobility management program. Other Ivanti products have recently been under active exploitation, and the mobile device management system is an attractive target. This bug was originally reported to the ZDI program by an anonymous researcher and was also discovered by Lucas Miller of Trend Micro Research. Successful exploitation of this vulnerability would allow an authenticated attacker to execute code in the context of SYSTEM. The following is a portion of their write-up covering CVE-2023-46263, with a few minimal modifications.


An arbitrary file upload vulnerability has been reported for Ivanti Avalanche. This vulnerability is due to improper input validation in the FileStoreConfig app.

A remote, authenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successfully exploring this vulnerability could result in remote code execution as SYSTEM.

The Vulnerability

Ivanti Avalanche is a mobile device management system. The Central FileStore and the Central File Server in Avalanche are used to store and distribute files that are associated with payloads for mobile device configuration. For example, .apk files or OS update files could be stored in the Central FileStore. The Central FileStore is relevant to understanding this vulnerability.

The Avalanche web interface can be accessed over HTTP on TCP port 8080 as follows:

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). 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:

A corresponding HTTP 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:

Avalanche allows users to change the location where the Central FileStore saves files by changing the FileStore path through the web interface. To change the FileStore path a request to AvalancheWeb/app/ FileStoreConfig.jsf is made and the request is handled by the com.wavelink.amc.web.view.FileStoreConfigBean class. The request includes a txtUncPath request parameter that contains the new path to store files. Before saving the new values the validateFileStoreUncPath method is called to verify the new path is allowed. The path is checked against a deny list of disallowed values and for directory traversal characters. If the path passes the checks the new path is saved. Future uploads to the FileStore will be stored in the new location.

An arbitrary file upload vulnerability exists in the Central FileStore. The vulnerability is due to insufficient sanitization of the txtUncPath field in the Central FileStore configuration settings. The validateFileStoreUncPath attempts to prevent the new path from containing the webroot folders for Avalanche servers in the path. However, the validateFileStoreUncPath method does not prevent the use of the parent folder of the RemoteControl server webroot folder at: “C:\ProgramData\Wavelink\Avalanche\RemoteControlServer\app\”. An attacker can set the txtUncPath value to “C:\ProgramData\Wavelink\Avalanche”, bypassing the disallowed path checks. Then an attacker can send a request to upload a malicious file to the “RemoteControlServer\app” subfolder. The RemoteControl server is typically used to control connected Windows Mobile/CE devices and can be accessed by sending an HTTP request to http://<hostname>:1900/. By default, the RemoteControl server executes Velocity macro code. By uploading a crafted file to the RemoteControl server webroot, an attacker could execute arbitrary commands on the system.

Source Code Walkthrough

The following code snippet was taken from Ivanti Avalanche version 6.4.1. Comments added by Trend Micro have been highlighted.

From app/FileStoreConfigSettings.xhtml in AvalancheWeb.jar.

From the decompiled WEB-INF.classes.com.wavelink.amc.web.view. CentralFileStoreDialog class in AvalancheWeb.jar.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on TCP ports 8080 (HTTP) and 8443 (HTTPS). Note that the traffic may be SSL encrypted. The detection device may be required to decrypt the traffic before proceeding through the next steps.

The detection device must monitor all HTTP POST requests to a request-URI containing the following path:

      /AvalancheWeb/app/FileStoreConfig.jsf

If such a request is found, then the detection device must search the request body for the linkFileStoreConfigSave parameter. If the linkFileStoreConfigSave parameter value is “linkFileStoreConfigSave”, the value of the txtUncPath parameter must be inspected for the following string:

      ProgramData\Wavelink\Avalanche

If found, the request should be considered suspicious as an attack exploiting this vulnerability is likely underway. Below is an example of a malicious request:

Conclusion

Ivanti patched this vulnerability and several others with the release of version 6.4.2. No other mitigations are listed, so it is recommended that users of Ivanti Avalanche test and deploy this patch to fully address this vulnerability.

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.

How To: Modifying EV Chargers for Benchtop Experiments

Previously, we looked at the ChargePoint Home Flex EV charger – one of the targets in the upcoming Pwn2Own Automotive contest. In this post, we look at how to safely modify an EV charger to perform research through benchtop experiments. This isn’t meant to be a comprehensive guide, but it should provide you with a solid base to start your own research into these devices.


In some of our previous blogs, we’ve looked at the attack surface of devices included in the Pwn2Own Automotive competition. In this post, we provide some information on hardware modifications that can be made to most electric vehicle (EV) chargers to assist in benchtop experimentation. But first, a safety reminder:

 EV Chargers contain high voltages, use extreme caution when working with them.  Never touch interior components when powered on.  If you are unable to determine the safe vs unsafe regions within the device, seek qualified assistance before proceeding.  An open enclosure can be a deadly enclosure. These modifications should not be made if there is an intent to ever plug into a vehicle or use the charging cable power or signal conductors as part of the experimentation. If there is such an intent, the EV charger should not be modified, and the appropriate connections should be made per the manufacturer's instructions.  Additionally, these suggested modifications do not reduce the danger or the need to exercise caution and appropriate high-voltage safety precautions.

Most residential EV chargers arrive out of the box with both the input and output power cables attached to the unit. The power input will generally be a household appliance-type plug, and the charger output will likely be a cable with an SAE J1772 connector that plugs into the vehicle. The input power is typically high current and high voltage (230VAC). However, most researchers do not need a high current connection to power up the device when looking for bugs. You can use a cheap, pre-built power cable that can be sacrificed to avoid the cost of setting up a high current and voltage infrastructure by a licensed electrician just to power up the device under test.

Here’s a look at a typical input cable plug:

Figure 1 - Typical EV charger residential input cable plug

And here’s a typical output cable plug (SAE J1772)

Figure 2 - Typical EV charger output cable plug

These connectors and voltages cannot be easily or safely handled at an electronics bench, so the following modification steps aim to simplify some of this infrastructure for experimentation. As a reminder, these modifications should only be done on EV chargers meant for research. If you intend to plug a vehicle into the charger, we do not recommend making any modifications whatsoever. Instead, follow the manufacturer’s instructions on the proper installation and use of the charger.

With that out of the way, let’s look at the steps needed to modify the EV charger for benchtop experimentation. 

1)     Remove the unit from any power source.

2)     Disconnect the output cable. Since the goal is to experiment on the device only as a stand-alone unit, the output cable can be removed. This involves opening the enclosure and unscrewing the terminals that hold the wires for the SAE J1772 cable. This will typically consist of 3 heavy gauge wires and 1 light gauge communication wire.   Here are some examples:

Figure 3 - Output cable terminals found on the Ubiquity charger

Figure 4 - Output cable terminals found on the Juicebox charger

Figure 5 - Output cable terminals found on the Autel charger

3)     Remove the now loosened output cable from the enclosure. This may also involve removing cable clamps and bulkhead connectors.

4)     Disconnect the input cable. This cable will have 3 large gauge wires attached to the inside of the enclosure. The terminals may or may not be in the same space as the output terminals. Some of the EV chargers place all terminals on the same PCB while others isolate them in different compartments inside the enclosure. It’s best practice to take a photograph of the terminals before disconnecting for future reference. You will be using these terminals to provide power with a smaller cable.

5)     Remove the now loosened input cable from the enclosure. This may involve removing cable clamps and bulkhead connectors.

6)     Identify your region’s voltage. The EV chargers typically run on higher voltages (230VAC) per the manufacturer’s installation documents. If your region has a higher voltage, then no step-up transformer is required. If your region has lower voltages (100VAC – 120VAC), it is recommended that you use a step-up transformer. However, some EV chargers will initialize to some extent with lower voltages so it is possible that, depending on your EV Charger model and the type of exploit you are experimenting with, a step-up transformer may not be necessary. If one is required for you, one suggestion is something like an LVYUAN DT-500VA device that accepts 110VAC input and produces 230VAC output.

Figure 6 - Example of an AC to AC step-up/step-down transformer

7)     You can now install an input cable inside the enclosure. The cable can be lighter gauge since only the electronics are being powered up. On one end will be 3 bare wires and on the other can be a typical 3-prong residential plug. An example is a standard PC power cord with the PC side cut off.  With the insulation removed, there will be 3 wires that can be stripped and the ends tinned (see picture below). Route the cable through the enclosure opening that the previous cable was in. Using the locations where you removed the large input cable, connect the bare wires to those terminals. The ground wire (green) is the first connection. Attach it to where the previous green wire was connected. The other two wires will be energized, so it does not matter which color connects to which of the remaining input power terminals. The picture below is an example of the cable end relative to the terminals.

Figure 7 -  Example of a new input cable prepared for attachment

Figure 8 - Input cable attachment terminals in an Autel charger

8)     With the wiring is complete, you can re-assemble the enclosure.

9)     You can now plug the new input power cable into the 230V receptacle on the step-up transformer. We recommend securing the cable with zip ties to prevent accidental removal of the input cable.

Figure 9 - Input cable attached to the 230V port on the transformer

Conclusion

This shows you how to wire an EV charger for benchtop experimentation. The intent is to use an easy to get, cheap, pre-built cable that can be sacrificed to avoid having a researcher working with a limited budget attempt to build the high current and voltage infrastructure to their bench if they only intend to power up the electronics.  If a researcher already has a 230VAC plug right next to their testbench, they will not need this modification. However, we suspect that most researchers just getting into the automotive space will not have these resources. That’s why we’re offering this work-around for those who don’t intend to connect to a vehicle and thus don’t need a high-current connection.

As always, we recommend using basic electrical safety handling procedures whenever working with electrical devices. Potentially lethal voltages will be present within the unit, especially when powered from a 230VAC source.

The modifications shown in this article should assist you in conveniently conducting your research into potential vulnerabilities in EV chargers. Our research has uncovered some already, and we continue looking into the attack surface of such devices. We hope you’re successful with your research, and if you discover a vulnerability, we hope you demonstrate it during the upcoming Pwn2Own Automotive contest.

Stay tuned to the blog for attack surface reviews and how-to guides for other devices, and if you’re curious, you can see all the devices included in the contest. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

CVE-2023-35150: Arbitrary Code Injection in XWiki.org XWiki

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.814.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.

CVE-2023-36934: Progress Software MOVEit Transfer SQL Injection Remote Code Execution Vulnerability

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.

CVE-2023-20864: Remote Code Execution in VMware Aria Operations for Logs

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.

CVE-2023-24941: Microsoft Network File System Remote Code Execution

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.

CVE-2023-28231: RCE in the Microsoft Windows DHCPv6 Service

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.

❌
❌