CloudGoat雲靶機 Part-3:利用AWS Lambda函式提權
前言
本文將描繪當攻擊者擁有使用者Joe和Bob的訪問金鑰,但EC2例項停止服務的情形。如果你是第一次閱讀本系列文章,你不知道什麼是 CloudGoat 以及Joe和Bob到底是誰,那麼我建議你先閱讀本系列的第一部分。
許可權提權
擁有訪問金鑰後,攻擊者首先會檢驗該賬戶擁有的許可權。在這裡,Joe缺少 iam:ListAttachedUserPolicies
和 iam:GetUserPolicy
許可權(列出某使用者擁有的許可權),但幸運的是我們可以使用Bob。
Oooh,可以看到Joe的許可權為 DatabaseAdministrator
。如果允許我們用該許可權建立一個Lambda函式的話,一切將變得簡單起來。首先我得了解Joe擁有哪些角色(沒有角色,即使建立了新 Lambda 函式,也無法執行任何操作),讓我們使用以下命令看看分配了哪些角色:
$ aws iam list-roles --profile joe
從輸出中,我們可以讀到這裡實際上有2個角色與 Lambda 函式有關: iam_for_lambda
和 lambda-dynamodb-cloudgoat
。第一個名為 policy_for_lambda_role
的策略,它有助於我們繞過 CloudTrail 的監控服務(有關詳細資訊,請參閱本系列的第二部分)。現在,讓我們來看看第二個角色—— lambda-dynamodb-cloudgoat
好的!可以看到它擁有 iam:AttachRolePolicy
許可權,我可以使用Lambda服務將許可權升級為管理員許可權:sunglasses:,如此“邪惡”功能似乎很容易實現:
import boto3 def lambda_handler(event, context): iam = boto3.client("iam") iam.attach_role_policy(RoleName="lambda-dynamodb-cloudgoat", PolicyArn="arn:aws:iam::aws:policy/AdministratorAccess",) iam.attach_user_policy(UserName="joe", PolicyArn="arn:aws:iam::aws:policy/AdministratorAccess",)
DatabaseAdministrator
策略允許建立新的Lambda函式。現在,是時候壓縮程式碼,建立一個新的Lambda函數了:
最後的一步本該是簡單地呼叫函式,然後慶祝提權成功。但遺憾的是……並不允許直接呼叫:cry:
辦法總有很多,這裡我們可以使用事件 *
來呼叫Lambda
*
——這裡插入一點題外話,因為這是適用於所有 Serverless 應用的全新攻擊向量: 事件注入 。一般來說, Lambda 函式是用來處理事件,所以如果可以使事件“丟幀”(例如上傳的S3物件的名稱)並且後續未正確驗證,那麼就可以強制 Lambda 執行我們的程式碼。我現在不想詳細介紹,因為這不適用於 CloudGoat 場景,但是如果你是這種型別的攻擊的新手,我建議你先觀看一個 簡短的視訊展示 ,看看這個簡單的例子 上傳檔名中的SQLi 或這個 更”真實“的例子 。
現在,我們回到本文的場景。 這裡 有Lambda支援的事件源列表。這裡,我們選取 Amazon DynamoDB
事件。檢視 使用者Joe許可權 ,允許將新的Lambda函式與 DynamoDB
表連線起來 – 換句話說,我可以配置一個新的Lambda函式,在 DynamoDB
表中建立新條目,就可以實現呼叫該函式。這可能聽起來很奇怪,請看下面這個例子。讓我們嘗試使用以下命令建立一個名為 rzepsky_table
的表來簡單地測試:
$ aws dynamodb create-table --table-name rzepsky_table --attribute-definitions AttributeName=Test,AttributeType=S --key-schema AttributeName=Test,KeyType=HASH --provisioned-throughput ReadCapacityUnits=3,WriteCapacityUnits=3 --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE --query TableDescription.LatestStreamArn --profile joe
簡單解釋一下,上述命令建立了一個只有一列 Test
用於儲存字串( S
)的新表。在 --key-schema
中,我給 Test
指定了主鍵。然後,我使用了引數 provisioned-throughput
和啟用了 DynamoDB Stream
流。
好的,它的確起作用了
只要我建立一個事件源,就可以將新的 DynamoDB
表與之前建立的Lambda函式連結起來:
Emm…這也有效!最後,我們只需在表中新增一個新條目就可以觸發Lambda函數了。使用以下命令:
$ aws dynamodb put-item --table-name rzepsky_table --item Test='{S=”Rzepsky”}' --profile joe
如果一切順利,這個事件會呼叫Lambda函式,並且將管理員許可權策略附加給使用者Joe。現在,讓我們驗證一下Joe的許可權:
非常棒!我們提權成功了。
初窺 AWS LightSail
LightSail服務為雲使用者提供雲端計算,儲存和網路。換句話說,您可以快速獲得各種作業系統,應用程式和堆疊,以便您可以構建模板。LightSail的目標是為使用者提供EC2的簡化版本,因此你無需瞭解EBS,VPC和Route 53的使用細節 – 你只需要獲得一個簡單,輕量級的VPS。便捷通常伴隨著風險,LightSail的簡單性會降低安全性嗎?讓我們開始探究LightSail。
在EC2例項中,不允許直接下載SSH金鑰來獲取例項的shell。但是,在LightSail中,情況有所不同。首先,LightSail的使用者允許使用“預設金鑰”,可以使用以下命令檢索:
$ aws lightsail download-default-key-pair
讓我們看看 CloudGoat 靶機中的LightSail專案的金鑰資訊:
$ aws lightsail get-instance-access-details --instance-name cloudgoat_ls --profile joe
我們簡單地獲得臨時ssh金鑰,這在LightSail中這不是什麼問題。從輸出中我們可以讀到LightSail例項使用的是 cloudgoat_key_pair
:
重要的一點,如果我們擁有AWS控制檯管理訪問許可權(比如我將joe的許可權升級為管理員,這是可能的),那麼可以直接從瀏覽器訪問shell!只需點選終端的小圖示:
結束語
在本文,我們介紹了使用Amazon提供的 DatabaseAdministrator
策略,結合具有Lambda寬許可權的角色,實現許可權提升的過程。管理 IAM 許可權並非易事,特別是如果你具有複雜的體系結構和眾多的使用者。一個有效的工具可以幫助你實現許可權最小化分配—— Netflix Repokid 。
後面我們將繼續探討了 LightSail 服務的一些” features “。不要誤解我的意思 ,我不是認為它不安全,我們要做的是恰當地控制連線許可權。在許可權策略中分配萬用字元時,請注意這些“ features ”:wink:
在下一篇文章中,我將介紹另一個 CloudGoat 的場景,感謝觀看。