淺談云上攻防—

作者：ruiqiang@云鼎實驗室
原文鏈接：https://mp.weixin.qq.com/s/Y9CBYJ_3c2UI54Du6bneZA

前言

在針對云上業務的的攻擊事件中，很多攻擊者將攻擊脆弱的元數據服務作為攻擊流程中重要的一個環節并最終造成了嚴重的危害。

以2019年的美國第一資本投資國際集團（CapitalOne）信息泄露事件舉例，根據《ACase Study of the Capital One Data Breach》報告指出，攻擊者利用CapitalOne部署在AWS云上實例中的SSRF漏洞向元數據服務發送請求并獲取角色的臨時憑證，在獲取角色臨時憑據后將該角色權限下的S3存儲桶中的數據復制到攻擊者的本地機器上，最終導致這一嚴重數據泄露事件的產生，這一事件影響了北美超過1億人。CapitalOne 的股價在宣布數據泄露后收盤下跌 5.9%，在接下來的兩周內總共下跌了 15%。

Capital One信息泄露事件攻擊原理圖，可參見圖：

CapitalOne信息泄露事件攻擊原理圖

在介紹元數據服務帶來的安全挑戰之前，我們先來簡單介紹一下元數據服務以及角色的概念。

01元數據服務以及角色介紹

元數據服務

元數據即表示實例的相關數據，可以用來配置或管理正在運行的實例。用戶可以通過元數據服務在運行中的實例內查看實例的元數據。

以AWS舉例，可以在實例內部訪問如下地址來查看所有類別的實例元數據：

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

169.254.169.254屬于鏈路本地地址（Link-localaddress），鏈路本地地址又稱連結本地位址，是計算機網絡中一類特殊的地址，它僅供于在網段，或廣播域中的主機相互通信使用。這類主機通常不需要外部互聯網服務，僅有主機間相互通訊的需求。IPv4鏈路本地地址定義在169.254.0.0/16地址塊。

而在具體的技術實現上，云廠商將元數據服務運行在Hypervisor（虛擬機管理程序）上。當實例向元數據服務發起請求時，該請求不會通過網絡傳輸，也永遠不會離開這一臺計算機。基于這個原理，元數據服務只能從實例內部訪問。

可以PING云廠商所提供的元數據服務域名，以查看其IP地址

從上圖可見，元數據服務屬于鏈路本地地址。

從設計上來看，元數據服務看起來很安全，那為什么說元數據服務脆弱呢？

由于元數據服務部署在鏈路本地地址上，云廠商并沒有進一步設置安全措施來檢測或阻止由實例內部發出的惡意的對元數據服務的未授權訪問。攻擊者可以通過實例上應用的SSRF漏洞對實例的元數據服務進行訪問。

因此，如果實例中應用中存在SSRF漏洞，那么元數據服務將會完全暴露在攻擊者面前。

在實例元數據服務提供的眾多數據中，有一項數據特別受到攻擊者的青睞，那就是角色的臨時訪問憑據。這將是攻擊者由SSRF漏洞到獲取實例控制權限的橋梁。

訪問管理角色

既然攻擊涉及到訪問管理角色的臨時憑據，我們首先看下訪問管理角色是什么：

訪問管理的角色是擁有一組權限的虛擬身份，用于對角色載體授予云中服務、操作和資源的訪問權限。用戶可以將角色關聯到云服務器實例。為實例綁定角色后，將具備以下功能及優勢：

可使用 STS 臨時密鑰訪問云上其他服務
可為不同的實例賦予包含不同授權策略的角色，使實例對不同的云資源具有不同的訪問權限，實現更精細粒度的權限控制
無需自行在實例中保存 SecretKey，通過修改角色的授權即可變更權限，快捷地維護實例所擁有的訪問權限

具體的操作流程如下：

在將角色成功綁定實例后，用戶可以在實例上訪問元數據服務來查詢此角色的臨時憑據，并使用獲得的臨時憑據操作該角色權限下的云服務API接口。

02針對元數據服務的攻擊

接下來我們將介紹下針對元數據服務的一些常見的攻擊模式。攻擊者可以首先通過目標實例上的SSRF漏洞獲取與實例綁定的角色名稱（rolename）。攻擊者可以構造訪問元數據接口的payload，并通過存在SSRF漏洞的參數傳遞：

http://x.x.x.x/?url=http://169.254.169.254/latest/meta-data/iam/info

在獲取到角色名稱后，攻擊者可以繼續通過SSRF漏洞獲取角色的臨時憑證：

