各类组织使用云服务的前提是各家的账户都是独立的，特别是像数据库这样的高价值资产，是与其他客户隔离的。

Wiz Research在目前已被广泛使用的Azure数据库PostgreSQL服务器中发现了一系列关键漏洞。这个被称为ExtraReplica的漏洞允许对其他客户的PostgreSQL数据库进行未经授权的读取访问，绕过隔离保护。如果被利用，攻击者可能已经复制并获得对Azure PostgreSQL服务器客户数据库的读取权限。

Wiz Research于2022年1月向微软披露了 ExtraReplica。目前，微软确认该漏洞已完全缓解，Azure 客户无需采取任何行动。微软表示，他们不知道有任何利用此漏洞的企图。

根据微软的说法，该漏洞不会影响单服务器或具有显式VNet网络配置(私有访问)的服务器。在这篇文章中，我们将介绍整个攻击流程，从分析潜在的攻击面到完整的攻击，以及如何最终绕过云隔离模型。看完本文你就会知道：

1.通过识别和利用 Azure 的 PostgreSQL 服务器服务中的漏洞，在我们自己的 PostgreSQL 服务器上执行代码。

2.在服务的内部网络中执行侦察，发现我们可以访问子网中的其他客户。

3.在服务的身份验证过程中发现了第二个漏洞：由于正则表达式末尾的通配符 (.*) 导致的证书通用名 (CN) 的正则表达式验证过度允许我们登录到目标 PostgreSQL 示例使用颁发给任意域的证书。注意正则表达式末尾的错误，在此处标记：/^(.*？)\.eee03a2acfe6\.database\.azure\.com(.*)$/

通过为我们自己的域（wiz-research.com）replication.eee03a2acfe6.database.azure.com.wiz-research.com 颁发证书，我们成功访问了我们在不同租户上拥有的单独帐户的数据库，证明了跨帐户数据库访问。

4.利用Certificate Transparency(简称CT)提要来识别客户目标，最终允许我们使用前面提到的漏洞复制任何PostgreSQL Flexible Server示例(除了配置了Private access - VNet的示例)。

ExtraReplica攻击流程

我们之前在Azure Cosmos DB中发现了漏洞。我们能否在其他 Azure 服务中重现类似漏洞？

在2021年的Black Hat Europe大会上，我们展示了“ChaosDB：我们如何入侵了成千上万的 Azure 客户的数据库”，该文说明了如何通过 Azure Cosmos DB 中的一系列错误配置来不受限制地访问 Microsoft Azure 客户的数据库。在之前的研究中，我们的出发点是在内部 Azure 环境中的 Jupyter Notebook 示例上运行任意代码。我们发现 Jupyter Notebook 示例可以通过网络访问内部管理 API，从而向内部 Azure 组件打开攻击向量。

在Black Hat之后，我们想知道它是否可能成为一种模式，以及其他为客户提供专用的虚拟机(作为内部Azure环境的一部分)的托管服务是否也可以被敏感的网络组件访问。

这个方向引导我们采取以下策略来寻找我们的下一个研究目标。

我们寻找具有以下功能的新目标：

1.在内部云环境中为客户提供专用虚拟机示例的托管云服务。

2.一种允许我们执行代码的服务，可以作为服务标准功能的一部分，也可以通过新发现的漏洞执行。如果我们可以使用漏洞执行代码，我们将更有可能找到一个不那么严格的环境，因为服务开发人员可能不希望用户在那里运行他们的代码。

3.服务性质应具有很高的价值，被许多人使用，并包含敏感信息。

如上所述，我们的第一个想法是瞄准云管理的数据库服务。云服务提供商(CSP)以托管服务的形式向客户提供多种开源和商业数据库解决方案。这些数据库示例运行在CSP拥有和运行的内部云环境中，通常不属于用户的云环境。此外，大多数数据库解决方案提供了执行运行系统级命令的功能，这正是我们正在寻找的。

