Authors: HWG Sababa & BackBox Team
Vendor Homepage: www.zucchetti.it
Introduction
The product “Zucchetti Ad Hoc Infinity” is the ERP software of the “Infinity Project” suite of software implemented by Zucchetti.
Zucchetti Ad Hoc Infinity 2.4 Remote Code Execution (CVE-2024-51319)
Description
Before starting, it is necessary for us to provide a disclaimer. The mentioned vulnerability has been detected during a penetration test activity for a customer, with a limited time span. It was the first time we had access to the mentioned platform and still we have not a detailed knowledge of its inner workings, mainly due to the proprietary nature of the software and the lack of freely available technical documentation.
From what we have been told by the customer, the application consists of several modules that a developer may combine appropriately, to tailor the ERP to the customer use. Consequently, it is highly likely that the path to reach the vulnerable function for you may vary.
That said, we will try to be as thorough as possible to describe how we reached the vulnerable functionality, in the context of the customer installation. Let’s start.
The product exposes several functionalities to manage suppliers and their outgoing invoices. In the context of the instance under test, the user main page was showing a list of “Passive Invoices”, as shown in the next figure:
Clicking on the evidenced hyperlink, the user can then view the detail about the document, as shown below:
Next, by clicking on the “Fornitore” hyperlink, as highlighted in the picture, it is possible to reach the supplier detail page. In that page, the attacker can then click on “Amministrazione/Report” button, to reach the report generation functionality, as shown below:
The mentioned functionality allows to generate a report of the supplier data, and it is the one affected by the mentioned vulnerability. Specifically, the functionality is triggered by clicking on the “Invia a/MAIL” button, as highlighted below:
The click corresponds to a POST request to “http://example.com/servlet/Report”, like the following:
Due to the NDA with the customer, we can’t of course show all the details about the request and the response. However, it is sufficient to say that the “m_cWv” parameter contains, in turn, a big list of parameters with a custom format. In particular, besides the first parameter (i.e. “Rows”), each inner parameter is composed as follows:
%5cu0023[Parameter Name]=[Parameter Value]%0d%0a.
Among the parameters, it was noticeable the “ForwardTo” one, highlighted in the picture above, that was referring to a relative path to the “jsp” directory of the webserver.
The idea here was to try and use a custom jsp file as the “ForwardTo” parameter, to try and get code execution. In order to do that, however, we needed an arbitrary file upload functionality.
(Un)Fortunately, we didn’t need to search much further, since the same “Invia a/MAIL” functionality opens a page where the user can write and send an entire email, including user supplied attachments.
In particular, through “Allega file/Da file system locale”, the user can upload an arbitrary file, resulting in a multipart request to “http://example.com/jsp/zimg_upload.jsp?dir=WEB-INF/Tmp&file_prefix=contextId&multipart=true”. Note that the user can provide a “dir” URL parameter to specify where the file will be uploaded to, however, through our tests, it seemed that the parameter was checked against path traversals.
Nevertheless, the server response still returned the relative path of the just uploaded attachment.
Consequently, we attempted to directly use such path for the “ForwardTo” parameter, guessing it may not perform any check.
The attempt was actually successful, as shown below:
Note that, due to the platform complexity, size and customizability, we cannot guarantee that the same path applies to your version under test. Nevertheless, the procedure shown above should be sufficient for anyone to replicate the issue, once identified the proper “Report generation” functionality.
Business impact
An attacker is capable of running arbitrary code in the web application context.
Stored Cross-Site Scripting (CVE-2024-51320)
Description
The application is subject to a Stored Cross-Site Scripting flaw, due to the possibility to upload HTML document attachments, as part of an Invoice. Specifically, the functionality seems reserved to “privileged” users only (i.e. those users that have the authorization to add attachments to the Invoice).
Specifically, the functionality is reachable by clicking on the hyperlink of an invoice, as shown below:
And then clicking on the “Allegati” button, in the resulting window:
The button will open a new section, where the user can create/import/add new attachments, as shown below:
The “Nuovo” button allows the user to create a new attachment, through a window like the following one:
The hyperlink “Nuovo file HTML” on the right allows the user to create a custom HTML file, through the POST request to “http://example.com/servlet/gsdm_fsave_htmltmp”, as shown below:
The file is then shown in the list of attachments for the target invoice:
And, if the user clicks on the file hyperlink, the attachment will be shown with a default “inline” parameter, as shown below:
Consequently, when the user clicks on the hyperlink, an iframe opens within the page, rendering the HTML content as inline, and resulting in the XSS code executing, as shown below:
Reflected Cross-Site Scriptings (CVE-2024-51322)
Description
The application is subject to multiple Reflected Cross-Site Scripting instances, through the following payloads:
http://example.com/jsp/home.jsp?main=../asdf%27%29;alert%28document.location%2b%27
- in this case, the “main” URL parameter is reflected directly inside a Javascript code snippet, but is also affecting the “id” value of some “div” and “iframe” tags.
http://example.com/jsp/gsfr_feditorHTML.jsp?pHtmlSource=asdf%3c/textarea%3e%3cscript%3ealert(document.location)%3c%2fscript%3e&pJSCallBack=GetOpener().jdsyl.Update
- the “pHtmlSource” parameter is directly reflected, as is, in the resulting HTML editor, allowing to escape the “textarea” tag and inserting arbitrary HTML.
- the same attack can be triggered by replacing the “pJSCallBack” URL parameter with an XSS payload like “alert(document.location)//”, since the parameter is reflected as is inside an “eval” javascript call. In this case, the attack is triggered when the victim clicks on the “save” ico.
http://example.com/servlet/SPVisualZoom?m_cWv=Rows%3Dasdf%0A0%5Cu0023Table%3Dba_cauana%0A0%5Cu0023Linkzoomprg%3Dgsba_acauana%0A0%5Cu0023Linkzoom%3Dtrue%0A0%5Cu0023PKFields%3DCACODICE%0A0%5Cu0023LinkedField%3DCACODICE%0A0%5Cu0023UID%3DXQXOHZUGWJ%22%3e%3cimg+src='asdf'+onerror=%22alert(document.location)%0A0%5Cu0023SPZTL%3D429b7d4ccff7e41700d056dd0446e64a%0A0%5Cu0023Caption%3Dasdf'%0A
- in this case the “m_cWv” URL parameter and, specifically, the “%5Cu0023UID” part is reflected as is in the “UID” input HTML tag.
http://example.com/jsp/gsmd_container.jsp?pTitle=My+desk&containerCode=MYDESK&bc_JSONPath=[%22KANSDWHPTWti6nnwqu7n%27onmouseover=alert(document.location)//%20t9ebhrjzag%22%2c%22Workspace%22%2c%22%22]%2c[%22SKNECWWNTP%22%2c%22My%20desk%22%2c%22%22]%2c[%22IGVLWDXVOU%22%2c%22Home%22%2c%22..%2fjsp%2fgsmd_container.jsp%3fpTitle%3dMy%20Desk%26containerCode%3dMYDESK%22]
- in this case, the “bc_JSONPath” parameter is affected by a DOM-based reflected XSS that is executed whenever the victim moves the mouse over the “Workspace” or “My desk” links of the page
Note that the last two payloads may have instance specific details that the attacker may want to change before sending the payload to a victim (i.e. we cannot guarantee that they are universal).
Business impact
With the mentioned vulnerabilities an attacker could take control of a victim’s browser session and perform arbitrary operations on his/her behalf.
Unvalidated Redirect (CVE-2024-51321)
Description
The application login page accepts the “m_cURL” parameter, specifying the URL where a user is redirected to, after the login operation.
The parameter is checked to prevent an attacker to provide external endpoints, i.e. anything starting with “http://” or “https://”. However, the “m_cURL” parameter is reflected as is in the “Location” response header, and the server doesn’t check for URLs like “//example.com”. Specifically, when a browser receives a “Location” header starting with “//”, it interprets it as an absolute URL, i.e. the part that follows “//” is parsed as a domain.
As an example, “//example.com/test.jsp” will be interpreted as redirecting the user to “example.com”, requesting the “test.jsp” page.
Consequently, the attacker can send to the victim a URL like “http://target/jsp/login.jsp?m_cURL=//example.com/test.jsp”:
When the victim logs in, a POST request is sent to the server, including the forged “m_cURL” parameter, and the response includes the “Location: //example.com/test.jsp” header:
The browser receiving the server response is then redirected to the final location:
Business impact
With the mentioned vulnerability an attacker could convince victims to login to the legitimate application page, and redirect them to a phishing website, after a successful authentication.
Affected Systems
Currently we don’t have extensive details about the affected systems, due to the proprietary nature of the software, and the fact that the fixes have been implemented directly through vendor-customer communication, totally transparent to us.
The application under test was Zucchetti Ad Hoc Infinity v.2.4 but we don’t have additional details about the patch version.
Note that, through some information given to us by the customer, the Cross-Site Scripting issues and the Unvalidated Redirect have been patched on version 4.2.
Vulnerability History
- November 30th, 2023: Customer RCE notification
- November 30th, 2023: Customer acknowledged the flaw and notified the vendor
- December 5th, 2023: Customer notification of the remaining issues
- December 5th, 2023: Customer acknowledged the vulnerabilities and notified vendor
- December 2023: Customer indicated mid-January as vulnerability patch period
- March 2024: Request for updates to the customer
- March 2024: Customer said further investigation was needed
- July 2024: Request for updates to the customer
- July 2024: Customer answered that vendor patched issues in Mid-June
- October 2024: CVE Request
- November 4th, 2024: CVEs assigned by MITRE