Cloud RedTeam視角下元數據服務攻防實踐

高瑞強，目前從事云上攻防安全相關的研究工作。

今天分享的主題是《Cloud RedTeam 視角下元數據服務攻防實踐》。

縱觀云上的攻擊事件，以及近期的一些熱點事件，大家不難發現，元數據服務攻擊事件頻繁的發生。在云產業不斷發展壯大的當今，元數據服務已經成為了攻擊者攻擊流程中的一個重要的環節。我們從攻擊者的視角來分析攻擊流程中元數據服務所面臨的風險，也可以更好地迎戰元數據服務帶來的安全挑戰。

今天分享的議題由四個部分組成。

元數據服務概覽

安全事件回顧

針對元數據服務攻擊

ATT&CK矩陣和元數據服務

給大家簡單舉一個例子，介紹一下什么叫做云服務器實例元數據。大家可以設想一下，在租用云廠商所提供的云服務器服務后，首先需要選購機型、選購地區、選購配置的時長或者是計費方式，當購買成功之后，就會為用戶生成一個云服務器的實例。

這個實例有自己的屬性，常見的可以舉例，實例ID它自身綁定了一些角色信息，也會有一些安全組信息的綁定情況，包括大家日常可見的實例，自身有內網IP、外網IP、地域信息，這些就是我們所說的云服務器實例的元數據。

那元數據是怎么查詢或者使用的呢？用戶可以通過元數據服務接口，在運行的實例內查詢實例的元數據。具體是在云服務器實例的接口上，通過元數據服務查詢的請求來查詢相應的元數據相關的數據。

在這些實例的屬性中，從攻擊者的角度來看，最關心的便是與實例綁定的角色。

角色是云廠商所提供訪問管理中的一個功能模塊，可以使用訪問管理功能中可以新建一個角色，用這個角色來管理這些或者說進行授權、進行操縱這些云資源。

各個云廠商提供角色功能，可以細粒度化的控制配置。在為這個角色配置權限之后，可以將這個角色綁定在云服務器實例上，然后在云服務器實例中就可以用到這個角色，通過它的臨時憑據，來操作這個云服務。

也就是圖上的流程圖，其實就是創建角色，配置權限以及綁定實例。同理，如果用戶想使用這個元數據的角色信息，它可以簡單的在自己的這臺實例上，通過元數據服務接口查詢即可。

那么一些市面上比較常見的云廠商，它的元數據服務接口地址到底是什么樣子的？

aws地址：

http://169.254.169.254/latest/meta-data/

Google Cloud地址：

http://metadata/computeMetadata/v1/

Azure地址：

http://169.254.169.254/metadata/instance?api-version=2017-04-02

Oracle Cloud地址：

http://169.254.169.254/opc/v1/instance/

這個地址的學名叫做鏈路本地地址，鏈路本地地址又稱連結本地位址，是計算機網絡中一類特殊的地址，它僅供于在網段，或廣播域中的主機相互通信使用；這類主機通常不需要外部互聯網服務，僅有主機間相互通訊的需求。鏈路本地地址在IPv4鏈路本地地址定義在169.254.0.0/16這個地址塊，因此大家看到所涉及的這些云廠商，地址都是鏈路本地地址。

為什么要選用這個鏈路本地地址作為元數據服務接口提供的地址？

它的特性有點如下，實例元數據服務使用鏈路本地地址提供服務；當實例向元數據服務發起請求時，該請求不會通過網絡傳輸，也永遠不會離開這一臺計算機；基于這個原理，元數據服務理論上只能從實例內部訪問。

但是從這個攻擊事件上來看，其實數據是有可能被泄露出去的。具體怎么泄露的，一起來看一個歷史上的經典案例。

大約在2019年的時候，美國的Capital One銀行發生了一起相當嚴重的數據泄露事件，北美大約有1億人受到了這次事件的影響，上億條信用卡數據、十余萬社保號碼被泄露出來。

這個事件，不僅給這個銀行的用戶帶來了沉重的打擊，也給銀行自身帶來了相當嚴重的影響，銀行的股價在收盤的時候下跌了5.9%，在兩周之內下跌了15%。