http://x.x.x.x/url=http://169.254.169.254/latest/metadata/iam/security-credentials/

獲取角色臨時憑據的案例可參見下圖:

從上圖可見，攻擊者可以獲取角色的TmpSecretID以及TmpSecretKey。

在攻擊者成功獲取角色的臨時憑據后，將會檢查獲取到的角色臨時憑據的權限策略。

有的時候，可以通過獲取到的角色名稱，來猜測該角色的權限策略，例如角色名為：TKE_XXX，則這個角色很大可能是擁有操作TKE容器服務的權限。

此外，如果獲取的臨時密鑰擁有查詢訪問管理接口的權限，攻擊者可以通過訪問“訪問管理”API來準確獲取的角色權限策略。可以通過如下幾種方式判斷獲取角色的權限策略：

1、通過使用臨時API憑據訪問“獲取角色綁定的策略列表”API接口，見下圖：

從上圖可見，攻擊者獲取到的與實例綁定的角色的臨時憑據權限策略是“AdministratorAccess”,這個策略允許管理賬戶內所有用戶及其權限、財務相關的信息、云服務資產。

2、通過使用臨時API憑據訪問“獲取角色詳情”API接口，見下圖：

通過查詢的返回結果可以見，角色的權限策略為AssumeRole。

在弄清楚竊取的憑據所擁有的權限后，攻擊者便可以通過憑據的權限制定后續的攻擊流程。

但在開始后續的攻擊階段之前，攻擊者會先判斷當前權限是否可以獲取目標的數據資源。

在所有云資源中，攻擊者們往往對目標的數據更加感興趣。如果攻擊者獲取的密鑰擁有云數據庫服務或云存儲服務等服務的操作權限，攻擊者將會嘗試竊取目標數據。

臨時憑據同樣也可以幫助攻擊者們在目標實例中執行指令并控制實例權限。

與通過密鑰構造請求這種方式發起攻擊相比，攻擊者們在實戰中更傾向于使用云命令行工具來進行攻擊。

云服務廠商為用戶提供了相應的云命令行工具以管理云服務，例如騰訊云提供的TCCLI工具、AWS的AWSCLI工具。攻擊者可以通過在云命令行工具中配置竊取到的API密鑰來對云資源進行調用。與構造請求訪問云API接口這種方式相比，使用云命令行工具將會給攻擊者帶來更多便捷。

在使用云命令行工具之前，應先配置API密鑰，以AWSCLI工具配置舉例，可以將：

攻擊者將竊取來的AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN配置完成后，可以使用云命令行工具在目標實例上執行命令。

在配置好密鑰后，攻擊者可以嘗試使用如下圖命令通過AWSCLI在實例中運行bash腳本以獲取實例控制權限。

借助通過元數據服務竊取到的憑據以及AWSCLI所提供的功能,攻擊者可以在實例中執行反彈shell命令，由此進入實例。

除此之外，攻擊者還可以選擇修改userdata，將反彈shell寫入userdata中后將實例重啟，從而控制實例。

Userdata涉及到云廠商提供的一種功能，這項功能允許用戶自定義配置在實例啟動時執行的腳本的內容。

通過這一功能，攻擊者可以嘗試在實例的userdata中寫入惡意代碼，這些代碼將會在實例每次啟動時自動執行。

以AWS舉例，攻擊者可以將惡意代碼寫入my_script.txt文件中，然后執行如下指令將my_script.txt文件中內容導入userdata中。

隨后，攻擊者通過如下命令重啟實例：

當實例重啟時，userdata中的惡意代碼將會被執行。

攻擊者除了可以使用臨時憑據獲取實例的控制權限，通過元數據服務竊取到的擁有一定權限的角色臨時憑據在持久化階段也發揮著作用。攻擊者嘗試使用通過元數據服務獲取的臨時憑據進行持久化操作，確保能夠持續擁有訪問權限，以防被發現后強行終止攻擊行為。

使用臨時憑據進行持久化的方式有很多，比如說在上文中所提及的在userdata中寫入惡意代碼這項攻擊技術，也是可以運用在持久化階段：通過在實例的userdata中寫入惡意代碼，這些代碼將會在實例每次啟動時自動執行。這將很好的完成持久化操作而不易被發現。

除此之外，攻擊者還可以嘗試在賬戶中創建一個新的用戶以進行持久化，以AWSCLI舉例，攻擊者可以通過awsiam create-user --user-name Bob 為賬戶新建一個名為Bob的用戶

