一、漏洞环境搭建

我简单写了一个poc，地址：https://github.com/W01fh4cker/CVE-2024-30043-XXE

我采用的是SqlServer 2019 + Microsoft Sharepoint 2019 + DC联网安装的搭建方式，也可以把前两个装一块，看个人；如果要断网安装，网上也有对应的文章。

如果你实在是太懒，那就下载我搭建好的：

链接: https://pan.baidu.com/s/1LF7GmE8ujNEXnMw2Bi8Q_A 提取码: 5grq

还是推荐自己搭建，感受过程，积累排错经验：

SharePoint Server 2019下载地址：

https://download.microsoft.com/download/C/B/A/CBA01793-1C8A-4671-BE0D-38C9E5BBD0E9/officeserver.img

SqlServer 2019在线安装工具下载地址：

https://download.microsoft.com/download/d/a/2/da259851-b941-459d-989c-54a18a5d44dd/SQL2019-SSEI-Dev.exe

SQL Server Management Studio下载地址：

https://download.microsoft.com/download/b/9/7/b97061b9-9b9c-4bc7-86de-22b262c016d1/SSMS-Setup-CHS.exe

SharePoint Designer 2013下载地址：

https://download.microsoft.com/download/3/E/3/3E383BC4-C6EC-4DEA-A86A-C0E99F0F3BD9/sharepointdesigner_64bit.exe

由于原Dnspy作者不再维护，于是可以考虑下载社区维护版：

https://github.com/dnSpyEx/dnSpy/releases/download/v6.5.0/dnSpy-net-win64.zip

Microsoft .NET Framework 4.7.2下载地址：

https://download.visualstudio.microsoft.com/download/pr/1f5af042-d0e4-4002-9c59-9ba66bcf15f6/089f837de42708daacaae7c04b7494db/ndp472-kb4054530-x86-x64-allos-enu.exe

安装完成之后，切记要先打个快照。

如果用了我的镜像，发现sp2019机器配置了NAT但是显示电缆未插入的话，说明宿主机的NAT服务没启动，需要手动启动：

管理员账户访问http://sp2019:21548/并创建站点cvetest，这部分网上也有教程，就不细说了，实在遇到问题公众号后台发私信。

二、漏洞复现踩坑

搭建完成之后我打开sp2019机器的时候，系统提示我要进行Windows更新，但是我向来是不更新的，因此就略过了，没想到这打开了我三天的漏洞复现折磨之旅。

漏洞作者Piotr Bazydło在zerodayinitiative的博客上发布了一篇poc：

https://www.zerodayinitiative.com/blog/2024/5/29/cve-2024-30043-abusing-url-parsing-confusion-to-exploit-xxe-on-sharepoint-server-and-cloud

作者开篇即说明，漏洞点位于Microsoft.SharePoint.WebControls.BaseXmlDataSource，那么我们就利用Dnspy调试看看。

打开Dnspy，点击Debug-->Attach to Process：

可以看到这个就是我们之前创建的位于80端口的站点所对应的进程，选中后点击Attach：

然后选择模块：

搜索Microsoft.SharePoint.dll并双击反编译：

找到Microsoft.SharePoint.WebControls下的BaseXmlDataSource：

然后在如下几个位置打上断点：

根据原作者的提示，我们很容易就想到利用Microsoft Sharepoint的api去上传文件，具体代码我放后面展示。

上传并访问http://sp2019/sites/cvetest/6Svab8Fl.aspx，触发断点：

看到读取我们上传的恶意xml文件内容没问题：

我们继续一步步F10，发现报错无权限：

回过头重新再来调试一遍，发现这里的PermissionSet好像不太对劲：

正常来说应该会按照作者视频里这样：

展开发现我们的m_Unrestricted属性为false：

我决定跟进XmlSecureResolver看看是什么情况，在如下位置打断点：

进入CreateFromUrl方法这里：

一步步F11的过程中我们发现，我们的file://localhostc$/sites/cvetest/6Svab8Fl.xml这个payload居然会被认为是Internet这个SecurityZone，正常来说应该是MyComputer才对：

SecurityManager里面的GetStandardSandbox中判断只有是MyComputer的时候才会有无限制的权限：

就这一点困扰了我整整三天，我确实挺郁闷，这复现过程和作者完全一致，为什么会导致PermissionSet的不同呢？

于是我询问作者，详见推文https://x.com/chudyPB/status/1790437036723249381：

作者认为可能是因为没有进行Windows安全更新的缘故，一语道破天机，于是我去更新了一下，利用成功：

切记必须是http://sp2019而不能是http://192.168.198.142这种形式，否则通过浏览器或者requests库会触发失败，只能通过SharePoint Designer去访问触发，具体的原因可以自行调试观察，这里不再赘述

三、漏洞分析（略）与总结

作者的文章中已经描述的通俗易懂了，我上面也提到了一些调试的东西。

总的来说，这个洞我只能用非常鸡肋来形容，首先你得搞到账号密码或者通过某种手段能上传文件，然后你还得确保对方系统是打了KB103723这种累计更新的补丁的，就这样你才能成功利用，并且就算可以成功利用，你也无法读取web.config这种文件，因为里面包含%亦或是#这样的特殊字符串，导致按dtd去解析实体的时候会有如下报错：

但是，咱们可以出于学习目的去进行调试分析研究，以达到触类旁通的效果，形成对这种大型框架的全局观。

如果你喜欢我写的文章，欢迎关注我的公众号，我是W01fh4cker，我们下篇见。