攻擊者發現，Capital One銀行的web應用部署于AWS云服務器上。此外，攻擊者發現Capital One應用程序中存在了一個SSRF漏洞。

如果在傳統的攻防中，如果一個應用存在SSRF漏洞，雖然漏洞比較嚴重，但是也并不會產生如此嚴重的影響。這個就是傳統漏洞與云上結合所帶來的更深遠的影響。

攻擊者通過SSRF漏洞發起了內網請求，然后成功地訪問到了這臺云服務器實例上的元數據服務接口，并且它通過這個接口成功地讀到了一個角色，并且通過這個角色拿到了這個角色的臨時憑據。

這個角色就是Capital One銀行在云服務器上部署了他的代碼，它很有可能也租用了亞馬遜云的對象存儲服務，就是所謂的aws存儲桶，然后他把用戶數據存在了亞馬遜云的存儲桶中。

這就導致一個問題，攻擊者拿到的這個角色，恰恰是Capital One銀行的應用程序，用來調用他在亞馬遜云上的對象存儲的角色。因此，攻擊者把這個歷史憑據保存到了本地，并且成功的把存儲桶中所有的用戶數據復制下載到本地，造成了一個相當嚴重的影響。

元數據服務風險，它存在于兩個方面，一個是平臺側、一個是用戶側。

針對于用戶側的攻擊，攻擊者通過目標部署在云服務器實例上的應用程序的漏洞。比如說SSRF、RCE、任意文件讀取等漏洞。通過這些漏洞來訪問服務器的元數據服務接口，并且獲得相應的數據用以后續的攻擊。

細化介紹一下常見的攻擊者所采用的攻擊流程。

步驟一：獲取利用點。攻擊者會使用一些常規的漏洞探測方式，比如漏洞掃描、手動測試這些方式，發現部署在云上應用中的脆弱點。

步驟二：攻擊者發現了這個脆弱點之后，他將會嘗試訪問云上的元數據服務接口，如果一旦發現這個元數據服務接口是可以訪問的，他將會嘗試獲取與實例綁定的角色名稱。

我們這里以SSRF漏洞進行舉例，看看攻擊者是如何通過SSRF漏洞獲取到與實例綁定的角色名稱。

我們假設http://x.x.x.x/?url=http://169.254.169.254/latest/meta-data/iam/info 網站上它存在一個SSRF漏洞，并且有回顯，它存在url參數，后面我們構造一個payload來訪問這個元數據服務，并且通過這個地址獲取角色名稱。

步驟三：當獲取角色名稱之后，我們通過名稱信息進一步的獲取角色的臨時憑據，攻擊者可以繼續通過SSRF漏洞來訪問元數據服務接口，獲取角色歷史憑據，通過的payload跟上一個獲得的角色名稱很類似，但是這里是相當于我們把角色名稱傳入來獲取此角色的歷史憑據。如圖所見，這個歷史憑據，也可以成功的返回回來。

這里臨時憑據，他有個特點，一般都會是TmpSecretld或者TmpSecretKey，而且他一般都跟著一個token，為什么大家的主憑據沒有token而歷史憑據有token？

因為主憑據相當于是擁有這個賬號的所有權，等同于你的賬號權限，但是臨時憑據，他需要標識這條憑據的存活時間、權限策略，所以說它有一個token用來標識憑據的這些信息。

步驟四：在獲取到角色的名字、角色的臨時憑據了，還需要猜測一下，或者說來確定一下這個角色，他的權限策略是什么？也通過這個權限策略制定后續的攻擊行為，我們怎么獲得角色的權限策略？有兩個比較常見的方式。

方式1：通過名稱初步猜測角色用途。比如說一個業務，他應用到角色來訪問存儲桶，他很有可能為角色命名和存儲桶相關的名字，比如說他用這個角色來操作云服務器，它可能會為這個角色命名一個跟云服務器比較關聯的名字，方便后續的管理和使用。

方式2：通過“訪問管理”API接口獲取角色詳情。但是有個前提，這個角色他的權限是可以操作訪問管理的權限，才可以進行這一步的操作。

