RCE in Citrix ShareFile Storage Zones Controller (CVE-2021-22941) – A Walk-Through

Citrix ShareFile Storage Zones Controller uses a fork of the third party library NeatUpload. Versions before 5.11.20 are affected by a relative path traversal vulnerability (CTX328123/CVE-2021-22941) when processing upload requests. This can be exploited by unauthenticated users to gain Remote Code Execution.

Come and join us on a walk-though of finding and exploiting this vulnerability.

BACKGROUND

Part of our activities here at Code White is to monitor what vulnerabilities are published. These are then assessed to determine their criticality and exploitation potential. Depending on that, we inform our clients about affected systems and may also develop exploits for our offensive arsenal.

In April, Citrix published an advisory that addresses three vulnerabilities in ShareFile Storage Zones Controller (from here on just “ShareFile”). In contrast to a previous patch in the same product, there were no lightweight patches available, which could have been analysed quickly. Instead, only full installation packages were available. So, we downloaded to have a look at it.StorageCenter_5.11.18.msi

THE TRAVELOGUE

A first glance at the files contained in the file revealed the third party library . We knew that the latest version contains a Padding Oracle vulnerability, and since the file had the same .NET file version number as ShareFile (i. e., 5.11.18), chances were that somebody had reported that very vulnerability to Citrix..msiNeatUpload.dllNeatUpload.dll

After installation of version 5.11.18 of ShareFile, attaching to the process with dnSpy and opening the , we noticed that the handler class was missing. So, it must have either been removed by Citrix or they used an older version. Judging by the other classes in the library, the version used by ShareFile appeared to share similarities with NeatUpload 1.2 available on GitHub.w3wp.exeNeatUpload.dllBrettle.Web.NeatUpload.UploadStateStoreHandler

So, not a quick win, afterall? As we did not find a previous version of ShareFile such as 5.11.17, that we could use to diff against 5.11.18, we decided to give it a try to look for something in 5.11.18.

Finding A Path From Sink To Source

Since NeatUpload is a file upload handling library, our first attempts were focused around analysing its file handling. Here was a good candidate to start with. By analysing where that class got instantiated, the first result already pointed directly to a method in NeatUpload, the method. Here a file gets written with something that appears to be some kind of metrics of an upload request:FileStreamBrettle.Web.NeatUpload.UploadContext.WritePersistFile()

By following the call hierarchy, one eventually ends up in , which is the initialization method for :Brettle.Web.NeatUpload.UploadHttpModule.Init(HttpApplication)System.Web.IHttpModule

That method is used to register event handlers that get called during the life cycle of an ASP.NET request. That module is also added to the list of modules in :C:\inetpub\wwwroot\Citrix\StorageCenter\web.config

After verifying that there is a direct path from the processing a request to a constructor, we have to check whether the file path and contents can be controlled. Back in , both the file path and contents include the property value. By following the call hierarchy of the assignment of the field that backs that property, there is also a path originating from the . In , the return value of a call ends up in the assignment of that field:UploadHttpModuleFileStreamUploadContext.WritePersistFile()PostBackIDUploadContext.postBackIDUploadHttpModuleFilteringWorkerRequest.ParseOrThrow()FieldNameTranslator.FileFieldNameToPostBackID(string)

The condition of that branch is that and are set and that returns a value for . originates from the attribute of a multi-part header and from its attribute (see lines 514–517). That means, the request must be a multipart message with one part having a header like this:iftext5text4FieldNameTranslator.FileFieldNameToPostBackID(string)text4text5filenameContent-Dispositiontext4name

Content-Disposition: form-data; name="text4"; filename="text5"

As for , the method call either returns the value of the field if present:text6FieldNameTranslator.FileFieldNameToPostBackID(string)FieldNameTranslator.PostBackID

By following the assignment of that field, it becomes clear that the internal constructor of takes it from a request query string parameter:FieldNameTranslator.PostBackIDFieldNameTranslator

So, let’s summarize our knowledge of the HTTP request requirements so far:

POST /default.aspx?foo HTTP/1.1
Host: localhost
Content-Type: multipart/form-data; boundary="boundary"
Content-Length: 94

--boundary
Content-Disposition: form-data; name="text4"; filename="text5"


--boundary--

The request path and query string are not yet known, so we’ll simply use dummies. This works because HTTP modules are not bound to paths like HTTP handlers are.

Important Checkpoints Along The Route

Let’s set some breakpoints at some critical points and ensure they get reached and behave as assumed:

• UploadHttpModule.Application_BeginRequest() – to ensure the HTTP module is actually active (the BeginRequest event handler is the first in the chain of raised events)
• FieldNameTranslator..ctor() – to ensure the field gets set with our valueFieldNameTranslator.PostBackID
• FilteringWorkerRequest.ParseOrThrow() – to ensure the multipart parsing works as expected
• UploadContext.set_PostBackID(string) – to ensure the field is set with our valueUploadContext.postBackID
• UploadContext.WritePersistFile() – to ensure the file path and content contain our value

After sending the request, the break point at should be hit. Here we can also see that the module expects the to contain and :UploadHttpModule.Application_BeginRequest()RawUrlupload.aspx

Let’s change to and send the request again. This time the break point at the constructor of should be hit. Here we can see that the field value is taken from a query string parameter named or (which is actually configured in the file).default.aspxupload.aspxFieldNameTranslatorPostBackIDiduploadidweb.config

After sending a new request with the query string , our next break point at should be hit. After stepping through that method, you’ll notice that some additional parameters and are expected:id=fooFilteringWorkerRequest.ParseOrThrow()bpaccountid

Let’s add them with bogus values and try it again. This time the break point at should get hit where the gets created:UploadContext.WritePersistFile()FileStream

So, now we have reached the constructor but the field value is as it hasn’t been set yet.FileStreamUploadContext.PostBackIDnull

Are We Still On Track?

You may have noticed that the break point at also hasn’t been hit yet. This is because the loop in uses the result of as condition but it returns on its first call so the block never gets executed.UploadContext.set_PostBackID(string)whileFilteringWorkerRequest.ParseOrThrow()FilteringWorkerRequest.CopyUntilBoundary(string, string, string)falsewhile

When looking at the code of (not depicted here), it appears that it fills some buffer with the posted data and returns if is . The byte array has a size of 4096 bytes, which our minimalistic example request certainly does not exceed.CopyUntilBoundary(string, string, string)false_doneReadingtruetmpBuffer

After sending a multipart part that is larger than 4096 bytes the break point at the should get hit twice, once with a value originating from within the condition’s call and once with originating from within the block:FileStreamnullwhileFilteringWorkerRequest.CopyUntilBoundary(string, string, string)foowhile

Stepping into the constructor also shows the resulting path, which is . Although does not exist, we’re already within the document root directory that the process user has full control of:FileStreamC:\inetpub\wwwroot\Citrix\StorageCenter\context\foocontextw3wp.exe

Let’s prove this by writing a file to it using :id=../foo

We have reached our destination, we can write into the web root directory!

WHAT’S IN THE BACKPACK?

Now that we’re able to write files, how can we exploit this? We have to keep in mind that the / parameter is used for both the file path and the content.iduploadid

That means, the restriction is that we can only use characters that are valid in Windows file system paths. According to the naming conventions of files and paths, the following characters are not allowed:

• Characters in range of 0–31 (0x00–0x1F)
• < (less than)
• > (greater than)
• : (colon)
• " (double quote)
• | (vertical bar or pipe)
• ? (question mark)
• * (asterisk)

Here, especially and are daunting as we can’t write an web shell, which would require or blocks. Binary files like DLLs are also out as they require bytes in the range 0–31.<>.aspx<% … %><script runat="server">…</script>

So, is that the end of this journey? At best a denial of service when overwriting existing files? Have we already tried hard enough?

Running With Razor

If you are a little more familiar with ASP.NET, you will probably know that there are not just Web Forms (i. e., , , , etc.) but also two other web application frameworks, one of them being MVC (model/view/controller). And while the models and controllers are compiled to binary assemblies, the views are implemented in separate files. These use a different syntax, the Razor Pages syntax, which uses symbol to transition from HTML to C#:.aspx.ashx.asmx.cshtml@

@("Hello, World!")

And ShareFile does not just use Web Forms but also MVC:

Note that we can’t just add new views as their rendering is driven by the corresponding controller. But we can overwrite an existing view file like the , which is accessible via :ConfigService\Views\Shared\Error.cshtml/ConfigService/Home/Error

What is still missing now is the writing of the actual payload using Razor syntax. We won’t show this here, but here is a hint: unlike Unix-based systems, Windows doesn’t require each segment in a file path to exist as it gets resolved symbolically. That means, we could use additional “directories” to contain the payload as long as we “step out” of them so that the resolved path still points to the right file.

TIMELINE AND FIX

Code White reported the vulnerability to Citrix on May 14th. On August 25th, Citrix released the ShareFile Storage Zones Controller 5.11.20 to address this vulnerability by validating the passed value before assigning :FieldNameTranslator.PostBackID

On September 14th, Citrix published the Security Bulletin CTX328123.

原文始发于codewhitesec：RCE in Citrix ShareFile Storage Zones Controller (CVE-2021-22941) – A Walk-Through