Microsoft SharePoint Latest Update Summary (CVE-2020-1178, CVE-2020-1181)
In the recent days Microsoft has published a new security advisory related to Microsoft SharePoint based systems. The advisory published revealed: 7 Cross-Site Scripting vulnerabilities - Can be mitigated by existing BIG-IP ASM Cross-Site Scripting signatures). 1 Open Redirect vulnerability - Can be mitigated by BIG-IP ASM Open Redirect mitigation feature. 1 Privilege Escalation vulnerability which details regarding the exploitation path is still unclear. 2 Remote Code Execution vulnerabilities - One of them related to Server-Side Request Forgery attack, and the other related to uploading a malicious “Web Part” onto a vulnerable SharePoint instance. In this post we will discuss some details that we revealed related to the SSRF vulnerability (CVE-2020-1178), And also some of the details that were publicly disclosed related to the malicious “Web Part” vulnerability (CVE-2020-1181). CVE-2020-1178 – Remote Command Execution via Server-Side Request Forgery and NTLM relay SharePoint has a functionality that allows users to create a type of list named “Site List”, this site list can contain links to other external or internal sites. Each one of the links added to this type of list has an attribute named “LinkStatus” which indicates if the supplied link is either reachable or if it is down. Figure 1: Example of a site list created during the reproduction of the vulnerability. SharePoint offers two ways of checking for broken links; one is done through the Central Administration site of SharePoint and requires the SharePoint Administrator to enable a specific SharePoint job named “LinksCheckerJob”. As the vulnerability advisory categorized it as a Privilege-Escalation vulnerability, we assumed that this is not the right exploitation path of this vulnerability. The second way for checking for broken links can be done by accessing a page named “linkschecker.aspx” and supplying it with a query parameter named “v” with a value set to the URL containing the site list we want it to validate. To exploit this vulnerability, first an attacker must hold an account associated with the “Site Admin” privilege, as the mentioned “linkschecker.aspx” page first checks this when a request to validate links is received. Then the attacker would have to create a site list page and add his malicious link to this created list, after this is done all he has to do now is supply the link to this list to the “linkschecker.aspx” page. Figure 2: linkschecker.aspx page Once the “linkschecker.aspx” page will validate the attacker’s link it will trigger a Server-Side request to an attacker-controlled site. But this SSRF vulnerability has a much more interesting side, as it may be escalated into a Remote Command Execution vulnerability. The request sent to the attacker controlled link may contain the credentials of the configured IIS application pool user negotiated via the NTLM authentication scheme. but this can only happen when the attacker site will respond back with a “401 Unauthorized” HTTP status code. This fact allows the attacker to relay the credentials sent by the SharePoint site back to it via a different protocol (SMB for instance) – and this is how remote command execution could be achieved in this case. CVE-2020-1181 – Remote Code Execution By Uploading a Malicious WebPart “WebPart” is a term used by Microsoft for different objects that can be embedded to the site pages by using the SharePoint content editor. This vulnerability is triggered when a specially crafted web part is embedded into a created page via the SharePoint content editor. A research paper published by Zero Day Initiative provides a Proof of Concept WebPart that triggers the vulnerability and also explains in depth how SharePoint treats user created content against how it treats internal pages. We will try to add on top of this knowledge by going into the details of why the “WikiContentWebpart” was chosen for the exploitation task. Here are two reasons that makes “WikiContentWebpart” a good fit for exploiting this vulnerability: It has the “ParseChildren” attribute set to true in its class declaration – According to Microsoft documentation, it instructs the ASP.NET Page Parser to treat nested web control elements as the class attributes, instead of associating them to the parent control “Controls” collection. Figure 3: ParseChildren attribute set to true in the WikiContentWebpart class declaration So in the Proof of Concept webpart XML shown in the Zero Day Initiative article we can see that the Content member of the “WikiContentWebpart” class will be set to point a specially crafted “ObjectDataSource” instance that will execute an arbitrary command while parsed. Figure 4: WikiContentWebpart xml shown in the Zero Day Initiative article 2. The “WikiContentWebpart” passes the value of the “Content” class member concatenated to a private member named “_directive” to the “ParseControl” method which parses a string and instantiates a web control object. The “_directive” private member has its value set to an ASP.NET register directive string - which is used for registering ASP.NET assemblies containing the implementation code of the WebControl that is about to be parsed. Figure 5: “WikiContentWebpart” passing its “Content” member value concatenated to the _directive private member value to the “ParseControl” method. So this means that instances of the “WikiContentWebpart” that didn’t specifically set its “_directive” member value was intended to embed web controls registered under the “Microsoft.Sharepoint.WebControls” namespace, but it can also allow loading web controls registered under the default “asp” TagPrefix accessible in any ASPX page. The proof of concept WebPart XML is instantiating an “ObjectDataSource” object that is located in the “System.Web” .net assembly and available under the “asp” TagPrefix. ObjectDataSource is also a good pick for the exploitation purpose because it allows instantiating arbitrary object types indicated by the value of the “TypeName” class member, and allows invoking arbitrary method from the type specified as indicated by the “SelectMethod” class member. As can be observed from the proof of concept webpart XML - it attempts to instantiate an object from the “system.diagnostics.process” type and invoke its “Start” method – which leads to the arbitrary command execution. Mitigating the vulnerabilities with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against these two Remote Code Execution vulnerabilities. CVE-2020-1178 can be mitigated by existing Server-Side request forgery signatures, and also by a dedicated signature recently released to mitigate the vulnerability. Figure 6: CVE-2020-1178 Exploitation attempt blocked with attack signature 200018081 CVE-2020-1181 can be mitigated by a dedicated signature recently released to mitigate the vulnerability. Figure 7: CVE-2020-1181 Exploitation attempt blocked with attack signature 200104089
