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.