嵌入载荷与绕过微软InfoPath控制

最近在浏览SharePoint实例时，我发现了一个有趣的URL，格式为：https://<server>/_layouts/FormServer.aspx?XsnLocation=https://<server>/resource/Forms/template.xsn。该页面显示了一个向SharePoint提交数据的Web表单。出于对.xsn扩展名的好奇，我下载了该文件并开始研究，发现这是微软InfoPath的模板格式。在此过程中，我发现了规范中的某些部分，允许加载远程载荷、绕过警告对话框以及其他有趣的行为。

微软InfoPath是什么？

你可能有一段时间没听说过InfoPath了——它最后捆绑在Microsoft Office 2013中，但继续为Office 365订阅用户提供，并作为服务嵌入到SharePoint中。尽管它已被PowerApps取代，但由于微软著名的向后兼容性，它将继续享受延长支持直至2026年。简而言之，预计InfoPath将继续出现，尤其是在大型企业环境中。

InfoPath允许用户设计（保存为.xsn文件）和填写表单。此外，根据维基百科，InfoPath支持广泛的交互功能：

• 事件处理程序的规则
• 数据验证
• 条件格式
• ActiveX控件
• XPath表达式和函数
• 外部数据源，如SQL、Microsoft Access和SharePoint
• JScript、VBScript、Visual Basic、C#和其他语言
• 自定义HTML任务窗格
• SharePoint集成
• 用户角色

所有这些功能创造了一个隐藏和利用的兔子洞迷宫，但InfoPath实现了一个相当健壮的三层安全级别模型：受限、域和完全信任。每个级别具有不同程度的权限，受限表单无法执行任何托管代码（C#、VBA），而完全信任表单能够执行任何代码。同时，域级表单仅限于该表单的已定义发布域（例如，发布到特定SharePoint URL的表单）和由Microsoft Internet Explorer定义的安全区域。

此外，典型的变通方法如P/Invoke和加载非托管代码被阻止；危险的ActiveX控件和没有AllowPartiallyTrustedCallersAttribute的托管代码程序集需要完全信任的表单或根本无法加载。这对红队来说是个问题，因为完全信任的表单需要签名并会产生警告提示。Obscurity Labs的InfoPath网络钓鱼文章没有绕过这一点，而是依赖于欺骗自签名证书的作者名称。

然而，我更感兴趣的是寻找安全模型的绕过方法。

绕过托管代码警告

我发现的一个有趣的绕过方法与托管代码警告对话框有关。每当表单包含托管代码（C#、VBA）时，会弹出以下对话框，必须在执行代码前接受：

域级表单仍然可以执行托管代码，但不能使用危险的程序集如System.Diagnostics.Process，不过仍然可以通过Microsoft.Office.InfoPath.LoginName属性泄漏用户名和计算机名等信息。因此，最好能在不触发烦人对话框的情况下做到这一点。为此，有必要深入研究.xsn格式的结构。

与其他Microsoft Office格式（如.docx，本质上是包含XML清单和资源的ZIP文件）不同，.xsn文件是CAB压缩文件。CAB解压缩后得到以下内容：

• manifest.xsf：描述表单的清单文件。
• myschema.xsd：数据源和字段模式
• template.xml：表单模板示例
• sampledata.xml：表单数据示例
• 资源文件：表单中包含的其他资源文件

当向表单添加托管代码时，manifest.xsf将编译的DLL引用为rootAssembly文件类型：

1
2
3
4
5

<xsf:file name="Form_Calc.dll">
    <xsf:fileProperties>
        <xsf:property name="fileType" type="string" value="rootAssembly"></xsf:property>
    </xsf:fileProperties>
</xsf:file>

反过来，Form_Calc.dll被原样捆绑到CAB中。

清单还明确声明了表单中托管代码的存在：

1
2
3
4
5
6
7