PostgreSQL服务器几乎具有上述所有属性：它很受欢迎，包含敏感数据，而且它的所有示例似乎都在内部 Azure 环境中运行。 PostgreSQL 是一个大项目；它比其他数据库解决方案复杂且提供更多功能。

什么是Azure数据库？

PostgreSQL是一个强大的、开源的、成熟的对象关系数据库，成千上万的组织使用它来存储不同类型的数据。它以其经过验证的架构和可靠性赢得了强大的声誉。Azure PostgreSQL数据库服务器是Azure提供的四个PostgreSQL之一。它是一种完全托管的数据库即服务，可提供动态可扩展性和简化的开发人员体验。

PostgreSQL 部署选项及其优势

攻击面概述

为了了解我们的攻击面，我们运行了一组PostgreSQL查询，并收集了一些关于我们环境的信息。例如：我们的特权是什么？哪些 PostgreSQL 功能可用？等等。在了解了这些信息之后，我们得出结论，即使我们的数据库用户是PostgreSQL的高权限组azure_pg_admin的一部分，我们仍然缺乏执行本地代码所需的特定PostgreSQL权限，如下图所示：

由于缺乏权限，运行系统级的代码执行失败

这意味着我们必须找到一种方法来升级我们在PostgreSQL示例中的权限。幸运的是，我们可以参考之前关于PostgreSQL中权限升级的研究 (1, 2)。

漏洞1 ——PostgreSQL权限升级

在研究我们的示例时，我们发现Azure修改了他们的PostgreSQL引擎。Azure引入这些变化到PostgreSQL引擎很可能是为了加强它们的权限模型并添加新功能。我们设法利用这些修改中的一个漏洞来实现权限升级，允许我们作为超级用户执行任意查询。获得超级用户权限后，我们可以在示例上执行运行系统级别的命令。

虽然微软已经修复了这个漏洞，但是出于对其他可能对其PostgreSQL引擎进行了类似修改的厂商的谨慎考虑，我们现在不会透露漏洞的细节。

通过恶意SQL查询执行运行系统级代码

环境侦察

在获得在我们的 PostgreSQL 托管示例上执行任意代码的能力后，我们对环境进行了一些侦察。我们意识到我们在主要托管 PostgreSQL 进程的 docker 容器中以非特权 azuredb 用户身份运行。该容器正在运行 Ubuntu 18.04.6 LTS 的修改映像，并安装了最新的内核 (5.4.0-1063-azure)，几乎排除了使用当时已知的内核漏洞来绕过该容器的可能性。在我们的侦察过程中，我们还注意到可以从容器内部访问以下网络接口：

可从 PostgreSQL 容器内部访问的网络接口

通过查看网络接口，我们意识到容器与其主机共享一个网络名称空间。看到内部IP地址给了我们一个想法，如果通过这些内部网络接口路由，我们是否可以访问其他客户的其他PostgreSQL示例？

我们在另一个Azure帐户上创建了另一个PostgreSQL Flexible示例，并试图从我们创建的第一个数据库中访问它，通过端口5342上的内部网络接口(eth0, 10.0.0.0/23)。令我们惊讶的是，它成功了！最重要的是，即使示例的防火墙配置为拒绝所有连接尝试，它也能正常运行。我们认为这违反了预期的隔离模型，因为我们只是通过利用某种内部网络访问来连接到一个不相关的PostgreSQL示例。然而，由于我们仍然需要这个数据库的用户名和密码来执行任何有意义的运行(例如读取或修改数据)，这个漏洞的严重性仍然很低。

值得一提的是，当我们运行netstat命令时，除了5432 (PostgreSQL)，还有其他端口在所有接口(0.0.0.0)上监听。然而，当我们试图从内部子网连接到其中一些时，我们超时了。我们执行了更多的测试，包括监听任意端口并试图从另一个示例连接，但失败了。我们怀疑存在一个配置为显式允许端口5432连接的防火墙。

