πŸ”’
❌
There are new articles available, click to refresh the page.
Before yesterdayZero Day Initiative - Blog

CVE-2021-28474: SharePoint Remote Code Execution via Server-Side Control Interpretation Conflict

In May of 2021, Microsoft released a patch to correct CVE-2021-28474, a remote code execution bug in supported versions of Microsoft SharePoint Server. This bug was reported to ZDI by an anonymous researcher and is also known as ZDI-21-574. This blog takes a deeper look at the root cause of this vulnerability.

The vulnerability allows authenticated users to execute arbitrary .NET code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker needs SPBasePermissions.ManageLists permissions for a SharePoint site. By default, authenticated SharePoint users can create sites/subsites and will have all necessary permissions.Β Β Β 

The Vulnerability

This problem exists due to an inconsistency between code that is used for security verification and code that is used for the actual processing of user input.

Security verification is performed by EditingPageParser.VerifyControlOnSafeList(). This function verifies that the provided input does not contain unsafe controls, meaning any control that is not marked as safe by SafeControl elements in web.config file.

The EditingPageParser.ParseStringInternal() function parses user input from dscXml and populates hashtable with information from the Register directives and hashtable2 with values from the tags of server controls. In the next step, it tries to verify each element of hashtable2 against the SafeControl elements from the web.config file. If a control is not marked there as safe, it throws an exception.

Let’s take a closer look at how values in hashtable2 are populated:

As we can see, the SharePoint server verifies only server-side controls (tags with the runat="server" attribute). This is reasonable since client-side elements do not require verification.

Β If verification passes, SharePoint will process the provided markup. Let’s review the code that performs the processing:

As you can see, the steps for parsing content at processing time are very similar to the parsing steps at verification time. However, there is a critical one-line difference:

Β Β Β Β Β Β text4 = HttpUtility.HtmlDecode(text4);

At processing time, attribute values are HTML-decoded by the parser, but there is no corresponding line at verification time. This means that if we have an ASPX tag with an attribute such as runat="server", the EditingPageParser.VerifyControlOnSafeList() function will not consider it a server-side control and will not check it for safety. At processing time, however, it will be recognized and executed as a server-side control.

Exploitation

For our attack, we will use the System.Web.UI.WebControls.Xml control. It allows us to retrieve information from an arbitrary XML file. We can use this to exfiltrate the machineKey section from web.config, which we allow us to forge an arbitrary ViewState and achieve remote code execution via ViewState deserialization.

We can see that System.Web.UI.WebControls.Xml is marked as unsafe via a SafeControl element in web.config:

To deliver our payload to the server, we will use the WebPartPagesWebService.ExecuteProxyUpdates web API method that is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It allows us to render ASPX markup from the OuterHtml attribute in Design mode. User input will be verified by the VerifyControlOnSafeList method.

For a successful attack, we need to provide a relative path to any existing site page:

We can use information from the machinekey section from web.config to create a valid ViewState that will be deserialized by SharePoint. This allows us to run an arbitrary OS command via deserialization of untrusted data.

Proof of Concept

For this demonstration, we use Microsoft SharePoint Server 2019 installed with all default options on Windows Server 2019 Datacenter. The server’s computer name is sp2019.contoso.lab and it is a member of the contoso.lab domain. The domain controller is a separate virtual machine. It has been updated to the January 2021 patch (version 16.0.10370.20001β€Ž) and a couple of users have been added, including β€œuser2” as a regular, unprivileged user.

On the attacker side, we need any supported web browser, our PoC application for sending SOAP requests to the server, and the ysoserial.net tool. For this demonstration, we are using Firefox as our browser.

Getting Remote Code Execution

Let’s begin by visiting our SharePoint Server and authenticating as β€œuser2”.

Picture1.png

Let’s create a site so we will be the owner and have all permissions.

Click on β€œSharePoint” on the top panel:

Picture2.png

Now click β€œ+ Create site” link:

Picture3.png

Choose Team Site.

Now we need to pick a name for the new site. In this case, we use ts01.

Picture4.png

Click β€œFinish” and the new site will be created:

Picture5.png

Now we need a relative path to any site page in this site. We can see list of pages by going to /SitePages/Forms/ByAuthor.aspx:

Picture6.png

We can click on the desired page and take the relative path from the address bar (note that we omit the leading site name and β€œ/” ) :

Picture7.png

In our case, it is SitePages/Home.aspx.

