权限滥用风险：攻击者如何通过 Power Apps 渗透本地服务器
Microsoft 的 Power Platform 服务提供了一个低代码/无代码 (LCNC) 平台，包括分析 (Power BI)、网站开发 (Power Pages)、虚拟代理 (Power Virtual Agent) 和一种“完整应用程序”开发能力 (Power Apps)。这类平台能够让技术背景较弱的业务用户具备创建解决方案的能力，而这类解决方案在传统模式下，往往需要具备编程经验的专业技术开发人员才能实现。
虽然 LCNC 平台可以成为业务用户的强大工具，但平台开发人员必须注意每一步的安全性。业务用户没有正式编程经验，可能不具备与现代软件开发人员相当的安全意识。这会增加在这些 LCNC 平台中引入用户错误配置的可能性。
在本篇博客中，我们将详细剖析：2022 年，IBM X-Force Red 威胁模拟团队如何将当时普遍存在的用户配置错误，与微软 Power Apps 平台中至今仍未修复的安全绕过漏洞相结合。这一攻击组合使 IBM X-Force Red 成功突破加固后的外部边界防护，在本地部署的 SQL 服务器上获取代码执行权限，最终导致整个 Active Directory 域被完全攻陷。
2022 年时，Power Apps 的默认行为设定为：当某款 Power Apps 应用被共享给其他用户时，其关联的所有连接也会随之共享。这导致用户极易出现误操作：原本仅打算共享前端应用，却意外将连接信息共享给了组织内所有用户。据 Microsoft 说明，该默认行为已于 2024 年 1 月完成调整，大幅降低了用户意外共享连接信息的风险。
然而在 2022 年，IBM X-Force Red 发现了一个通过“本地数据网关”连接至本地 SQL 服务器的 SQL 连接，该连接正是通过上述方式被广泛共享的。尽管 Power Apps 流程中并不支持对本地 SQL 服务器执行原生 SQL 查询，但 X-Force Red 发现，借助“使用 Power Query 转换数据”这一操作，可向本地服务器发起原生 SQL 查询。这一发现使 X-Force Red 成功横向移动至本地 SQL 服务器，并最终达成了此次测试任务的全部目标。
此错误最近已报告给 Microsoft 安全响应中心 (MSRC)，其被评定为低严重级别，因此我们现公开相关技术细节。
增强安全情报
每周在 Think 时事通讯中获取有关安全、AI 等的新闻和洞察分析，从而预防威胁。
Power Apps 允许用户通过 LCNC 平台特有的拖拽式 GUI 创建“应用程序”和“流程”。应用程序用于构建前端应用，这类应用的核心功能通常是从数据源提取数据并向用户展示。下面是 Microsoft 下图是微软提供的 Budget Tracker 演示应用，其功能是从 Excel 电子表格中读取数据并呈现给用户。
Power Apps 的另一核心功能是“流程”，对于曾使用过 Azure Logic Apps 等其他 LCNC 服务的用户而言，这一功能会十分熟悉。流程允许用户创建类流程图的程序，其核心用途通常是拉取数据、处理数据，再将数据发送至目标位置。下图是一个极为基础的流程示例：发起 HTTP 请求后，解析返回的 JSON 数据。
Power Apps 提供了一套“连接器”组件，用户无需依赖大量 HTTP 请求操作，即可完成数据接入、发送邮件等任务。这些连接器大多是预构建的 HTTP 请求库，但会向用户屏蔽所有技术细节。若要获取 Entra ID 用户的相关信息，你无需手动构造 Graph API 的 HTTP 请求，只需接入 Entra ID 连接器并调用“获取用户”操作即可。
Power Apps 为众多主流服务提供了专属连接器，涵盖微软自家服务及第三方产品。你可从 SharePoint 读取文件、通过 Adobe PDF Services 将文档转换为 PDF 格式，或重启 Azure 中的虚拟机。当你创建连接时，系统会根据你要接入的服务类型，提示你提供相应的认证凭证。对于几乎所有与 Microsoft 相关的服务，你只需通过自己的 O365 账号完成身份验证即可。
说明：在本文后续内容中，我将用“连接器”指代 Power Apps 中的动作库（例如：Entra ID 连接器）；用“连接”指代已由用户创建并完成认证的连接器实例（例如：以 john.smith@contoso.com 身份认证的 Entra ID 连接），此类连接可用于创建新的操作。
只要该连接处于存续状态，你的身份验证信息就会与其绑定。任何获得该连接访问权限的用户，都能创建新操作并复用你的身份验证权限。举例来说，若你创建了一个 Entra ID 连接，其他获得该连接访问权限的用户，即便本身不具备在 Entra ID 中执行“添加用户至群组”操作的权限，也可通过该连接创建这一操作，且该操作会沿用你的身份验证权限来执行。我此前曾在博客中阐述过在 Azure Logic Apps 中对此类机制的滥用方式，还基于这一功能找到了一个可行的 Azure Logic Apps 权限提升漏洞利用方法。
2024 年之前，此类攻击在 Power Apps 中发生的概率要高得多。过去，当你共享一个使用了某连接的应用程序时，对应的连接也会随之被共享。Microsoft 官网有一篇 2022 年之后就未再更新的文档对此机制有所记载。不过，根据 2024 年发布的另一篇文档显示，如今这一情况已不复存在。现在，只有当连接单独共享至你的账号时，你才能使用该连接，这种情况下出现配置失误的概率大幅降低。这一机制变更或许源于 Michael Bargury 在 2023 年黑帽大会上发表的《万事俱备，只需访客账号》主题演讲，这篇精彩的演讲还探讨了 Power Apps 中的信息枚举与信息导出等安全相关内容。
若你需要访问互联网上无法获取的数据，该怎么办？若你需要从本地 SQL Server 访问数据，该怎么办？Microsoft 已经考虑到这一点，并创建了本地部署数据网关。网关需安装在本地主机上，其核心作用相当于一个代理，使 Power Apps 连接器能够与本地资源进行通信。若要访问本地部署的 SQL Server，你只需在该 SQL Server（或其他服务器，甚至在影子 IT 场景下可安装在个人工作站）上部署网关，随后即可通过 SQL 连接器向该服务器执行查询操作。
连接 SQL Server 支持六种认证方式，但并非所有方式都适用于本地部署的 SQL Server。对于本地部署，你大概率会使用 SQL Server 身份验证或 Windows 身份验证，此时需提供 AD 凭据或本地 SQL Server 凭据。
一旦你创建了连接，或获得了某个共享连接的访问权限，就可以对 SQL Server 执行一系列操作。其中最受读者关注的当属“执行 SQL Query（V2 版）”功能。
如果你不了解执行原生 SQL 查询可能带来的影响，建议阅读我的同事 Sanjiv Kawa 的博客文章，其中详细介绍了他开发的工具 SQLRecon。显然，若能在服务器上执行 SQL 查询，你便能导出所有具备访问权限的数据，倘若数据库中存储了敏感信息，这一情况可能会引发严重安全风险。但是，若你拥有 SQL Server 的访问权限，就可以在底层操作系统上执行代码。你可以通过以下几种方法实现这一目标：
- xp_cmdshell 存储过程
- OLE 自动化过程
- 执行 .NET CLR 程序集
- SQL 代理作业
这最终取决于建立连接的用户所拥有的权限，但如果你曾通过 SQL Server 达成目标，就会知道超权账户有多普遍。即便连接用户不具备代码执行权限，你也可以检查是否存在模拟权限、与其他 SQL Server 的链接，或是数据库中以明文形式存储的凭据。
然而，这一切最终都是毫无意义的，因为网关不支持“执行 SQL 查询”操作。
其他操作（例如“Get rows (V2)”）可正常运行。我们就是无法在服务器上执行任意查询。我推测这是因为 Microsoft 考虑到了被滥用的可能性，且认为向外部 O365 用户暴露本地 SQL Server 的安全隐患是不可接受的。
如果浏览 SQL 连接器的所有可用操作，你会发现“使用 Power Query 转换数据”这一功能。尽管名称中带有 “Power”，但 Power Query 并非 Power Platform 服务家族的成员。它实则是一款数据转换引擎，嵌入于 Excel 等其他服务/应用中。作为数据转换引擎，Power Query 的设计初衷是读取数据并进行转换处理，而不会修改源数据。
创建带有有效连接的“使用 Power Query 转换数据”操作后，系统会弹出一个菜单，显示该连接所指向数据库中的所有数据表。在我的测试 SQL Server 中，仅存在一个名为“Persons”的空表。
选择“转换数据”后将进入下一界面，即 Power Query 编辑器。Power Query 采用 Microsoft 开发的数据转换语言 M 公式语言。M 语言的官方参考文档中包含“数据访问函数”模块，该模块列出了可用于向 Power Query 摄入数据的各类函数。当我们在 Power Query 编辑器中打开默认查询时，会发现系统正通过 Sql.Databases 函数从已连接的数据库中获取信息。
浏览完 1394 页的 M 语言 PDF 版文档后，我发现 Sql.Database 函数包含一个可选参数“Query”。该参数的描述为“用于检索数据的原生 SQL 查询”。
若将以下 Power Query 代码粘贴至编辑器中，界面会弹出警告提示：“原生查询可能存在安全风险，并可能修改数据库”。
好家伙，修改数据库对我来说本就是家常便饭，所以点击“继续”后，我们果然成功获取到了原生 SQL 查询的执行结果。
简要回顾一下，只需拥有 Power Apps 许可权限，即可通过以下方法滥用该漏洞入侵本地 SQL Server：
- 某用户创建了一个使用本地 SQL 连接的应用，并有意或无意地将其共享给了所有用户。
- 攻击者创建新流程，通过该现有 SQL 连接添加“使用 Power Query 转换数据”操作。
- 若连接用户为 SQL 管理员、具备模拟权限，或数据库中存在高权限 SQL 链接、明文凭据，亦或是攻击者已获取其他高权限明文凭据，此时便可借助该路径横向移动至本地 SQL Server。
根据 Microsoft 2022 年最后更新的官方文档，若共享使用网关数据源的应用，网关也会随之共享。但在我的租户测试中发现，目前这一机制似乎已发生变化。尽管如此，若你已获得网关访问权限，便可通过它创建新的连接，意味着你不再受限于现有连接。当然，这要求你已获取 AD 或 SQL 账户的明文凭据，且知晓 SQL Server 的主机名；不过在 SharePoint/Confluence 等协作平台中，这类信息并不难获取。
你还可以利用其他支持网关的连接器（例如“文件系统”操作）。这同样需要你持有有效的凭据和主机名，但借助该方式，你能够对内部主机执行文件读写操作。
若获取到一个具备 Power Apps 访问权限的账户，你需要检查该账户可访问的所有环境。通过点击右上角的“环境”下拉菜单即可查看。在每个环境中，需选择“… 更多”选项，再点击“发现全部”，随后会进入一个可浏览 Power Apps 中所有资源的页面。
从该页面中，你可以选择“连接”查看所有可访问的连接，选择“网关”查看所有可访问的网关。你还能看到这些连接的所有者信息，进而判断该用户是否具备高权限。
此外，屏幕左侧是“流程”和“应用程序”按钮。你需要点击“与我共享”选项，以查看所有可访问的资源，进而开始寻找明文凭据或敏感信息。其中 HTTP 流操作是挖掘密码和 API 密钥的重点目标。
管理员应考虑限制可安装网关的用户范围；若不存在业务使用需求，可直接禁用网关功能。操作路径如下：进入 Power Apps 管理平台，选择“数据”，勾选“租户管理”选项，随后点击“管理网关安装者”。在该页面中，可启用“限制组织内用户安装网关”设置，并添加确有安装需求的用户。更多信息请参阅 Microsoft 文档。
考虑定期评估环境中的连接，并确保用户没有广泛共享敏感连接。
本文探讨了如下攻击路径：若攻击者获取到借助本地数据网关连接 SQL Server 的连接器权限，便能在该服务器上执行原生查询，进而有可能从微软 365 环境横向渗透至本地资源。此前导致这类配置失误频发的相关机制虽已于 2024 年完成调整，但攻击者只要获取到对应权限，仍有可能滥用该漏洞发起攻击。本文发布旨在提醒安全防护人员对自身运维环境展开全面审计，排查各类网关及过度共享的连接器，以此防范针对 Power Apps 的后续攻击。
2025 年 2 月 10 日：提交首个 MSRC 案例
2025 年 2 月 11 日：MSRC 认定这是一起社会工程攻击事件并结案。
2025 年 2 月 12 日：提交第二个 MSRC 案例
2025 年 2 月 24 日：MSRC 将漏洞评估为低严重程度