图片在 BlueHat IL 2023 上，我们自豪地宣布在 Azure 中发现了一个新漏洞，我们将其称为“Super FabriXss”。在我们的PPT中，我们演示了如何通过滥用“指标”选项卡并在控制台中启用特定选项（“群集类型”切换）将 Azure Service Fabric Explorer 中反射型 XSS 漏洞升级为未经身份验证的远程代码执行。有关完整攻击，请阅读下面的内容。
Super FabriXss （CVE-2023-23383） 是 Orca Research Pod 发现的一个危险的跨站脚本 （XSS） 漏洞，会影响 Azure Service Fabric Explorer （SFX）。此漏洞允许未经身份验证的远程攻击者在 Service Fabric 节点上托管的容器上执行代码。
Orca Security 立即向 Microsoft 安全响应中心 （MSRC） 报告了该漏洞，后者调查了该问题，并将其命名为 CVE-2023-23383 （CVSS 8.2），严重性为“重要”。Microsoft发布了一个修复程序，并将其包含在 2023 年 3月的周二补丁中。
我们要感谢 Microsoft 的合作和及时响应，以及他们为发布漏洞补丁所做的辛勤努力。
在这篇博文中，我们将探讨如何找到 Super FabriXss 的细节、它带来的风险，并就如何缓解漏洞提供建议。
摘要
- Orca Security 在 Azure Service Fabric Explorer （SFX） 中发现了一个危险的跨站点脚本 （XSS） 漏洞，我们将其命名为“Super FabriXss”，并被 Microsoft 分配为 CVE-2023-23383。
- Super FabriXss 漏洞使远程攻击者能够利用 XSS 漏洞在 Service Fabric 节点上托管的容器上实现远程代码执行，而无需进行身份验证。
- 最初是发现一个 XSS 漏洞，该漏洞允许恶意脚本从 Web 应用程序反射出来，在单击构建的恶意 URL 并切换“事件”选项卡下的“群集”事件类型设置后，最终变成了一个完整的远程代码执行 （RCE） 漏洞。
- 使用 Service Fabric Explorer 版本 9.1.1436.9590 或更早版本的组织容易受到此 CVE 的攻击。Microsoft 在其 2023 年3月的星期二补丁中包含了针对此漏洞的补丁。如果应用了自动更新，则无需进一步操作。
- 这是 Orca 在 Azure Service Fabric Explorer 中发现的第二个 XSS 漏洞。第一个叫做FabriXss。由于第二个更危险，我们决定将其称为“Super FabriXss”。
FabriXss？听起来很熟悉
如果“FabriXss”这个名字听起来很熟悉，那是因为这是 Orca 在 Azure Service Fabric Explorer 中发现的第二个 XSS 漏洞。但是，与第一个漏洞不同的是，此漏洞更加危险。借助 Super FabriXss，未经身份验证的远程攻击者可以在其中一个 Service Fabric 节点上托管的容器上执行代码。这意味着攻击者可能会获得对关键系统的控制权并造成重大损害。
关于 Super FabriXss 漏洞
Orca 在 Azure Service Fabric Explorer 中发现了一个严重漏洞，我们可以通过向任何 Azure Service Fabric 用户发送构建的 URL 来利用该漏洞。该漏洞源于易受攻击的“节点名称”参数，可利用该参数在用户上下文中嵌入 iframe。然后，此 iframe 从攻击者控制的服务器检索远程文件，最终导致执行恶意 PowerShell 并反弹 shell。此攻击链最终可能导致在部署到群集的容器上远程执行代码，从而可能允许攻击者控制关键系统。
发现和修复时间线：
- Orca 于 2022 年 12 月 20 日通过 MSRC VDP 向 MSRC 报告了该漏洞
- MSRC 于 2022 年 12 月 31 日开始调查该问题
- MSRC 和 Orca 于 2023 年 1 月 1 日讨论了该漏洞及其影响
- MSRC 和 Orca于 2023 年 2 月 8 日讨论了此攻击过程
- MSRC 于 2023 年 3 月 14日 将 CVE-2023-23383 分配给该漏洞
- 修复包含在 Microsoft 2023 年 3 月 14 日的星期二补丁中
什么是 Azure Service Fabric Explorer
Microsoft Azure Service Fabric 是一个分布式系统平台，支持大规模打包、部署和管理无状态和有状态微服务和容器。它与 Windows 和 Linux 操作系统兼容，可以部署在任何云、数据中心甚至个人笔记本电脑上，支持跨地理区域。
Super FabriXss 是 Azure Service Fabric Explorer 版本 9.1.1436.9590 及更早版本上存在的危险漏洞。
我们对 Super FabriXss 漏洞的概念验证
对于我们几个月前发现的 FabriXss 漏洞，Linux 和 Windows 群集都容易受到Xss的攻击，方法是利用旧仪表板中的 ComposeNewDeployment 函数。但是，SuperFabriXxs 漏洞仅存在于 Windows 群集中。下面我们描述漏洞利用的步骤。
步骤 1：创建 Azure Service Fabric 群集
首先，我们使用 Windows Server 2016 创建新的 Azure Service Fabric，并将容器作为主要集群操作系统。集群准备就绪后，我们可以直接进入它并查看新的仪表板。
与之前的 Service Fabric Explorer（SFX）仪表板类似，新的仪表板已针对 FabriXss 漏洞 CVE-2022-35829 进行了修补。但是，它的不同之处在于我们不再能够在旧的 SFX 和新的 SFX 之间切换。
图片正如我们所看到的，没有在旧 UI 和当前 UI 之间切换的选项——
图片查看我们的节点列表，我们可以看到我们当前正在运行 6 个Windows节点。
图片当您单击仪表板中的某个节点时，它会将您带到一个独立的节点仪表板，其中包含有关该特定节点的信息。此仪表板有三个主要选项卡：
- 要点：节点当前状态和运行状况的高级概述。
- 详细信息：有关节点的更多详细信息，例如其 ID、负载指标、当前状态和正常运行时间状态。
- 事件：显示与节点上正在执行的事件相关的各种指标。
Super FabriXss 则位于“事件”选项卡中。
步骤 2：观察节点名称更改
我们注意到，当 Node 名称在 UI 中修改时，它会反映在 Node 的独立仪表板中。这种行为使我们能够观察服务器如何处理不同变量的不存在和/或修改的值。
图片例如，我们可以通过将节点的名称更改为 OrcaPOC 并刷新页面来演示这一点。我们可以看到，我们的节点现在被称为 OrcaPOC，但没有提供有关该节点的有效或现有信息。绿色运行状况旁边显示一个空白区域，与前面屏幕截图中显示的有效名称形成鲜明对比。
图片因此，既然我们知道我们的名字在页面上展示，下一步就是尝试插入一个常见的 HTML 注入或跨站点脚本 （XSS） 有效负载，例如：
图片好的，到目前为止没有什么不寻常的，H1 标签没有以任何不寻常的方式呈现。这也可以通过查看页面元素来验证：
图片第 3 步：切换群集选项
在不同选项卡之间切换会显示新功能，这些功能可能会对节点新插入的名称产生影响，或者可能根本没有影响。
单击“事件”选项卡将向我们展示与我们在其他两个选项卡中收到的完全相同的输出，但是“节点指标”呢？如果一个事件将发生或由节点执行，那么名称如何展示（如果有的话）呢？
图片单击“事件类型”可显示两个不同的选项：“集群”和“修复任务”
图片当我们测试并单击两个不同的选项时，我们惊讶地发现，由于 HTML 中 <h1> 标记的影响，单击“Cluster”会导致新标题显示为大标题。
图片这是一个有趣的结果，因为它现在让我们走上了一条新的道路，最终将导致 RCE。
我将通过提供触发警报框的 Javascript 有效负载来验证相同的标记转义 ter Event Type，我们就会触发渲染的 JS 有效负载，生成一系列事件，这些事件将导致远程代码执行。
我将通过提供触发警报框的 Javascript 有效负载来验证相同的标记转义
图片我将对有效负载进行编码，并组合最终 url –
图片因此，现在，当输入任何经过身份验证的用户时，无论是管理员还是具有适当权限的低权限用户单击 URL，都可以引导他启用“事件”选项卡下的“群集事件类型”！
图片在下面的屏幕截图中，很明显 <img> 标记成功绕过了封闭的 <div> 标记，表明现在可以执行它了。这演示了我们如何设法逃出 <div> 。
图片第 4 步：将 XSS 用于 RCE
在发现 FabriXss 漏洞后，我意识到如果将 XSS 与其它漏洞组合，可能会获得更好的结果，这涉及嵌入一个 iframe，该 iframe 允许攻击者利用受害者的权限来执行所需的操作。但是，这次我们有一个不同的目标：在集群节点托管的容器上获得执行命令权限。
为了实现这一点，我们必须确定可以利用的 Service Fabric 的特定功能。经过多次测试和数小时的文档阅读，我们最终发现了一个漏洞，可以让我们实现目标。
图片Start Compose Deployment Upgrade 是通过 POST 请求发送的，其目的（顾名思义）是升级（即覆盖）现有的 Compose Deployment。这让我豁然开朗。查看必需的参数，我们可以看到它需要一个名为 ComposeDeploymentUpgradeDescription 的关键参数。
图片为了正确发送恶意payload，我们需要了解ComposeDeploymentUpgradeDescription 所需的属性到底是什么：
图片启用所述攻击方案的关键元素是 ComposeFileContent。此对象包含 Docker Compose 创建的新部署的规范，而 Docker Compose 又基于 Dockerfile。在此攻击中，ComposeFileContent 被修改为引用由攻击者控制的新 Docker 镜像。
攻击者使用包含 CMD 指令的 Dockerfile 创建此映像，该指令将在构建映像时执行。CMD 指令下载一个恶意 .bat 文件，其中包含以特定方式编码的 PowerShell payload。然后，此bat文件将在后续的dokcerfile指令中被执行。
此攻击的目的是将合法的 Compose 部署（在此示例中，假设它是一个 IIS 应用程序）替换为攻击者的容器。攻击成功后，攻击者将获得对具有反向 Shell 的自定义容器的访问权限，这使他们能够远程执行命令，并可能控制托管容器的整个群集节点。
以下工作流程图说明了该过程 -
图片在上图中，演示了这种攻击，该攻击涉及将构建的 URL 发送到Service Fabric 管理员。此 URL 包含一个 iframe，该 iframe 使用简单的POST请求来触发 Compose 部署的升级，在本例中为 IIS 应用程序。可以在 Service Fabric 仪表板中看到升级过程，完成后，应用程序将具有新名称，例如“iisupgraded”。
攻击分为两个主要阶段：
- 一旦嵌入 iframe 并触发POST请求，攻击者的代码就会利用升级过程，用新的恶意部署覆盖现有部署。此新部署在其 Dockerfile 中包含一个 CMD 指令，该指令将下载远程 .bat 文件。
- 下载 .bat 文件后，将执行该文件，进而生成一个反向shell。此反向 shell 允许攻击者远程访问目标系统，并可能控制托管容器的群集节点。
值得注意的是，此攻击利用了 Service Fabric 平台中“事件”选项卡下的“群集类型切换”选项，该选项允许攻击者通过使用 XSS 漏洞中特制的URL触发升级来覆盖现有的 Compose 部署。通过以这种方式控制合法应用程序，攻击者可以将其用作发起进一步攻击或访问敏感数据或资源的平台。
阅读原文
