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
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
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
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 invoking the “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 lead to 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