谷歌云 Compute Engine 攻防
0x01 初始訪問
1、元數據
每個虛擬機 (VM) 實例都將其元數據存儲在元數據服務器上。您的虛擬機可自動獲得對元數據服務器 API 的訪問權限，而無需任何額外的授權。
查詢元數據服務器的內容，您可以從虛擬機實例中向以下根網址發出請求。
請使用
http://metadata.google.internal/computeMetadata/v1/ 網址向元數據服務器發出請求。
Google 為其 API 端點實施了一些額外的安全措施——查詢 Google Cloud Metadata APIv1 需要特殊的標頭:Metadata-Flavor: Google
> attributes/ metadata創建或更新 VM 時在字段中傳遞的用戶定義元數據。> attributes/ssh-keys metadata通過值在字段中創建 VM 期間傳遞的公共 SSH 密鑰列表ssh-keys。> description 創建或更新 VM 時傳遞的文本描述。> disks/ 連接到 VM 的磁盤。> hostname 分配給 VM 的限定域名> id 虛擬機的 ID。ID 在創建 VM 時自動生成，并且在 Yandex Cloud 中是唯一的。> name 創建或更新 VM 時傳遞的名稱。> networkInterfaces/ 連接到 VM 的網絡接口。> service-accounts 鏈接到 VM 的服務賬戶> service-accounts/default/token 關聯服務賬戶的IAM令牌
2、憑證泄露
服務帳號密鑰可能無意中進入不應存儲的位置。不法分子可能會使用泄露的服務帳號密鑰在您的環境中進行身份驗證。
可能會存在服務帳號密鑰的位置，包括：開源項目的源代碼庫、公共 Cloud Storage 存儲桶、遭破解服務的公共數據轉儲、電子郵件收件箱、文件共享、備份存儲、臨時文件系統目錄。
如果找到這些文件之一，可以通過gcloud命令使用此服務帳戶重新進行身份驗證。
0x02 命令執行
1、接管項目
當找到權限大得憑證時，可以通過gcloud命令使用此服務帳戶重新進行身份驗證。
gcloud auth activate-service-account --key-file [FILE]
輸出項目的IAM策略
gcloud projects get-iam-policy example-project-id-1
要在“example-project-id-1”的項目上為用戶“test-user@gmail.com”的“roles/editor”角色添加 IAM 策略綁定。
gcloud projects add-iam-policy-binding example-project-id-1 --member='user:test-user@gmail.com' --role='roles/editor'
拿到高權限服務賬戶的憑證然后就可以通過gcloud調用憑證去添加其他谷歌用戶項目權限，下面添加editor權限，可以看到能夠使用我們添加的用戶去管理這個項目了。
2、獲取項目級實例權限
利用方式：Web應用程序漏洞（如SSRF/XXE/RCE）等，假設存在的Web應用程序存在SSRF漏洞，使用瀏覽器訪問 URL 應用程序應如下所示：
在URL處輸入http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token?alt=json，Header處輸入Metadata-Flavor: Google，成功獲取了access_token，當然，我們也可以通過上面列表去訪問其他API獲取更多的信息。
使用scopes參數獲取access token的使用范圍
如果有修改元數據的權限，則有辦法實現權限提升，有以下情況：
默認賬戶啟用了允許訪問所有Cloud API或自定義服務賬戶具有https://www.googleapis.com/auth/compute、https://www.googleapis.com/auth/cloud-platform權限范圍
首先要先獲取元數據中fingerprint
然后使用setCommonInstanceMetadata方法去添加(此次項目中沒有舊的密鑰，如果有舊的密鑰，需要"value": "EXISTING_SSH_KEYSNEW_SSH_KEY")
再去看下，成功寫入，拿到實例控制權限
3、SSH密鑰泄露
當谷歌云ssh的密鑰被泄露后我們可以登陸該Compute Engine實例執行一系列惡意操作命令。
0x03 權限提升
1、修改元數據
如果能夠修改原數據，則可以將SSH密鑰添加到實例級元數據。
2、竊取 gcloud 授權
很可能同一機器上的其他用戶一直在gcloud使用比您自己的帳戶更強大的帳戶運行命令。您需要本地root權限才能執行此操作。
首先，查找gcloud用戶的主文件夾中存在哪些配置目錄。
$ sudo find / -name "gcloud"
您可以手動檢查里面的文件，但這些通常是帶有秘密的文件：
- ~/.config/gcloud/credentials.db
- ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json
- ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto
- ~/.credentials.json
現在，您可以選擇在這些文件中查找明文憑據，或者簡單地將整個gcloud文件夾復制到您控制和運行的計算機上gcloud auth list，以查看您現在可以使用哪些帳戶。
3、授予其他用戶控制臺權限
見命令執行中的接管項目操作
0x04 權限維持
1、添加項目主賬戶
加其他用戶到項目主賬戶，其他用戶就可以登錄控制臺去管理項目
2、添加新密鑰
在其他高權限服務賬戶種創建新密鑰，可以在當前用戶權限掉后，繼續使用高權限得用戶憑證去實現權限維持。
3、添加項目級ssh密鑰
添加項目級ssh密鑰，可以讓我們是隨意控制項目下的虛擬機。
0x05 信息收集
1、元數據
通過元數據進行信息收集
attributes/ metadata創建或更新 VM 時在字段中傳遞的用戶定義元數據。attributes/ssh-keys metadata通過值在字段中創建 VM 期間傳遞的公共 SSH 密鑰列表ssh-keys。description 創建或更新 VM 時傳遞的文本描述。disks/ 連接到 VM 的磁盤。hostname 分配給 VM 的限定域名id 虛擬機的 ID。ID 在創建 VM 時自動生成，并且在 Yandex Cloud 中是唯一的。name 創建或更新 VM 時傳遞的名稱。networkInterfaces/ 連接到 VM 的網絡接口。service-accounts 鏈接到 VM 的服務賬戶service-accounts/default/token 關聯服務賬戶的IAM令牌
2、子網信息
通過獲取項目權限后，在控制臺進行查看子網信息。
3、用戶數據
目標實例上運行的服務以及存儲的數據
4、密鑰
很有可能機器上的其他用戶比你當前的賬戶權限更大，我們可以尋找一下敏感文件。
sudo find / -name "gcloud"
注意以下文件：
- ~/.config/gcloud/credentials.db
- ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json
- ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto
- ~/.credentials.json
5、查看自定義實例模板
實例模板定義實例屬性以幫助部署一致的配置，可能包含與運行的實例一樣的敏感數據。
# 列出可以獲取的模版$ gcloud compute instance-templates list# 獲取模版的信息$ gcloud compute instance-templates describe [TEMPLATE NAME]
6、枚舉存儲桶
# 列出項目中的所有存儲桶$ gsutil ls # 獲取項目中所有存儲桶的詳細信息$ gsutil ls -L # 列出特定存儲桶的內容$ gsutil ls -r gs://bucket-name/ # 將存儲桶中的對象復制到本地存儲以供查看$ gsutil cp gs://bucket-name/folder/object ~/
0x06 橫向移動
1、控制臺
在添加項目主賬戶后，拿到控制臺下項目的管理權限，通過控制臺去控制當前項目下其他虛擬機實例。
2、虛擬機實例
在拿到項目下虛擬機實例的權限，可以通過傳統滲透方式去進行。
0x07 影響
1、子域名接管
當域名對應的實例銷毀或者當實例重新啟動后對應的公網ip發生變化，但域名還是指向原來的公網ip，此時會存在子域名被接管的風險，但是由于公網ip的隨機性，此攻擊的利用成本較大。
2、Google Compute Engine (GCE) VM takeover via DHCP flood
由于 ISC DHCP 軟件使用的隨機數較弱以及其他因素的不幸組合，攻擊者可以通過網絡接管 Google Cloud Platform 的虛擬機。這是通過從目標虛擬機的角度模擬元數據服務器來完成的。
通過安裝此漏洞，攻擊者可以通過 SSH（公鑰身份驗證）授予自己訪問權限，以便他們可以以 root 用戶身份登錄。
參考：https://github.com/irsl/gcp-dhcp-takeover-code-exec
0x08 總結
整體而言，谷歌云Compute Engine下的攻擊手法主要還是由于憑證泄露、配置錯誤這類問題導致的。
參考鏈接
- https://cloud.google.com/compute/docs/instances/connecting-advanced#sa_ssh_manual
- https://cloud.google.com/compute/docs/connect/add-ssh-keys#api_3
- https://cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy?hl=zh-cn
- https://cloud.google.com/iam/docs/impersonating-service-accounts?authuser=1&_ga=2.81056407.-1414587130.1644838399
