Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2023/02/07/multiple-dms-xss-cve-2022-47412-through-cve-20222-47419/
Through the course of routine security testing and analysis, Rapid7 has discovered several issues in on-premises installations of open source and freemium Document Management System (DMS) offerings from four vendors. While all of the discovered issues are instances of CWE-79: Improper Neutralization of Input During Web Page Generation, in this disclosure, we have ordered them from most severe to least.
The issues are summarized in the table below.
All of these issues were discovered by Rapid7 researcher Matthew Kienow, and validated by Rapid7’s security sciences team. Unfortunately, none of these vendors were able to respond to Rapid7’s disclosure outreach, despite having coordinated these disclosures with CERT/CC. As such, these issues are being disclosed in accordance with Rapid7’s vulnerability disclosure policy. When we become aware of patches or vendor advisories, we will update this advisory with that information.
CVE-2022-47412: ONLYOFFICE Workspace Search Stored XSS
Given a malicious document provided by an attacker, the ONLYOFFICE Workspace DMS is vulnerable to a stored (persistent, or "Type II") cross-site scripting (XSS) condition.
Product Description
ONLYOFFICE Workspace is an AGPL licensed DMS, available as an on-prem or cloud-hosted collaboration platform. Read more about ONLYOFFICE at the vendor’s website.
This vulnerability was identified in testing against ONLYOFFICE Workspace Version 12.1.0.1760. It is likely the vulnerability exists in previous versions of the software as well as the Enterprise offering. The test instance was installed using the Docker image and the instructions for installing ONLYOFFICE Workspace using the provided script.
CVE-2022-47412 Exploitation
The attack hinges on the ability of the attacker to get a document saved in the DMS for indexing. The details of how this might happen are going to vary significantly between sites, ranging from an email or web-based portal for submitting documents automatically to the target organization, to convincing a human operator to manually save the malicious document on behalf of the attacker, to an insider indexing their own document and waiting for another user to trigger the XSS condition.
Once indexed, the attacker then needs to wait for, or convince, a user to trigger the stored document via the search functionality provided by ONLYOFFICE Workspace. One technique to ensure success would be to create a document with several commonly searched-for terms, which will depend on the target organization’s industry, commonly spoken language, and other factors.
Reproduction of the issue is straightforward:
- Upload or create a new document that contains the following two lines of text and tags:
One <img src/onerror=alert('XSS-doc-1')> two
Three <script>alert('XSS-doc-2')</script> four
- Select the document and open it with either the edit or preview option. For example,
/Products/Files/DocEditor.aspx?fileid=11 is a typical path.
- Open the search panel by clicking the magnifying glass icon on the left side of the editor.
- Type one of the words on either side of the tag (one, two, three, or four) and it will cause the related XSS to execute in the user’s web browser.
Impact
Once an attacker has provided a malicious document, and a suitable victim has triggered the XSS condition, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie that a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.
A slightly more subtle and extensible attack would be to hook the victim’s browser session and inject the attacker’s own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.
Once enabled, the attacker would have access to the stored documents, which may be critically important to the targeted organization.
In the absence of an update from the vendor, users of the affected DMS should take care when importing documents from unknown or untrusted sources. Of course, many modern workflows depend on cataloging inbound documents, so this advice should be backed up with a robust document scanner that automatically searches for common XSS patterns embedded in documents. XSS filter evasion is a constantly evolving field, but a reasonable scanner should be able to at least pick out common XSS patterns.
Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.
Disclosure Timeline
- October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
- Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels.
- Fri, Dec 2, 2022: Support ticket #37150 suggests emailing [email protected]
- Mon, Dec 5, 2022: Provided details to the vendor
- Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-LFBLV)
- Tue, Feb 7, 2023: Public disclosure
CVE-2022-47413, CVE-2022-47414: OpenKM Document and Application XSS
Two XSS vulnerabilities were discovered in OpenKM, a popular DMS.
Given a malicious document provided by an attacker, the OpenKM DMS is vulnerable to a stored (persistent, or "Type II") XSS condition.
For the second issue, direct access to OpenKM is required in order for the attacker to craft a malicious "note" attached to a stored document.
Product Description
OpenKM is a GPL licensed DMS, available as an on-prem or cloud-hosted collaboration platform. Read more about OpenKM at the vendor’s website.
These vulnerabilities were identified in testing against OpenKM Version 6.3.12 (build: a3587ce). It is likely the vulnerability exists in previous versions of the software. The tested instance was installed using the Docker image and the installation instructions.
CVE-2022-47413 Exploitation
The attack hinges on the ability of the attacker to get a document saved in the DMS for indexing. The details of how this might happen are going to vary significantly between sites, ranging from an email or web-based portal for submitting documents automatically to the target organization, to convincing a human operator to manually save the malicious document on behalf of the attacker, to an insider indexing their own document and waiting for another user to trigger the XSS condition.
Once indexed, the attacker then needs to wait for, or convince, a user to trigger the stored document via either direct navigation to the document, or the search functionality provided by OpenKM. One technique to ensure success would be to create a document with several commonly searched-for terms, which will depend on the target organization’s industry, commonly spoken language, and other factors.
Reproduction of the issue is straightforward:
- Create a PDF and a text file that contains the following line of text and tag:
One <img src/onerror=alert('XSS-doc-1')> two
- Upload both documents
- A user that selects the text document will trigger the XSS to execute in their web browser. This does not require the Preview tab to be selected, and it will trigger when the default tab, Properties, is selected.
- The stored XSS in the document will also execute via a search
a. Click the Search tab and check the “View advanced mode” checkbox
b. On the Basic tab, change the Context drop-down to “My documents”
c. In the Content field enter one of the words on either side of the tag (one or two)
d. Click the Search button.
e. The XSS will execute in the user’s web browser as long as the document was included in the displayed search results.
CVE-2022-47414 Exploitation
If an attacker has access to the console for OpenKM (and is authenticated), a stored XSS vulnerability is reachable in the document "note" functionality. Reproduction of the issue is below.
- Upload or navigate to a document in the system and click to select it.
- In the lower panel click the Notes tab and enter a tag such as
<img src/onerror=alert('XSS-doc-note')> in the note field.
- Click the Add button
- A user that selects this document will trigger the XSS to execute in their web browser. This does not require the Notes tab to be selected, and it will trigger when the default tab, Properties, is selected.
Impact
Once a suitable victim has triggered one of the described XSS conditions, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.
A slightly more subtle and extensible attack would be to hook the victim’s browser session and inject the attacker’s own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.
Once enabled, the attacker would then have access to the stored documents, which may be critically important to the targeted organization.
For the first issue, in the absence of an update from the vendor, users of the affected DMS should take care when importing documents from unknown or untrusted sources. Of course, many modern workflows depend on cataloging inbound documents, so this advice should be backed up with a robust document scanner that automatically searches for common XSS patterns embedded in documents. XSS filter evasion is a constantly evolving field, but a reasonable scanner should be able to at least pick out common XSS patterns.
For the second issue, in the absence of an update from the vendor, administrators should limit the creation of untrusted users for the affected DMS, since all users have access to the note creation system by default. Until a patch or updated is provided by the vendor, only known, trusted users of the DMS should be permitted to use the tagging features of the application.
Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.
Disclosure Timeline
- October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
- Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels.
- Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-PNWWF)
- Tue, Feb 7, 2023: Public disclosure
CVE-2022-47415 through CVE-2022-47418: LogicalDOC Multiple Stored XSS
Four XSS vulnerabilities were discovered in the LogicalDOC DMS. Successful XSS exploitation was observed in the in-product messaging system, the chat system, stored document file name indexes, and stored document version comments.
Product Description
LogicalDOC Community Edition is an LGPL licensed document management system (DMS), available as an on-prem or cloud-hosted collaboration platform. Read more about LogicalDOC at the vendor’s website.
These vulnerabilities were identified in testing against LogicalDOC Enterprise version 8.8.2 and Community version 8.7.3. It is likely the vulnerability exists in previous versions of the software. The instances tested were installed using the Docker images and the Community installation and Enterprise installation instructions.
Exploitation
The XSS issues identified in LogicalDOC each have their own unique vectors for attacker utility. All require some level of access to the DMS system itself, though "Guest" access is often sufficient to target administrators.
CVE-2022-47415 Exploitation
CVE-2022-47415 is a stored XSS in the in-app messaging system (both subject and bodies of the messages). Reproduction steps are detailed below.
- Click messages tab
- Click Send message button
- Enter one or more Recipients
- In the subject field enter a tag such as
<img src/onerror=alert('XSS-msg-subject')>
- In the message body field enter a tag such as
<img src/onerror=alert('XSS-msg-body')>
- Click the Send button
- If the message recipient is logged into LogicalDOC in the Chrome web browser a pop-up will appear notifying the user of the new message and the XSS will execute in their web browser. If the user was not logged in at the time the message was sent, or they are using the Firefox web browser the XSS will execute in their web browser when they navigate to the messages panel if the XSS was placed in the subject field. If the XSS was placed in the message body it will execute when they select the message.
Note that the "Guest" group is able to send messages to other users by default, including administrators. This would be the likely attack path for an otherwise untrusted, but technically authenticated, user.
CVE-2022-47416 Exploitation
CVE-2022-47416 is a stored XSS in the in-app chat system, and was observed in the Enterprise edition of the DMS. Reproduction steps are detailed below.
- Click Dashboard tab
- Click Chat tab
- In the message input box at the bottom of the bag enter a tag such as
<img src/onerror=alert('XSS-chat-msg')>
- Click the Post button
- The XSS will execute in a user’s web browser if the user is logged into LogicalDoc with the Chat tab selected. If the user was not logged in at the time the message was sent, the XSS will execute in their web browser when they navigate to the Chat tab.
Note that the "Guest" group is able to initiate chats to other users by default, including administrators. This would be the likely attack path for an otherwise untrusted, but technically authenticated, user.
CVE-2022-47417 Exploitation
CVE-2022-47417 is a stored XSS in the document file name, but the filename must be changed in-app (rather than being merely provided by the attacker through some other mechanism). Reproduction steps are detailed below.
- Click Documents tab
- Click Add documents button
- Select a PDF document to upload, check the “Immediate indexing” checkbox, click the Send button and then click the Save button
- Select the uploaded document in the upper panel
- In the lower panel locate the “File name” field and enter as tag such as
<img src/onerror=alert('XSS-filename')>.pdf
- Click the Save button
- A dialog box will appear asking “The file extension has been changed. Do you want to proceed?”, click the Yes button
Once the file name is changed to include the malicious XSS payload, there are a number of conditions that trigger the XSS.
- The XSS will execute in a user’s web browser when they navigate to the Documents tab.
- The stored XSS will execute in another user’s web browser, such as the administrator, without them performing any actions as long as that user previously clicked the Documents tab before the adversarial user performed steps 1-7. The user does not need to remain on the Documents tab for the zero-click XSS to execute in their browser.
- The stored XSS in the document file name will also execute via a search
a. Either using the search box in the upper right hand corner or the Search tab, enter a unique term that appears within the previously uploaded document and click the magnifying glass icon (search button).
b. The XSS will execute in a user’s web browser as long as the document was included in the displayed search results.
CVE-2022-47418 Exploitation
CVE-2022-47418 is an XSS in document version comments. Reproduction steps are detailed below.
- Click Documents tab
- Click Add documents button
- Select a document and click the Send button
- In the input box for the “Version comment” at the bottom of the dialog box enter a value such as
<img src/onerror=alert('XSS-version-comment')> and click the Save button.
- The stored XSS will execute in any user’s web browser if they select the document in the document panel and then click on either the Versions or History tabs.
Impact
Once a suitable victim has triggered one of the described XSS conditions, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.
A slightly more subtle and extensible attack would be to hook the victim’s browser session and inject the attacker’s own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.
Once enabled, the attacker would then have access to the stored documents, which may be critically important to the targeted organization.
In the absence of an update from the vendor, administrators should limit the creation of anonymous, untrusted users for the affected DMS, since in many cases, the "Guest" access level is capable of launching these stored XSS attacks against more privileged users. Until a patch or updated is provided by the vendor, only known, trusted users of the DMS should be permitted to use the messaging, chat, document rename, and document version features of the application.
Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.
Disclosure Timeline
- October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
- Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels. Ticket #11105 opened automatically.
- Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-ZMXZP)
- Mon, Dec 19, 2022: Details disclosed to OpenKM
- Tue, Feb 7, 2023: Public disclosure
CVE-2022-47419: Mayan EDMS Tag XSS
An XSS vulnerability was discovered in the Mayan EDMS DMS. Successful XSS exploitation was observed in the in-product tagging system.
Product Description
Mayan EDMS Workspace is an Apache licensed DMS, available as an on-prem or cloud-hosted collaboration platform. Read more about Mayan EDMS at the vendor’s website.
This vulnerability was identified in testing against Mayan EDMS Version 4.3.3 (Build number: v4.3.3_Tue Nov 15 18:12:36 2022 -0500). It is likely the vulnerability exists in previous versions of the software. Installed using the Docker image and the installation instructions.
CVE-2022-47419 Exploitation
CVE-2022-47419 is a stored XSS in the in-product tagging system. Reproduction steps are below.
- Click Tags and then the “Create new tag” link in the panel on the left. This will take you to the URL http://hostname/#/tags/tags/create/.
- In the Label field enter a tag such as
<script>alert('XSS-tag-label')</script>
- Click the Save button
- Select Documents and then the “All documents” link in the panel on the left.
- Click a document to open the document preview
- Click the Tags link on the panel to the right.
- Click the “Attach tags” button
- Click in the Tags drop-down menu and the XSS will execute in the user’s web browser.
Impact
Once a suitable victim has triggered the described XSS condition, the attacker has several avenues for furthering their control over the target organization. A typical attack pattern would be to steal the session cookie a locally-logged in administrator is authenticated with, and reuse that session cookie to impersonate that user to create a new privileged account.
A slightly more subtle and extensible attack would be to hook the victim’s browser session and inject the attacker’s own commands under the identity of the hooked user, using BeEF or similar post-exploitation tooling.
Once enabled, the attacker would then have access to all stored documents, which may be critically important to the targeted organization.
In the absence of an update from the vendor, administrators should limit the creation of anonymous, untrusted users for the affected DMS, since all users have access to the tagging system by default. Until a patch or updated is provided by the vendor, only known, trusted users of the DMS should be permitted to use the tagging features of the application.
Given the high severity of a stored XSS vulnerability in a document management system, especially one that is often part of automated workflows, administrators are urged to apply any vendor-supplied updates on an emergency basis.
Disclosure Timeline
- October-November: Research project on DMS vulnerabilities initiated by Matthew Kienow
- Thu, Dec 1, 2022: Initial notification to the vendor via guessed email addresses and support channels.
- Fri, Dec 16, 2022: Details disclosed to CERT/CC via VINCE (VRF#22-12-WMFKG)
- Tue, Feb 7, 2023: Public disclosure
Sungyoul Park is a Senior Practice Manager at AWS ProServe. He helps customers innovate their business with AWS Analytics, IoT, and AI/ML services. He has a specialty in big data services and technologies and an interest in building customer business outcomes together.
Jiseong Kim is a Senior Data Architect at AWS ProServe. He mainly works with enterprise customers to help data lake migration and modernization, and provides guidance and technical assistance on big data projects such as Hadoop, Spark, data warehousing, real-time data processing, and large-scale machine learning. He also understands how to apply technologies to solve big data problems and build a well-designed data architecture.
George Zhao is a Senior Data Architect at AWS ProServe. He is an experienced analytics leader working with AWS customers to deliver modern data solutions. He is also a ProServe Amazon EMR domain specialist who enables ProServe consultants on best practices and delivery kits for Hadoop to Amazon EMR migrations. His area of interests are data lakes and cloud modern data architecture delivery.
Kalen Zhang was the Global Segment Tech Lead of Partner Data and Analytics at AWS. As a trusted advisor of data and analytics, she curated strategic initiatives for data transformation, led data and analytics workload migration and modernization programs, and accelerated customer migration journeys with partners at scale. She specializes in distributed systems, enterprise data management, advanced analytics, and large-scale strategic initiatives.
Payal Singh is a Partner Solutions Architect at Amazon Web Services, focused on the Serverless platform. She is responsible for helping partner and customers modernize and migrate their applications to AWS.
Igor Alekseev is a Senior Partner Solution Architect at AWS in Data and Analytics domain. In his role Igor is working with strategic partners helping them build complex, AWS-optimized architectures. Prior joining AWS, as a Data/Solution Architect he implemented many projects in Big Data domain, including several data lakes in Hadoop ecosystem. As a Data Engineer he was involved in applying AI/ML to fraud detection and office automation.
