Microsoft SharePoint and Microsoft Exchange December 2020 Security Update
Microsoft recently published its monthly security bulletin. Among all products we found Microsoft Exchange and Microsoft SharePoint security updates relevant for Advanced WAF customers, and those will be the ones we will be discussing in this post. For Microsoft SharePoint 5 distinct CVEs were published. At the moment there are no public details available regarding the exploitation of any of those vulnerabilities. We are currently in the process of analyzing those vulnerabilities and we are also actively monitoring them for new published information. Figure 1: December 2020 Microsoft SharePoint CVEs For Microsoft Exchange 6 new CVEs were published, while 3 of them already have a public proof of concept exploit available. Figure 2: December 2020 Microsoft Exchange CVEs * Signatures released in recent im ASM-SignatureFile_20201213_185938.im CVE-2020-17141 This is an External XML Entity (XXE) vulnerability discovered by Steven Seeley (mr_me). The root cause of this vulnerability is located in the “ParseComplaintData” function which is accessible by sending an XML that contains a “RouteComplaint” section to the Exchange web service. Figure 3: CVE-2020-17141 Exploit request The malicious XML content that exploits the XXE vulnerability is sent to the server encoded as base64. Once the server receives this request it decodes the base64 content, creates a new XmlDocument object and loads it with the user supplied data. Figure 4: ParseComplaintData method creates an XmlDocument object and loads it with the user supplied XML When stepping into the LoadXml function call we can see that the XmlTextReader that is responsible for parsing the XML has its“DtdProcessing” attribute set to “Parse”, which means Document Type Declaration (DTD) found in the XML will not be ignored, which leads to the XXE vulnerability. Figure 5: DtdProcessing is set to “Parse” When parsing the DTD that exists in the user supplied XML the server will leak the requested file to the external server specified by the user. Figure 6: win.ini leaked to external server Advanced WAF customers under any supported versions are protected against this vulnerability by a dedicated signature added to mitigate it. Figure 7: Exploit attempt blocked by signature 200018120 CVE-2020-17143 This is vulnerability was also discovered by Steven Seeley, This time the exploit proof of concept chains a Server-Side Request Forgery (SSRF) vulnerability with an XXE vulnerability that leaks file to external server. The vulnerable functionality is the “GetWacIframeUrlForOneDrive” which is accessible through another web service Micorosft Exchange exposes. This web service method will receive a parameter named “EndPointURL” specified in the “X-OWA-UrlPostData” header. Figure 8: CVE-2020-17143 Exploit request This request will trigger the SSRF part of the vulnerability in Exchange by forcing it to send a GET request to a user-controlled endpoint. Figure 9: GET request sent by Exchange to a user-controlled endpoint Then similarly to CVE-2020-17141 Exchange creates a new XmlDocument object and loads it with the response data it received from the GET request, which triggers the XXE vulnerability. Once again when stepping into the XmlDocument.Load function call we could see that DtdProcessing is set to “Parse”. Figure 10: DtdProcessing attribute of the XmlTextReader is set to Parse Advanced WAF customers under any supported version are already protected against this vulnerability as the exploit attempt is detected by a dedicated signature recently released to mitigate it. Figure 11: Exploit attempt blocked by signature id 200018103 CVE-2020-17144 This vulnerability, which affects Microsoft Exchange 2010 customers, exploits a machine learning functionality implemented by Microsoft to automatically tag emails in the user’s mailbox. Exchange allowed users to update the machine learning model by invokingthe “CreateUserConfiguration” web service and supplying it with a Base64 encoded and serialized .NET assembly which will then be unsafely deserialized by the Exchange server, and eventually leadto arbitrary code execution. Figure 12: Exploit request sending serialized .NET assembly to the CreateUserConfiguration Web Service Advanced WAF customers under any supported version are already protected against this vulnerability as the exploit request will be detected by a dedicated signature recently released. Figure 13: Exploit request blocked by signature id 200104646 Additional References https://support.microsoft.com/en-us/help/4486753/security-update-for-sharepoint-enterprise-server-2016-dec-8-2020 https://support.microsoft.com/en-us/help/4593465/description-of-the-security-update-for-microsoft-exchange-server-2019Microsoft 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
