Microsoft Exchange April 2021 Security Update And Possible Mitigation With Advanced WAF
Thanks to@Tomer Zait and@Osher Bello for their contributions in the research and development of the iRule mitigation suggested here.---Microsoft recently published the patch Tuesday for April 2021 which revealed 4 new critical vulnerabilities for Microsoft Exchange, while two of them can be exploited by unauthenticated attackers. Figure 1: April 2021 Patch Tuesday Microsoft Exchange vulnerabilities. Currently there are no public information available regarding the exploitation of any of those vulnerabilities, but we are closely monitoring for any new information published and working to analyze the patch internally in attempt to discover new details regarding possible exploitation paths. While reviewing the patch we noticed that similar mitigation we previously saw in the patch aimed to mitigate the “ProxyLogon” vulnerability (CVE-2021-26855), as exploited in the wild by HAFNIUM APT group. Figure 2: Patch diff from the “BackEndCookieEntryParser” class adding similar mitigation as CVE-2021-26855 The check that was added is conducted on the “X-BackEndCookie” cookie, which comprised of the user SID (unique identifier of the user’s mailbox) followed by an equal sign and then an obscured base64 string. Figure 3: “X-BackEndCookie” cookie example Once we decoded the obscured base64 string we noticed that the decoded string was comprised of the following structure: [Enum Value (Can be either “Database” or “Server”)]~[Server Version in the case of “Server” Enum value or Database GUID in the case of “Database” Enum value]~[Optional resource forest]~[Expire date of the cookie] Figure 4: Decoded “X-BackEndCookie” example Our current assumption is that similar SSRF bypassing the authentication as demonstrated in the “ProxyLogon” vulnerability was possible using the “X-BackEndCookie” cookie and might be involved in the exploit path of one of the unauthenticated vulnerabilities. Mitigating the vulnerability with Advanced WAF As the “X-BackEndCookie” cookie value is an obscured base64 string, it will be difficult to mitigate it using attack signature while avoiding false positives. Thus we have created a dedicated iRule and a user-defined violation that can be used to detect and block exploit attempts. The steps for deploying the iRule and the user-defined violation are: 1.Go to Security -> Options -> Application Security -> Advanced Configuration and click on the User-Defined violations tab. Figure 5: User-Defined violations tab 2. On the top right corner click on the “Create” button, then fill in the details as shown in the image below. Figure 6: User-defined violation creation details 3.In the “Learning and Blocking Settings” page of your policy, set the custom violation created to block. Figure 7: Custom violation set to block. 4.Add the following iRule by going to Local Traffic -> iRules -> iRules list and click on the “Create” button on the top right corner. # Configuration when RULE_INIT { set ::triggerASMViolation 1 } # Decrypt cookie content proc decrypt {value} { set xorKey 0xff set decodedString [b64decode $value] set length [string length $value] set decryptedString {} foreach c [split $decodedString {}] { set decryptedChar [expr {[scan $c %c] ^ $xorKey}] lappend decryptedString [format %c $decryptedChar] } return [join $decryptedString ""] } # Check if attack sent in cookie proc test {cookie} { set badChars {[/;\n]+} if {[regexp {[A-za-z0-9\-]+=+(.*?)} $cookie match0 match1 ]} { set decryptedCookie [call decrypt $match1] if { [regexp -all $badChars $decryptedCookie] } { return 1 } } return 0; } # If ASM / ASM irules not enabled (set ::triggerASMViolation 0) when HTTP_REQUEST { if {$::triggerASMViolation} { return } foreach cookie [HTTP::cookie names] { if { [ string match -nocase "X-BackEndCookie*" $cookie ] } { if { [ call test [HTTP::cookie value $cookie] ] } { log local0. "Microsoft Exchange SSRF violation detected: Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri]" drop } } } } when ASM_REQUEST_DONE { foreach cookie [HTTP::cookie names] { if { [ string match -nocase "X-BackEndCookie*" $cookie ] } { if { [ call test [HTTP::cookie value $cookie] ] } { ASM::raise VIOL_EXCHANGE_SSRF } } } } 8.Attach the newly created iRule to your Microsoft Exchange virtual server. 9.In your ASM Policy make sure to set the "Trigger ASM iRule Events Mode" setting to "Normal" Figure 8: "Trigger ASM iRule Events Mode" setting Figure 9: User-defined violation blocking malicious request.CVE-2021-26855 (SSRF) HAFNIUM APT Group Exploiting Microsoft Exchange Vulnerabilities
Recently, Microsoft has issued an out of band patch that aims to mitigate seven Remote Code Execution vulnerabilities in Microsoft Exchange. Microsoft Threat Intelligence Center (MSTIC) has observed active exploitation of four of those vulnerabilities in the wild. Figure 1: Microsoft Exchange 0-Day vulnerabilities exploited in the wild The attacks are attributed to an APT group named HAFNIUM, which exploited those vulnerabilities mainly against targets from different industry sectors in the United States. After gaining access to the vulnerable Exchange servers HAFNIUM operators exfiltrated data like Exchange address book from the compromised server. Currently there are no public technical details on the vulnerabilities neither proof of concept exploits for those. Meanwhile we have successfully recreated the exploit flow for the insecure deserialization vulnerability (CVE-2021-26857) and we have released a dedicated attack signature for mitigating it. We will continue the analysis process for rest of the vulnerabilities, and we are closely monitoring for public POC exploits related to them. Mitigating CVE-2021-26855 and CVE-2021-26857 with Advanced WAF Advanced WAF customers under any supported version are already protected against those vulnerabilities as exploitation attempts will be detected by a dedicated signatures recently released. The signatures could be found under the "Server Side Code Injection Signatures” and "Other Application Attacks Signatures" signature sets. Figure 2: CVE-2021-26855 Exploit attempt blocked by signature id 200018127 Figure 3: CVE-2021-26855 Exploit attempt blocked by signature id 200018128 Figure 4: CVE-2021-26857 Exploit attempt blocked by signature id 200104705 Mitigating CVE-2021-26855 and CVE-2021-26857 with Threat Campaigns Advanced WAF customers with Threat Campaign license could detect and block campaigns targeting those vulnerabilities with the following Threat Campaigns: Microsoft Exchange Resource Cookie SSRF Microsoft Exchange ContactInfo Unsafe Deserialization Figure 5: CVE-2021-26855 Exploit attempt blocked by Threat Campaigns feature Figure 6: CVE-2021-26857 Exploit attempt blocked by Threat Campaigns feature Additional References https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/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-2019
Exchange IAPP F5 to F5 migration
I have an existing exchange 2010 iapp in production. Is there a method to migrate the Iapp, pools, etc. configured in that particular iapp to a seperate F5? I would like to transfer over as much information as possible instead of creating it all over again from scratch. Thanks
Exchange 2007 redirection issue
Hi, I deployed iApp template for Exchange 2013 and it works fine. But in this environment there are legacy Exchange server (2007) and Exchange 2013 server. I modified Access policy by following instructions from this video https://www.youtube.com/watch?v=xRsUqWp1Ngs. My final result is: For Exchange 2013 everything works fine. For Exchange 2007: user tries to authenticate and enters his credential, system redirect him to legacy server and logon screen shows up again. After second authentication browser tries to enter to Exchange 2007 mailbox but it get stuck there. APM logs show that the issue occures when expression user.session.exchange comes to evaluation e.g. it says: fail to authenticate. Does anyone has any advice regarding this issue? Thanks in advance.
