iStern Blog

After looking for some extreme hardening of the Sitecore client I found a way to get Remote Code execution (RCE) via a Update center, described in this post.

It is possible for authenticated users, to upload arbitrary files, via update package functionality.It is possible for a malicious attacker to bypass file upload restrictions, hardened with the Sitecore hardening guide https://doc.sitecore.com/en/developers/101/platform-administration-and-architecture/security-guide.html and with secure file upload functionality, taken from this link
https://doc.sitecore.com/developers/100/platform-administration-and-architecture/en/secure-thefile-upload-functionality.html.

Test Instance information

The test of this was done on a local Windows 10 machine with Sitecore 10 XM installation, installed via Graphical installation wizard see more information below

The Additional Filed upload restriction package was also installed with the following settings.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<processors>
<uiUpload>
<processor mode="on"
type="Sitecore.Pipelines.Upload.CheckExtension,
Sitecore.UploadFilter" patch:before="*[1]">
<param desc="Allowed extensions (comma separated)"></param>
<param desc="Blocked extensions (comma separated)">exe,dll,aspx</param>
</processor>
</uiUpload>
</processors>
</sitecore>
</configuration>

Steps to reproduce

Keep in mind this is a autheticated file upload, so a compromised user must be obtained.

1. Authenticate / Login to Sitecore

2. Once correctly logged in. Navigate to the Upload center

3. Choose/click the option to upload custom update

4. Pick your custom webshell

5. If the installer hangs click anywhere in the windows, this is expected.

6. Since uploads of updates packages always goes into the same folder

https://HOSTNAME/sitecore/admin/Packages/

to find the uploaded file in our case
https://sc101cm.dev.local/sitecore/admin/Packages/shell.aspx

7. Now all that is left is running the webshell.

Remediation

Disabled the Update center functionality

One way of doing the in add restriction to path in web.config like below

 <location path="sitecore/api/ssc/updatecenter">
  <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
  </location>

Other

The findings has been reported to Sitecore, and the Update center is being deprecated, but until this happens a simple fix is as mentioned to disabled the Update center functionality.

This vulnerability has been given CVE-2021-38366

Let’s start with a question:
Should you trust data downloaded from your own website?

As a rule of thumb NO ! especially not if what you download contains user generated input, as an example data collected from Sitecore Form.

There is something interesting about this, because there is a trust relation for editors to their own site, most editors “i hope” will see their own site as a trustworthy source for downloads, and why shouldn’t they .But is this really true ? In this blog post I will give an example of how Sitecore can be used as a vessel to deliver a malicious payload to an unknown editor “victim”. 

For this I’ve used the latest version of Sitecore 10.0.1 in XM mode.

To enable this let’s assume an editor creates a Form like the one below but it could be any form with fields that allows for text input.

IMG-1-form

Now after publishing the form the attacker sees form “sorry for missing styling:)”

img2

For testing purposes  i will use a very simple payload “=1+1*cmd|’/k echo backdor’!z” which opens an command prompt and display the texst backdoor. More  payloads can be found here https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CSV%20Injection also note that could be other that are more relevant for other application and not Excel specificly.

The vulnerability used here is better known as csv injection or formula injection

Now after some time the editors want to get the data from his newly created form. He logins into Sitecore and navigates to his form and exports the data “btw only way to view Forms collected data in Sitecore OTB”

Now the next part is he opens the csv file in Excel “please note I’ve enabled what can be seen as an insecure setting in Excel see below.

Now lets see what happens when the editor opens the csv file

Excel does show an alert, and this is where the trust comes into play because why wouldn’t the editor accept the warning and continue.

So now lets see what happens after he accepts the warnings

A nice little command prompt has opened with the text defined in our payload earlier. 

So the question is this a vulnerability in Sitecore ? No or ….. You could filter out characters that could allow these attacks or you could simply add an “‘“ in front of all fields when exported, I will leave it to you to decide, but at least you should tell your customers to regard it as an insecure source when downloading content that contains user generated input. And please MAKE SURE TO DISABLE  “enable dynamic data exchange server launch” in excel. Note this also works for applications then excel., maybe with a different payload.