RSS Security

πŸ”’
❌ About FreshRSS
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-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability

In May of 2021, Microsoft released a patch to correct CVE-2021-31181 – 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-573. 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 code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker must have SPBasePermissions.ManageLists permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permission.Β Β Β 

The Vulnerability

This attack is possible due to insufficient validation of user input in the EditingPageParser.VerifyControlOnSafeList() method. This method verifies user input against a list of unsafe controls and should raise an exception if any control is not marked as safe by the SafeControl elements as specified in web.config.

A good example of an unsafe control that is forbidden by SharePoint is System.Web.UI.WebControls.XmlDataSource. This control is dangerous because it would allow an attacker to get information from an arbitrary XML file on the server. As we will see, this could be used not only for information disclosure but even for code execution.

We can see that it is marked as unsafe via a SafeControl element in web.config:

Because of this, an attacker should not be able to instantiate this control. However, we will see how we can bypass verification in EditingPageParser.VerifyControlOnSafeList().

EditingPageParser.ParseStringInternal() parses user input (dscXml) and populates hashtable with information from Register directives and hashtable2 with values from tags that represent server controls. In the next step, it tries to create a Type object for each element from hashtable2 and checks it against an allowed list of SafeControls. However, it will ignore the tag of the server control if the Type cannot be resolved. Normally, this would not create a hazard. If a Type cannot be resolved at the verification stage, then it should similarly fail to resolve later during the actual processing of markup. However, an inconsistency between the code in EditingPageParser and TemplateParser breaks this assumption.

Let’s look closer at how the values in hashtable are populated, and let’s pay attention to the namespace attribute of the Register directive:

The value of the namespace attribute will be stored in triplet.First. Let’s suppose that we have Namespace="System.Web.UI.WebControls " (note the trailing space) in our Register directive, and a tag named XmlDataSource. As you can see, there are no Trim() calls for the namespace attribute. Due to the trailing space, VerifyControlOnSafeList will not be able to resolve the Type System.Web.UI.WebControls .XmlDataSource and consequently it will not be blocked. Later, though, during actual processing of the Register directive, the following code executes:

At this stage, the Namespace will be trimmed and a Type for System.Web.UI.WebControls.XmlDataSource will be successfully resolved. This means the unsafe control will be processed by the server.

For our attack, we will use the WebPartPagesWebService.RenderWebPartForEdit webapi method. It is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It takes ASPX markup as an input, verifies it using EditingPageParser.VerifyControlOnSafeList, and, if there are no unsafe elements, processes the markup in Design mode. The resulting HTML will be returned to the web client.

We will use the WebPart Microsoft.SharePoint.WebPartPage.XsltListFormWebPart with our unsafe XmlDataSource, specifying a simple XSL transformation to copy the result verbatim to our output. In this way we can obtain the contents of an arbitrary XML file from the server. We choose to disclose the contents of web.config. This will provide us with the validation key needed to forge a VIEWSTATE parameter, providing a path to remote code execution.

To proceed, we will also need to provide the Title of any existing SPList from the current site, as well as the site’s webID. These can be obtained easily. We will see how to do this in the PoC section.

Here is an example of a RenderWebPartForEdit request:

We can use the machinekey section from web.config to create a valid VIEWSTATE parameter that causes an arbitrary OS command to be executed when the ViewState is deserialized on the server.

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 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 that we will be the owner and have all permissions.

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

Picture2.png

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

Picture3.png

Choose Team Site.

Choose a name for the new site. In this example, it is ts01.

Picture4.png

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

Picture5.png

Now let’s get the webId for the site. This can be done with a request to /_api/web/id :

Picture6.png

In this example, it is 6e7040c8-0338-4448-914d-a7061e0fc347.

We also need the title of any existing SPlist in the current site. The β€œDocuments” SPlist is available on most sites, but we can use any item from the /_layouts/15/viewlsts.aspx page:

Picture7.png

