An interesting vulnerability in Microsoft SharePoint Server 2019, Microsoft SharePoint Enterprise Server 2016, Microsoft Business Productivity Servers 2010 Service Pack 2, and Microsoft SharePoint Foundation 2013 Service Pack 1 that allows for RCE via a deserialization vulnerability. However for an added twist the vulnerability occurs due to a replay-style attack.

The specifics of the vulnerability are discussed in some detail at https://www.zerodayinitiative.com/blog/2021/3/17/cve-2021-27076-a-replay-style-deserialization-attack-against-sharepoint, however I’ll try cut out a lot of the cruft and boil it down to the key essentials here. Basically in most apps there is a requirement to provide some level of message authentication. This ensures that messages are not tampered with or otherwise altered after they are sent, however there is a fatal flaw that applications can make where they assume that just cause a message is signed, aka it was not tampered, it ensures that the intent of the user was to perform that action.

This issue, aka the lack of intent attached to a message, can lead to incorrect assumptions whereby an application assumes that just cause a message is signed correctly, its intent must be correct. Unfortunately its hard to infer intent based just on some random signed message, as all the signing does is tell us that the sender definitely sent some specific sequence of bytes and that it likely wasn’t tampered with after sending them. This is the basis of the idea behind replay attacks: just cause the message is valid doesn’t mean it can’t be replayed in different scenarios to achieve useful results.

A good example of this is say you have messages to perform action A, B and C and they need to be performed in that order or your factory will explode. Message authentication is great to say okay your doing action A, B, or C and not some other action, but it does nothing to ensure that step B is done after step A and not after step C. That is where intent comes into play.

Now that this logic is understood, we can look at CVE-2021-27076 within SharePoint. This issue occurs in the InfoPath functionality that SharePoint offers, which stores documents in a serialized state within session data, after which they are then retrieved by key using the editingSessionId key and deserialized. As noted in ZDI’s blog post, this deserialization is done by the BinaryFormatter.Deserialize() function, and if arbitrary data can be provided here then an attacker could get RCE.

Now whilst the blog post doesn’t in and of itself say which user gets RCE, if one looks at the advisory from Microsoft they will note some very interesting key words: In a network-based attack an attacker can gain access to create a site and could execute code remotely within the kernel., This to me indicates that whilst the original component that is impacted may not immediately grant kernel level RCE, it is possible to elevate one’s permissions to SYSTEM or similar though the access granted by exploiting this vulnerability. This would ultimately allow an attacker to go from having low permissions on the SharePoint server to gaining full SYSTEM level code execution on the server.

Okay so we know this grants SYSTEM level code execution. Lets continue. The first hurdle we see is that we don’t have direct access to the session data, as this is stored server side. How can we store the arbitrary data we need to store in the session data to trigger the vuln? Well turns out we can use the app itself to store data into the session data, since we can’t directly access it ourselves. We know the app shouldn’t store arbitrary data in the session data that it could end up later deserializing but remember intents from earlier? Well turns out it may not have intended it, but there is a way to do this!

In particular, when uploading files, we normally retrieve the data from the session state using the key associated with a data item that was placed in the session state (remember the earlier discussion about session state being used to hold documents), and the data in the session state is intended to be used for file attachment upload operations (aka file goes to session state, and is then retrieved from session state and used in a file attachment upload operation).

Similarly, DocumentSessionState is used as the deserialization operation, and then when this occurs what normally is expected is that data is retrieved using a key corresponding to an item placed into the session state, with the intent of it being used in a DocumentSessionState deserialization, not a file attachment upload.

In both cases, editingSessionId is used as the key to determine which item should be retrieved from the session state. However, this variable is entirely controlled from client side. Therefore, we can upload arbitrary data via one intent (the attachment upload) and then use that same editingSessionId in a different context, namely to enter the DocumentSessionState deserialization code path.

However now we have a problem, as when uploading an attachment, we can’t see which session state key, aka editingSessionId, is used for that particular attachment. It exists only on the server inside the DocumentSessionState object, which we can’t see as a client side user. To solve this the researcher ended up sending the document state key into the attachment mechanism, which is located at FormServerAttachments.aspx, so that the server replays a serialized DocumentSessionState as an attachment and returns it to the client, and then within this data will be the attachment’s state key, aka its editingSessionId key corresponding to that specific attachment.

As noted in the ZDI report the final steps end up being roughly the following:

1. Create an InfoPath list.
   
2. Begin adding a new item to the list.
   
3. Attach a file to the item. The file contains a fake InfoPath DocumentSessionState including arbitrary objects to be deserialized. The file’s extension can be
   set to anything InfoPath allows for extensions, for example, .png. After attaching this file, do not save the form.
   
4. Scrape the document’s state key from the page’s HTML.
   
5. Feed the document’s state key to the FormServerAttachments.aspx page, maliciously replaying the DocumentSessionState into the attachment mechanism. The entire serialized DocumentSessionState is returned to the client as if it were an attached file.
   
6. From within the returned data, extract the state key of the attachment added in step 3.
   
7. Feed the attachment’s state key into an undocumented client-side API, maliciously replaying the attachment into the deserialization mechanism. Remote code execution is achieved when the arbitrary objects present in the attachment are deserialized on the server.
   

Its interesting that they included most of these steps but just leave the last step as an undocumented client-side API. The client-side API part of this gives us some hints, along with the fact that it replays the attachment into the deserialization mechanism, but without further info or discussion on this part, its hard to tell what this function is right now without doing further analysis. I haven’t seen any discussions on this bug online either so I don’t know if others have figured this out or not; most likely people are still working on it.

In conclusion though I would strongly recommend that users patch this vulnerability. Whilst this bug does require some level of authentication to exploit, which mitigates some of its risk, the fact that it allows users to go from basic authentication to full SYSTEM level control over the affected SharePoint server should not be overlooked. I can see this being a potential for threat groups to utilize in more targeted attacks in the future, given the need for some level of authentication, as this allows for easy pivoting and information gathering should attackers manage to gain some initial credentials to a SharePoint server.