.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
各類組織使用雲服務的前提是各家的賬戶都是獨立的，特別是像數據庫這樣的高價值資產，是與其他客戶隔離的。
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)。選擇後就不能更改。