Now we use our PoC to send a request to the server. We need to provide the base URL for our site, valid user credentials, the title of an SPList, and the webId. In our case:

>PoC.exe http://sp2019/sites/ts01/ user2 [email protected] contoso "Documents" "{6e7040c8-0338-4448-914d-a7061e0fc347}"

If this step successful, we will get the machineKey section of web.config:

Picture9.png

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

validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”

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

Using this information, we can proceed to get remote code execution. Before the actual attack, let’s go to the target SharePoint Server and open C:\windows\temp folder:

Picture10.png

Note that there is no PoC_SPRCE01.txt file yet.

Now let’s go back to the attacker machine. We need to collect one more piece of information, which is the value of __VIEWSTATEGENERATOR. We can get this by browsing to the success.aspx page on our site. In this example, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:

Picture11.png

Viewing the source code, we can find the value of __VIEWSTATEGENERATOR:

Picture12.png

In this example it is AF878507.

In summary, the values needed to forge a VIEWSTATE are as follows:

__VIEWSTATEGENERATOR=AF878507 validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79 validationAlg=HMACSHA256

We provide these values on the command line of ysoserial, as follows:

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

Picture13.png

The result is a valid VIEWSTATE.

We need to URL-encode this ViewState and send it as a __VIEWSTATE parameter to our server. For example, this can be done by composing a URL with a __VIEWSTATE query string parameter, as follows:

Browsing to this URL, an error page is returned.

Picture14.png

However, when we check the C:\Windows\temp folder on the SharePoint server:

Picture15.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-31181, 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-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability

The Top 5 Bug Submissions of 2020

16 December 2020 at 16:23

As the year draws to a close, we thought it would be fun to look back at some of the best submissions we received throughout 2020. We’re very close to having a record-breaking year in terms of published advisories, so narrowing 1,400+ bugs to just five was quite the challenge. In the end, we came up with the following submissions from 2020 that stood out from the pack. Without further ado and presented in no particular order, here are our Top 5 submissions for 2020.


CVE-2020-0688/ZDI-20-258: Microsoft Exchange Server Exchange Control Panel Fixed Cryptographic Key Remote Code Execution Vulnerability

This bug was reported to the program by an anonymous researcher. This highly critical vulnerability in Microsoft Exchange Server allows any authenticated Exchange user to gain SYSTEM privileges on the server. The vulnerability is found in the Exchange Admin Center web interface. Even though this web interface is called an β€œAdmin” interface, by default it is available to any user who has credentials to a mailbox on the Exchange server and is exposed on the network alongside Outlook Web Access. The vulnerability relates to the cryptographic keys (β€œmachine keys”) installed in the Exchange Admin Center ASP.NET application. Exchange should generate these keys randomly at install time so that they will be secret and unique to every installation. Instead, they are copied verbatim from install media, so that an outside attacker can know these keys by referring to any other installation of the product. An attacker can use knowledge of the keys to forge messages that will be deserialized at the server, leading to arbitrary code execution. Vulnerabilities in Exchange Server are highly significant because Exchange is at the nerve center of the enterprise, making it an exceptionally valuable target for adversaries. If your organization has not yet applied the patch, it is imperative to do so at the very earliest time. For further details about this bug, including a video of the bug in action, refer to our previousΒ blogΒ covering the full details of this vulnerability.

Β CVE-2020-3992/ZDI-20-1377: VMware ESXi SLP Use-After-Free Remote Code Execution Vulnerability