<xsf:extension name="SolutionDefinitionExtensions">
    <xsf2:solutionDefinition runtimeCompatibility="client server" allowClientOnlyCode="no">
        <xsf2:offline openIfQueryFails="yes" cacheQueries="yes"></xsf2:offline>
        <xsf2:managedCode projectPath="C:\Users\IEUser\Documents\InfoPath Projects\Form-Calc1\Form-Calc.csproj" language="CSharp" version="15.0" enabled="yes"></xsf2:managedCode>
        <xsf2:server formLocale="en-US" isPreSubmitPostBackEnabled="no" isMobileEnabled="no"></xsf2:server>
    </xsf2:solutionDefinition>
</xsf:extension>

有趣的是，通过将xsf2:managedCode节点中的enabled属性翻转为no，代码现在无需点击警告对话框即可执行！不确定这是业务逻辑错误还是延迟弹出…

无发布位置

创建域级表单模板时，InfoPath在清单中指定publishUrl属性：

1

<xsf:xDocumentClass solutionFormatVersion="15.0.0.0" solutionVersion="1.0.0.3" productVersion="15.0.0" requireFullTrust="yes" publishUrl="C:\Users\IEUser\Desktop\Form-Calc.xsn" name="urn:schemas-microsoft-com:office:infopath:Form-Calc:-myXSD-2022-05-25T14-32-18" ...>

这用作域安全控制的一部分，将表单限制在publishUrl指定的位置。例如，如果在指定位置之外打开域级表单，将出现以下错误。

奇怪的是，对于某些类别的表单（例如，没有托管代码但包含JScript等脚本的表单），只需删除清单中的整个publishUrl属性，域级表单仍然可以打开而不会触发此错误。这使得更容易交付更高权限的域级表单，而无需回退到低权限的受限表单。

在自定义任务窗格中打开任意文件

InfoPath填充模式表单（即那些旨在在桌面上填充而非发布到SharePoint或Web的表单）的一个非常有趣的功能是它们对自定义任务窗格的支持。这些表面上是用户可以嵌入到InfoPath侧面板中的自定义HTML文件，随表单自动打开。可以使用远程和嵌入的URL。例如，将任务窗格位置设置为https://evil.com：

将在填充视图中按原样显示站点。

然而，对于远程URL，这也会触发远程连接警告。

这可以通过引用嵌入的资源文件轻松避免。

有趣的是，尽管GUI和文档只允许嵌入.html文件，但我可以直接编辑清单中xsf:taskpane节点的href值以引用非HTML文件！自定义URI也受支持。

1

<xsf:taskpane caption="test" href="calc.exe"></xsf:taskpane>

由于任务窗格在Internet Explorer引擎（RIP）中打开，我还可以运行.hta和JScript，以及可执行文件。对于非默认的IE文件，这将提示典型的运行/保存对话框。即使在Windows 11中，这也有效，因为任务窗格使用Internet Explorer引擎而不是浏览器本身，后者仍然保留用于此类兼容性场景。随着Internet Explorer逐渐退出，这增加了JScript引擎或类似组件中出现老式内存损坏漏洞的可能性。因此，除了作为交付可执行载荷的便捷方式外，还有可能交付无点击漏洞利用。

Follina呢？

在所有这些关于嵌入自定义URL和HTML文件的讨论中，你可能会想知道ms-msdt自定义URI/Follina漏洞是否可以在这里使用。不幸的是，当我测试时，它不再有效——也许是因为InfoPath没有像Word等其他Office应用程序那样为ms-msdt内置相同的自定义URI白名单。尽管如此，鉴于能够使用自定义任务窗格嵌入自定义URI和HTML文件，类似攻击的大门仍然敞开。

又一种载荷交付机制

实验InfoPath发现了几种我可以利用来交付载荷或执行代码的方式。虽然三层安全模型抵抗了幼稚的攻击，但我找到了直接调整清单以触发有趣行为的方法。鉴于像OLE这样的嵌入资源和向后兼容性继续困扰Microsoft Office产品，我认为实验看似已弃用的产品以发现僵尸漏洞和小工具是有用的。