步驟五：在搞清楚角色用途后，可以進行憑據后的后利用，根據角色的權限不同，可以攻擊對象存儲服務、攻擊云服務器實例、攻擊訪問管理等等。

接下來，舉幾個案例具體看一下。

第一個案例：竊取存儲桶中的用戶數據。在所有的云資源中，攻擊者往往對目標的數據更加感興趣，如果攻擊者獲取的臨時憑據擁有云數據庫服務或云存儲服務等服務的操作權限，攻擊者將會嘗試竊取目標數據 。

具體可以怎么做？還是以亞馬遜云舉例子，AWS其實提供了相應的一些命令行工具，或者說一些可視化工具用來簡化操作，攻擊者就可以借用這些工具配置臨時憑據，并且利用存儲桶工具將存儲桶的內容下載到本地。

Capital One銀行的數據泄露案例，后續官方調查取證的時候，發現攻擊者用的就是這個思路。

第二個案例：在云服務器實例中運行命令。借助通過元數據服務接口竊取到的憑據，借助AWS CLI所提供的命令行工具，攻擊者可以在實例中執行反彈shell命令，由此進入實例。

參考上圖，比如說在這個參數中配置好憑據，或者在參數中直接執行命令。

第三個案例：在云服務器實例中寫入后門。這個步驟其實是在攻擊階段中的持久化階段很有效果。云服務商一般會提供一個叫userdate的字段，或者說一個功能，其實這個功能是為了方便使用者在Windows實例也好，Linux實例也好，在它開機啟動的時候加載用戶的腳本，然后攻擊者可以通過將userdata中寫入后門，然后當實例下次重啟的時候，你到后門就可以生效，或者說就進行持久化操作。

第四個案例：利用訪問管理創建新用戶。還是通過這個憑據，我們可以通過訪問管理的功能，創建一個用戶，命名為Bob，并且為Bob創建一個權限策略，比如說他擁有管理員權限，并且復制Bob上，但是這個攻擊他會有一個前提，就是你獲取的臨時憑據，獲取的角色，他必須有相應的訪問管理的權限才可以操作。

介紹完這個用戶側的一些風險，我們接下來看產品測的一些風險，云產品中也會應用到元數據服務。因此，元數據安全挑戰也會被帶入到云產品中。

舉一個比較有代表性的案例，Web應用托管服務，Web應用托管服務是一種常見的平臺即服務產品，可以用來運行并管理web類、移動類和API類的應用程序。

還是以亞馬遜云舉例，Web應用托管服務可以讓用戶將Web應用直接上傳到托管服務中，當代碼上傳到托管服務中，Web托管服務將用戶代碼存儲到對象存儲服務中。

所以說與之前的攻擊流程相似，攻擊者也是可以利用SSRF漏洞，訪問到云服務器，通過云服務器獲取到相應的元數據，并且通過拿到的對象存儲的角色，以及對象存儲的權限來訪問存儲桶。

我們再看平臺測更多的安全風險，除了給大家介紹的aws下的安全風險，平臺測他其實還有更危險的一個安全風險，如果這個平臺測沒有配置好，這個角色的權限將會導致一個什么問題？

比如說平臺測的產品，它的功能特別強大，它可能會使用云服務器、對象存儲、容器服務等一系列的云上服務，那他的角色的權限將會擁有如下的這些服務的權限，攻擊者獲取到這個角色之后，可以輕松的操作，或者說控制這些云資產，而且可以將攻擊面直接擴散到其他產品中。

大家可以看到上面圖片，這個是云鼎實驗室推出的云安全攻防矩陣，在攻防矩陣的階段中，可能會出現到剛才給大家介紹的實例元數據服務的利用情況，相當于一個技術攻擊，縱觀整個矩陣，可以發現云服務器的元數據服務，也是攻擊者所常用的攻擊切入點。

云原生安全攻防全景圖，這個攻防全景圖從五個大部分來描述了一下云原生的安全攻防的一個場景。主要是從容器基礎設施、云原生應用安全、云原生安全工具、云廠商產品安全風險、容器編排平臺的攻防技術來描述的。

web前端 通用安全

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。