Now we use our custom executable to send a request to the server that triggers the vulnerability. We need to provide the URL to our site, credentials, and the relative path determined above. In this case:

Β Β Β Β Β Β >SP_soap_RCE_PoC.exe http://sp2019/sites/ts01/ user2 [email protected] contoso "SitePages/Home.aspx"

Picture8.png

If our attack is successful, we receive the content of web.config:

Picture9.png

Within the file, we search for the machineKey element:

Picture10.png

For our RCE attack, we need the value of validationKey. In this case it is:

Β Β Β Β Β Β validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”

We can also see the algorithm: validation="HMACSHA256".

Using this information, we can perform our remote code execution attack. Before the final step, let’s go to the target SharePoint server and open C:\windows\temp folder:

Picture11.png

We verify there is no SP_RCE_01.txt file yet.

Now let’s go back to the β€œattacker” machine, and open the Success.aspx page on our site:

In this case, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:

Picture12.png

Now we need to open the source code view for this page and find the value of __VIEWSTATEGENERATOR:

Picture13.png

In this example, it is AF878507.

We now have all the data needed to forge an arbitrary ViewState:

Β __VIEWSTATEGENERATOR=AF878507

validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79

validationAlg=HMACSHA256

We generate the ViewState using ysoserial, as follows:

>ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo RCE > c:/windows/temp/SP_RCE_01.txt" --generator="AF878507" --validationkey="FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79" --validationalg="HMACSHA256" --islegacy --minify

Picture14.png

Here is the resulting payload:

We need to URL-encode it and send it as the __VIEWSTATE parameter in the query string in a request to our server:

We paste this URL into the browser. The response appears as an error:

Picture15.png

Nevertheless, when we check the C:\windows\temp folder on our target server again:

Picture16.png

Our target file was successfully created, demonstrating that we achieved code execution. In the same way, an attacker can execute any OS command in the context of the SharePoint web application.

Conclusion

Microsoft patched this in May and assigned identifier CVE-2021-28474, with a CVSS score of 8.8. SharePoint continues to be an attractive target for researchers and attackers alike, and several SharePoint-related disclosures are currently in our Upcoming queue. Stay tuned to this blog for details about those bugs once they are disclosed.

Until then, follow the team for the latest in exploit techniques and security patches.

CVE-2021-28474: SharePoint Remote Code Execution via Server-Side Control Interpretation Conflict

CVE-2021-26420: Remote Code Execution in SharePoint via Workflow Compilation

In June of 2021, Microsoft released a patch to correct CVE-2021-26420 – a remote code execution bug in the supported versions of Microsoft SharePoint Server. This bug was reported to the ZDI program by an anonymous researcher and is also known as ZDI-21-755. This blog takes a deeper look at the root cause of this vulnerability.

Before this patch being made available, this vulnerability could be used by an authenticated user to execute arbitrary .NET code on the server in the context and permissions of service account of SharePoint web application. For successful attack, the attacker should have β€œManage Lists” permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permissions.Β Β Β 

The Vulnerability

SharePoint workflows are pre-programmed mini-applications that streamline and automate a wide variety of business processes. An organization can use workflows to attach business logic to documents or items in a SharePoint list or library.

For security purposes, Workflow Foundation (WF) on SharePoint runs workflows only when all dependent types and assemblies are authorized in the authorizedTypes list in the web.config file. Along with allowed types, this list also contains items that block specific types from allowed namespaces that are considered dangerous. One example is System.Workflow.ComponentModel.Compiler. The Compile() method offered by WorkflowCompiler compiles a workflow based on parameters. Workflows in SharePoint are normally compiled in very restricted context (no code, types restricted by the authorizedTypes list, etc.), but invoking WorkflowCompiler would allow attackers to create a new context without these restrictions by specifying appropriate parameters. Because of this, WorkflowCompiler is blocked by the authorizedTypes list in web.config:

Therefore, we cannot mount an attack using WorkflowCompiler type. However, examining the .NET code of WorkflowCompiler.Compile reveals something interesting:

From here we see that the bulk of the implementation of WorkflowCompiler.Compile resides a different class named WorkflowCompilerInternal. This class is not blocked by authorizedTypes list. Furthermore, since it is found within the `System.Workflow` namespace, it is allowed by the line:

Therefore, we can compile an arbitrary workflow by invoking the WorkflowCompilerInternal type directly.

For arbitrary code execution, we can use the following XOML file (Attck.xoml). When compiled, it will execute the desired .NET commands, provided that the noCode flag is not specified:

Here is the .rules file (WF02.rules) of a SharePoint workflow that invokes the WorkflowCompilerInternal.Compile to compile an arbitrary XOML workflow definition, provided that the XOML file can be retrieved from an SMB share:

This rule will be triggered by the following lines from the XOML file of our SharePoint workflow (WF02.xoml):

An attacker could store Attck.xoml in a shared SMB folder controlled by the attacker and upload the WF02.xoml and WF02.rules files to a location on the SharePoint site, for example, to the Documents folder. Also, the attacker would need a workflow configuration file (WF02config.xml) that points to the uploaded XOML and rules files, and associates them with the ListID of a list in the site where the attacker can add new items:

An attacker would need to associate this new workflow with the SharePoint list. This can be done by using the AssociateWorkflowMarkup method from the WebPartPages WebService (/_vti_bin/WebPartPages.asmx) and providing the relative path to the uploaded config file.

To trigger workflow execution, the attacker adds a new item to the target SharePoint list. Β 

Proof of Concept

For this demonstration, we use Microsoft SharePoint Server 2019 installed with all default options on Windows Server 2019 Datacenter. The server’s computer name is sp2019.contoso.lab and it is a member of the contoso.lab domain. The domain controller is a separate virtual machine. It has been updated to the February 2021 patch level (version 16.0.10371.20043) and a couple of users have been added, including β€œuser2” as a regular, unprivileged user.

On the attacker side, we need:
-- an SMB server hosting the Attck.xoml file containing the .NET code we want to execute. It must be hosted on a share that can be accessed by the SharePoint server
-- our PoC application for sending SOAP requests to the server (SP_soap_RCE_PoC.exe) that calls the AssociateWorkflowMarkup method of the WebPartPages web service
-- the workflow config file, WF02config.xml
-- The XOML and .rules files referenced by the workflow config file
-- any supported web browser. For this demonstration, we are using Firefox.

Achieving Remote Code Execution

Let’s visit our SharePoint Server and authenticate as a regular user. In my case it is user2:

Picture2.png

Before our attack, we need to prepare a few things. We could try to do this with current user sites, but if possible, we recommend creating a new site so that we will be the owner and have all permissions.

Click on β€œSharePoint” on the top panel:

Picture3.png

Now click the β€œ+ Create site” link:

Picture4.png

Choose Team Site.

Pick a name for the new site. Here we use testsiteofuser2.

Picture5.png

Click β€œFinish” and the new site will be created:

Picture6.png

Now we need to create a new list. Click on the β€œSite contents” link:Β 

Picture7.png

Then click β€œ+ New” -> β€œList”:

Picture8.png

Enter any available name. For example, β€œNewList”:

Picture9.png

And click β€œCreate”:

Picture10.png

We will need the ListID of this new list. Let’s go back to the β€œSite contents” page and click on β€œSettings” in the dropdown menu for our new list:

Picture11.png

We will be redirected to the listedit.aspx page:

Picture12.png

We need value of the List URL parameter. In my case it is:

28e11fd2-9f76-418c-83ea-dc0d8f3c184bΒ 

We need to place this value into the ListId attribute in the workflow config file, WF02config.txt:Β 

Picture13.png

Now we need to upload the Attck.xoml file, containing the .NET code we want to run, into an SMB folder that is accessible from the SharePoint server.

We should place the remote path to the Attck.xoml file into WF02.rules:

Picture14.png

Save changes in both files (WF02config.txt and WF02.rules) and upload them together with the WF02.xoml file to the Documents folder of our SharePoint site:

Picture15.png

We are almost ready for the final step. But first, let’s check the C:\windows\temp folder on our target SharePoint server:

Picture16.png

There is no PoC_SPRCE02.txt file yet.

For our attack, we will use the SP_soap_RCE_PoC.exe application. We need to provide the following information:

β€” BaseUrl of the target SharePoint Site (in this case http://sp2019/sites/testsiteofuser2/)Β Β 
β€” UserName (in this case user2)Β 
β€” Password
β€” Domain

β€” Relative path to the workflow config file on our site - "Shared Documents/WF02config.txt"

> SP_soap_RCE_PoC.exe http://sp2019/sites/testsiteofuser2/ user2 [email protected] contoso "Shared Documents/WF02config.xml"

Picture17.png

We received a β€œSuccess” result. Now to trigger the RCE, we just need to add a new item to NewList:Β 

Picture18.png

Click on the β€œSave” button there.

Let’s check C:\windows\temp folder on our target SharePoint server:

Picture19.png

The file PoC_SPRCE02.txt has been created, demonstrating the success of our code execution. In this manner, our attacker can execute arbitrary OS commands in the context of the SharePoint web application account.

To run additional OS commands, we would need to place them into Attck.xoml file in the shared folder and create another new item in NewList.

Picture20.png

Conclusion

Microsoft patched this in June and assigned identifier CVE-2021-26420, with a CVSS score of 7.1. While the inclusion of an attacker-controlled SMB server adds a level of complexity, this bug can still be used for code execution in many scenarios. Since SharePoint is generally considered an attractive target for attackers, it would not be surprising if this bug were to be found in the wild. SharePoint continues to be an attractive target for security researchers, and many SharePoint-related disclosures are currently in our Upcoming queue. Stay tuned to this blog for details about those bugs once they are disclosed.

Until then, follow the team for the latest in exploit techniques and security patches.

CVE-2021-26420: Remote Code Execution in SharePoint via Workflow Compilation

CVE-2021-44142: Details on a Samba Code Execution Bug Demonstrated at Pwn2Own Austin

Recently, Samba released a patch to address an Out-of-Bounds (OOB) Heap Read/Write vulnerability found in Samba versions prior to 4.13.17. This vulnerability was disclosed at Pwn2Own Austin 2021 by Nguyα»…n HoΓ ng ThαΊ‘ch Β (@hi_im_d4rkn3ss)Β and Billy Jheng Bing-Jhong (@st424204)Β of STAR Labs. After the event, Lucas Leong of Trend Micro Zero Day Initiative discovered additional variants of the vulnerability which were disclosed to Samba as part of this fix. This bug was also independently reported to Samba by Orange Tsai of DEVCORE.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Samba. Authentication is not required to exploit this vulnerability. The specific flaw exists within the parsing of EA metadata in the Samba server daemon (smbd) when opening a file. An attacker can leverage this vulnerability to execute code in the context of root.

Now that the patch has been made available, let’s take a more detailed look at the bugs involved and the patch released to fix them. Much of this information was derived from the white paper submitted by STARLabs as a part of their Pwn2Own entry.

Background

Within Samba, the server daemon that provides the file sharing service is known as smbd. This analysis was conducted on smbd version 4.9.5, which can be downloaded here. While this isn’t the latest version of Samba, there are still quite a few vendors that incorporate this version or prior versions in their products. This was the case during Pwn2Own Austin 2021. Since Samba provides file sharing between devices, it is often enabled by default. The configuration of smbd is found in /etc/samba/smb.conf. Here’s a portion of an smb.conf file showing how Samba would be configured to support a Time Machine share for Apple devices:

In this section, you can see that guest ok = yes is declared, which allows guest authentication. The vfs objects list contains three modules: catia, fruit, and streams_xattr. The bugs we’re concerned with reside in the fruit module, which provides enhanced compatibility with Apple SMB clients. As stated by the vendor advisory, β€œThe problem in vfs_fruit exists in the default configuration of the fruit VFS module using fruit:metadata=netatalk or fruit:resource=file. If both options are set to different settings than [sic] the default values, the system is not affected by the security issue.”

The Vulnerability

The fruit module that ships with Samba is designed to provide interoperability between Samba and Netatalk. Netatalk is an open-source implementation of the Apple Filing Protocol (AFP). It allows Unix-like systems to serve as file servers for Apple devices. Once a session is established, smbd allows an unauthenticated user to set extended file attributes of a file via SMB2_SET_INFO. This is done by the set_ea function found in β€œsource3/smbd/trans2.c”. The name of the attribute must not be within the private Samba attribute name list, which includes user.SAMBA_PAI, user.DOSATTRIB, user.SAMBA_STREAMS, and security.NACL. With the exception of these attributes, an attacker can set arbitrary extended attributes.

The fruit module handles requests that access a file with the stream name :AFP_AfpInfo or :AFP_Resource. If using the stream name :AFP_AfpInfo, an attacker can open, read, and write Netatalk metadata of a file. Netatalk metadata is stored in a adouble structure, which is initialized by the ad_get/ad_fget functions.

The Netatalk metadata of a file is stored in the value of the extended attribute identified by the name org.netatalk.Metadata. The metadata will be parsed to fill the adouble (AppleDouble) structure. Since org.netatalk.Metadata isn't in the private Samba attribute name list discussed above, an attacker can set an arbitrary value for this attribute. Therefore, it's possible for an attacker to inject malformed metadata values. This can lead to multiple out-of-bounds memory accesses when the adouble structure is later used.

Let’s take a more detailed look at the bugs used to exploit this vulnerability during the Pwn2Own competition.

ZDI-22-245: Heap Out-Of-Bounds Read

The fruit_pread function reads metadata of a file. Since our file stream is named :AFP_AfpInfo and the file type is ADOUBLE_META, the function chain fruit_pread_meta -> fruit_pread_meta_adouble will be executed.

Consider the following source code:

At line 4279, the ad_fget function creates an adouble structure containing attacker-controlled data.

At line 4285, the call to ad_get_entry returns the pointer to the ADEID_FINDERI entry. Since this is controllable by the attacker, they can make p point to the last byte of the ad->data buffer. This will cause the memcpy call at line 4300 to read past the end of the allocated buffer and dump up to thirty-one bytes of memory from the heap.

ZDI-22-246: Heap Out-Of-Bounds Write

The fruit_pwrite function is used to write metadata to a file. Since we can already control an ADEID_FINDERI entry, we can leverage that to control a memcpy call, which allows us to write up to thirty-one bytes of data to the heap.

Consider the following source code:

At line 4657, the ad_fget function creates the ad adouble structure from metadata. As mentioned before, an attacker could inject malformed metadata here and control the values within.

Later at line 4664, the ad_get_entry returns the pointer to the ADEID_FINDERI entry. Since this is controllable by the attacker, they can set p to point to the last byte of the ad->data buffer. This allows the memcpy call at line 4671 to write past the end of the ad->ad_data buffer. Since ad->ad_data is allocated from heap memory, the attacker can leverage this vulnerability to write up to 31 bytes of data past the end of the heap buffer.

ZDI-22-244: Heap-based Buffer Overflow

When analyzing the bugs used during Pwn2Own, ZDI Vulnerability Researcher Lucas Leong noticed a variant of the vulnerability used at the contest.

In the case of the bugs used during Pwn2Own, Samba fails to validate the ADEID_FINDERI function, which leads to an OOB read and OOB write. Further analysis from Lucas found that Samba does not validate the ADEID_FILEDATESI entry either. This leads to OOB read in ad_getdate and an OOB write in ad_setdate. This leads to an overflow of three bytes, as seen in the code below:

An attacker can possibly leverage this vulnerability to execute code in the context of the smbd daemon.

Patch details

The source code of the patch for CVE-2021-44142 can be found here. The primary change from the vendor was an update to two areas to mitigate this vulnerability.

First, Samba added the function ad_entry_check_size(), which validates the size of each entry when parsing the AppleDouble format.

Second, Samba added the Netatalk extended attribute AFPINFO_EA_NETATALK to the list of the private attribute name list. Since an attacker needs to set the malformed extended attribute on a file at the beginning stage of this exploit, this change effectively blocks any user attempting to set any Netatalk extended attribute. This is a generic mitigation for this attack vector.

Conclusion

Samba patched this and other bugs on January 31, 2022. They assigned CVE-2021-44142 to cover the bugs discussed in this report. In addition to 4.13.17, Samba 4.14.12 and 4.15.5 have been released to address this vulnerability. The vendor does list removing the fruit VFS module from the list of configured VFS in β€œsmb.conf” as a workaround. However, this will severely impact the functionality of any macOS systems attempting to access the Samba server. Because of this, you should focus on testing and deploying the patch to remediate this vulnerability. It’s also recommended to reach out to any third-party vendors with devices on your enterprise to ensure they have consumed the patch and provided updates to their devices as well. It is expected that many different vendors will need to update the version of Samba they ship with their devices, so expect lots of additional patches to address these bugs.

Thanks again to Nguyα»…n HoΓ ng ThαΊ‘ch (@hi_im_d4rkn3ss) and Billy Jheng Bing-Jhong (@st424204) of STAR Labs for participating in Pwn2Own Austin 2021 and demonstrating this bug. At the contest, they won $45,000 from this exploit alone, and a total of $113,500 for the entire event. We certainly hope to see them at future competitions. Until then, follow the team for the latest in exploit techniques and security patches.

CVE-2021-44142: Details on a Samba Code Execution Bug Demonstrated at Pwn2Own Austin

  • There are no more articles
❌