隨后使用awsiam create-access-key --user-name Bob指令為Bob用戶創建憑據

雖然這個方法操作簡單且有效，但是賬戶里突然新增的用戶及其容易被察覺，因此并不是一個特別有效的持久化方式。

此外，攻擊者還會使用一種常見的持久化手法，那就是給現有的用戶分配額外的密鑰。以針對AWS的攻擊來說，攻擊者可以使用aws_pwn這款工具來完成這項攻擊，aws_pwn地址如下：

https://github.com/dagrz/aws_pwn

aws_pwn提供了多項技術以供攻擊者可以完成針對aw的持久化攻擊，關于aws_pwn所提供的持久化功能可見下圖：

通過元數據服務竊取也可以被攻擊者應用于橫向移動操作。攻擊者可以通過元數據服務竊取角色的臨時憑據橫向移動到角色對應權限的資源上。除此之外，攻擊者會在所控制的實例上尋找配置文件，并通過配置文件中的配置項中獲取其他資源的訪問方式以及訪問憑據。

攻擊者在橫向移動的過程中，獲取到可以操作云數據庫或存儲服務必要權限的密鑰或是登錄憑據后，攻擊者就可以訪問這些服務并嘗試將其中的用戶數據復制到攻擊者的本地機器上。

以AWSCLI為例，攻擊者可以通過如下命令將s3存儲桶中的內容同步到本地

仍然以上文提及的CapitalOne銀行數據泄露事件舉例，攻擊者使用獲取到的角色臨時憑據，多次執行“awss3 ls”命令，獲取CapitalOne 賬戶的存儲桶的完整列表；

接著攻擊者使用 sync命令將近30 GB 的Capital One用戶數據復制到了攻擊者本地。

總的來說，元數據服務為云上安全帶來了極大的安全挑戰，攻擊者在通過SSRF等漏洞獲取到實例綁定的角色的臨時憑據后，將會將其應用于云上攻擊的各個階段。通過破壞用戶系統，濫用用戶資源、加密用戶資源并進行勒索等手段影響用戶環境正常使用。

03元數據安全性改進

以AWS為例，AWS為了解決元數據服務在SSRF 攻擊面前暴露出的安全性問題，引入IMDSv2來改善其總體安全情況。

在IMDSv2中，如果用戶想訪問元數據服務，首先需要在實例內部向IMDSv2發送一個HTTPPUT請求來啟動會話，示例如下：

X-aws-ec2-metadata-token-ttl-seconds用于指定生存時間（TTL）值（以秒為單位），上文中生成的token有效期為6小時（21600秒），在IMDSv2中21600秒是允許的最大TTL值。此請求將會返回一個token，后續訪問元數據服務，需要在HTTPheader中攜帶此token，見如下請求：

完整流程如下：

TOKEN=`curl-X PUT "http://169.254.169.254/latest/api/token" -H"X-aws-ec2-metadata-token-ttl-seconds: 21600"

curlhttp://169.254.169.254/latest/meta-data/profile -H“X-aws-ec2-metadata-token: $TOKEN”

流程圖如下:

可見，在采用IMDSv2時，即使實例中應用存在SSRF漏洞，攻擊者也無法輕易的利用SSRF漏洞向元數據服務發出PUT請求來獲取token，在沒有token的情況下，攻擊者并不能訪問元數據服務，也就無法獲取角色的臨時憑據進行后續的攻擊行為。

除了使用PUT啟動請求這項安全策略之外，IMDSv2還引入了如下兩個機制保證元數據服務的安全：

不允許X-Forwarded-For標頭：如果攻擊者通過反向代理的方式的確可以繞過PUT限制，但是，通過代理傳遞的請求將包含“ X-Forwarded-For”標頭。這樣的請求被IMDSv2拒絕，并且不發行令牌。
IP數據包TTL設置為“ 1”：TTL指定數據包被路由器丟棄之前允許通過的最大網段數量，是IP數據包在網絡中可以轉發的最大跳數(躍點數),將其值設置為1可確保包含機密令牌的HTTP響應不會在實例外部傳播。即使攻擊者能夠繞過所有其他保護措施，這也將確保令牌不會在實例外部傳播，并且一旦數據包離開實例，數據包將被丟棄。

值得注意的是，AWS認為現有的實例元數據服務（IMDSv1）是完全安全的，因此將繼續支持它。如果不執行任何操作，則IMDSv1和IMDSv2都可用于EC2實例。這就是說，在不主動禁用IMDSv1的情況下，實例仍存在著安全隱患。