This bug was discovered by ZDI vulnerability researcher Lucas Leong. ESXi is an enterprise-class hypervisor developed by VMWare. One of the protocols enabled by default in ESXi is the Service Location Protocol (SLP). SLP is a protocol that enables clients to discover networked services. The most popular implementation of SLP is OpenSLP. However, Lucas discovered that ESXi is using their own custom implementation. Furthermore, there were flaws in this custom implementation that led to two critical security issues. One of these security issues resulted in an SLPMessage object being freed within SLPDProcessMessage() despite the program still retaining a reference to the freed object in the SLPDatabase structure. This results in a Use-After-Free (UAF) condition that can be exploited by a remote attacker within the WAN environment. This vulnerability was initially reported as ZDI-CAN-11563. However, the security patch produced by VMWare did not fully address the issue. This resulted in a bypass that was reported to VMWare as ZDI-CAN-12190. It should be noted that in addition to being remotely exploitable, these SLP bugs can be used for sandbox escapes by processes running within a restricted environment. This vulnerability is a great example that even heavily researched products such as ESXi contain attack surfaces that are often overlooked with dangerous security implications.

CVE-2020-9850/ZDI-20-672: Apple Safari in Operator JIT Type Confusion Remote Code Execution Vulnerability

This bug was reported during the spring Pwn2Own competition by the team from the Georgia Tech Systems Software & Security Lab. This bug is a portion of an interesting chain of bugs that starts with Webkit’s type confusion in the DFG tier, similar to last year’sΒ bug. Then comes Safari’s ability to execute β€œ.app” symlinks, which is aided by a heap overflow bug in OpenGL’s CVM (Core Virtual Machine). Add to that a first-time app protection bypass, root access, and privilege escalation in cfprefsd and kextload respectively due to race conditions. The end result was a successful Pwn2Own demonstration, which earned the team $70,000. The dedication of those researchers in finding and exploiting six vulnerabilities is mind-boggling. This all occurs behind the scenes when an unsuspecting victim visits a simple web page. Imagine browsing the web and 10 seconds later, malicious code is running on your machine. That is pretty neat I would say.

CVE-2020-7460/ZDI-20-949: FreeBSD Kernel sendmsg System Call Time-Of-Check Time-Of-Use Privilege Escalation Vulnerability

This vulnerability was reported to the ZDI program by a researcher who goes by the name m00nbsd. The bug allows an attacker to achieve kernel-level code execution on FreeBSD starting from an unprivileged user using a Time-Of-Check Time-Of-Use (TOCTOU) vulnerability present in the 32-bit sendmsg() system call. The vulnerability is a double-fetch bug in a system call. To trigger the overflow, userland must quickly replace one of the MsgLen values with a bigger value between the first access and the second access. An attacker could trigger this by spawning a thread that calls sendmsg() in a loop, giving it correct arguments. They could then spawn another thread that replaces one of the MsgLen with a gigantic value and then puts back the correct value in a loop. Wait for the two threads to race and the overflow will be triggered. It is surprising that the depth of the bug is quite shallow and yet it survived for many years. We previously blogged about this bug back in September, and you can read all of the details (including PoC) here.

CVE-2020-17057/ZDI-20-1371: Microsoft Windows DirectComposition Uninitialized Pointer Privilege Escalation Vulnerability

This bug was reported to the ZDI program by an anonymous researcher. This is a vulnerability the Windows DirectComposition kernel-mode graphics component. The win32kbase!DirectComposition::CInteractionTrackerMarshaler::SetBufferProperty function populates an object of type DirectComposition::CInteractionTrackerMarshaler based upon data passed from user mode. If this function encounters invalid data, it branches to an error path, which attempts to release resources the function has already created and stored in the object. Due to a bug in this error path, the function can be influenced to release a pointer that was never initialized. This gives an attacker control over the instruction pointer in kernel mode, which can be leveraged to gain SYSTEM privileges.


Thanks for joining us as we recapped some of the best bugs submitted to the ZDI program this year. It’s been an amazing year for the program as we celebratedΒ 15 yearsΒ of operation. Many things have changed over the years, but our desire to work with independent security researchers from around the globe has never wavered. If you have submitted to the program, we thank you for your hard work and participation. If you haven’t submitted to the program, we hope you consider doing so in the future.

Until then, you can follow the ZDIΒ teamΒ on Twitter for the latest in exploit techniques and security patches.

The Top 5 Bug Submissions of 2020

❌