我们想知道，为什么允许这种联系开始？我们的示例可以通过 10.0.0.0/23 子网访问其他示例的正当理由是什么？

漏洞2——使用伪造的证书绕过跨帐户身份验证

为了探究为什么我们的示例可以在内部访问其他示例，我们决定检查设备上的两个文件：pg_hba.conf 和 pg_ident.conf。根据 PostgreSQL 文档，这些文件分别负责客户端身份验证和用户名映射。pg_hba.conf 文件定义了哪些客户端可以连接到哪个数据库、来自哪个 IP 范围、使用哪个用户名和身份验证方法。

让我们检查一下这些来自我们示例的配置文件：

pg_hba.conf：

Azure PostgreSQL Flexible Server pg_hba.conf

在第25行中，我们看到客户端可以使用标准密码身份验证(md5)从内部网络和外部网络连接到示例。此外，在第17到21行中，特殊帐户复制只能在内部网络中使用客户端证书认证进行身份验证（子网 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）。

复制用户的目的是什么？事实证明，PostgreSQL提供了一个独特的功能，允许将数据库数据从一个服务器复制到另一个服务器，从而“复制”数据库。这通常用于备份和故障转移/高可用性场景。例如，Azure将其用于其高可用性功能：

高可用性功能

如果我们能够设法以复制用户身份验证其他客户的其他 PostgreSQL 示例，我们应该能够获得他们数据库的完整副本（即复制）。

使用客户端证书进行身份验证时，PostgreSQL 会验证提供的证书是否由受信任的证书颁发机构 (CA) 签名。受信任的 CA 列表可在 SSL 证书颁发机构文件中找到。 SSL 证书颁发机构文件位置位于 PostgreSQL 服务器配置中的 ssl_ca_file 字段下。

指向 ca.pem 的 SSL 配置，可以在 postgresql.certoverrides.conf 中看到

通过检查此文件，我们了解到 Azure 信任多个 CA 的证书，其中一个是 DigiCert。 DigiCert 是著名的根证书颁发机构和 SSL 证书颁发机构，为个人和开发人员以及企业提供服务。

Azure PostgreSQL服务器支持的受信任的证书颁发机构列表

Azure使用了另一个PostgreSQL功能来验证证书的通用名称(CN)。这就是pg_identity .conf的作用。

pg_identity .conf文件是对pg_hba.conf文件的扩展。当使用身份验证方法(如Ident或Certificate authentication)时，发起连接的用户名可能与需要连接的实际用户名不同。在这种情况下，将应用用户映射以将连接用户与相应的 PostgreSQL 用户匹配。这允许将通用名称 (CN) 链接到特定用户。例如，具有签署到 alice.com 的证书的用户将能够以 Alice 的身份进行连接，或者具有签署到 bob.com 的证书的用户可以以 Bob 的身份进行连接。 pg_ident.conf 还支持更复杂的通用名验证的正则表达式。

这是 Azure 中的 pg_ident.conf 配置：

检查pg_identity .conf文件中指定的映射，我们注意到一些有趣的逻辑：

根据第一个条目，任何具有匹配某个正则表达式的证书CN的用户都可以使用与CN的第一部分等价的数据库用户名登录。例如，拥有签署到 azuresu.eee03a2acfe6.database.azure.com 的证书的用户将能够使用 azuresu 用户连接到复制数据库。

根据第二个条目，复制用户可以使用等于 rl.eee03a2acfe6.prod.osdb.azclient.ms 的证书 CN 值登录（这对于我们的示例来说似乎是唯一的）。

此外，第一个条目还允许复制用户登录，因为它的用户名也与正则表达式匹配 (replication.eee03a2acfe6.database.azure.com)。

眼尖的读者会注意到这个正则表达式的一些奇怪之处：

为什么这个正则表达式以 (.*) 结尾？这显然是一个错误。我们是否可以注册一个匹配这个正则表达式的域，例如replication.eee03a2acfe6.database.azure.com.wiz-research.com，为其生成一个客户端证书，然后通过模拟复制用户使用它来登录我们的服务器。

