5.4 Medium
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
REQUIRED
Scope
CHANGED
Confidentiality Impact
LOW
Integrity Impact
LOW
Availability Impact
NONE
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
0.001 Low
EPSS
Percentile
23.3%
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.
Vendor | Product | Version | CVE | Patched? |
---|---|---|---|---|
ONLYOFFICE | Workspace | 12.1.0.1760 | CVE-2022-47412 | Unpatched |
OpenKM | OpenKM | 6.3.12 | CVE-2022-47413 | Unpatched |
OpenKM | OpenKM | 6.3.12 | CVE-2022-47414 | Unpatched |
LogicalDOC | LogicalDOC CE/Enterprise | 8.7.3/8.8.2 | CVE-2022-47415 | Unpatched |
LogicalDOC | LogicalDOC Enterprise | 8.8.2 | CVE-2022-47416 | Unpatched |
LogicalDOC | LogicalDOC CE/Enterprise | 8.7.3/8.8.2 | CVE-2022-47417 | Unpatched |
LogicalDOC | LogicalDOC CE/Enterprise | 8.7.3/8.8.2 | CVE-2022-47418 | Unpatched |
Mayan | Mayan EDMS | 4.3.3 | CVE-2022-47419 | Unpatched |
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.
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.
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.
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:
One <img> two
Three <script>alert('XSS-doc-2')</script> four
/Products/Files/DocEditor.aspx?fileid=11
is a typical path.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.
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.
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.
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:
One <img> two
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.
<img> in the note field.
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.
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.
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.
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 is a stored XSS in the in-app messaging system (both subject and bodies of the messages). Reproduction steps are detailed below.
<img>
<img>
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 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.
<img>
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 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.
<img>.pdf
Once the file name is changed to include the malicious XSS payload, there are a number of conditions that trigger the XSS.
CVE-2022-47418 is an XSS in document version comments. Reproduction steps are detailed below.
<img>
and click the Save button.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.
An XSS vulnerability was discovered in the Mayan EDMS DMS. Successful XSS exploitation was observed in the in-product tagging system.
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 is a stored XSS in the in-product tagging system. Reproduction steps are below.
<script>alert('XSS-tag-label')</script>
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.
5.4 Medium
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
REQUIRED
Scope
CHANGED
Confidentiality Impact
LOW
Integrity Impact
LOW
Availability Impact
NONE
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
0.001 Low
EPSS
Percentile
23.3%