要利用这个松散的正则表达式，我们必须做的就是访问 digicert.com 并向 replication.eee03a2acfe6.database.azure.com.wiz-research.com 颁发证书。由于我们是 wiz-research.com 的合法所有者，我们通过了验证过程并成功获得了客户证书。在实践中，我们最终从 RapidSSL（DigiCert 的中间 CA）购买了证书，因为我们发现该过程更容易。这就是我们如何为我们自己的示例伪造一个有效的 SSL 客户端证书，任何人都可以使用它来连接和复制我们的数据库。

访问其他客户的数据库

到目前为止，我们只讨论了登录到我们自己的PostgreSQL示例。我们如何应用这个技巧来获得对其他客户示例的访问？让我们再看看pg_identity .conf文件中的正则表达式：

我们可以看到，每个数据库示例都有一个惟一的标识符。要为特定的数据库生成自定义证书，我们需要事先知道这个标识符。那如何获得这些信息？

我们发现，数据库的唯一标识符出现在服务器的SSL证书中。通过尝试使用SSL连接内部网络中的其他数据库，我们可以检索它们的SSL证书，并提取子网中每个数据库的惟一标识符。

测试到随机客户示例的连接，以检索标识符

在发现目标数据库的唯一标识符之后，我们可以颁发一个新的客户端证书，但这一次是使用目标的标识符replication.ebe6ed51328f.databasee.azure.com.wiz-research.com，并使用它连接到目标数据库，它具有完全的读取权限。

但是，如果我们不想将自己局限于碰巧共享我们子网的其他客户呢？如果我们想从特定目标数据库（假设我们知道它的域名）中检索数据，例如 wizresearch-target-1.postgres.database.azure.com，该怎么办？在这种情况下，我们可以通过在公共证书透明度提要中搜索数据库域名来获取具有唯一标识符的 CN：

使用crt.sh识别包含唯一标识符的CN

一旦我们有了标识符，我们就可以购买一个伪造的普通名称的证书：

购买的伪造证书

接下来，我们可以通过解析数据库域找到目标示例的相关Azure区域，并将IP地址匹配到Azure的一个公共IP范围：

SQL East US区域的IP范围片段

最后，我们可以在与目标相同的区域中创建由攻击者控制的数据库，并将其作为利用我们发现的漏洞的切入点，并获得对我们所寻找的数据的访问权限！

步骤总结

1.选择一个目标 PostgreSQL Flexible Server。

2.从Certificate Transparency 提要中检索目标的公用名。

3.从DigiCert或DigiCert中级证书颁发机构购买一个特别制作的证书 。

4.通过解析数据库域名并将其与Azure的一个公共IP范围匹配，找到目标的Azure区域。

5.在目标的Azure区域中创建一个攻击者控制的数据库。

6.利用攻击者控制的示例上的漏洞1来升级特权并获得代码执行。

7.扫描子网查找目标示例，并利用漏洞2获得读取权限限！

影响

最初的PostgreSQL漏洞(漏洞1)同时影响了Azure PostgreSQL服务器和Azure PostgreSQL单一服务器。然而，Single Server服务没有受到跨帐户身份验证绕过漏洞(漏洞2)的影响，因此，我们无法在该服务中实现跨租户访问。此外，微软的调查发现，跨帐户认证绕过并没有影响Azure PostgreSQL客户，他们将数据库的网络设置配置为使用私有访问(VNet Integration)。因此，Azure Database for PostgreSQL Flexible Server客户在任何配置了公网访问的地区，无论防火墙规则如何，都是易受攻击的。

需要注意的是，在设置Flexible Server数据库时，用户需要将其网络连接配置为公共访问(默认选择)或私有访问(VNet Integration)。选择后就不能更改。

本文翻译自：https://www.wiz.io/blog/wiz-research-discovers-extrareplica-cross-account-database-vulnerability-in-azure-postgresql/如若转载，请注明原文地址