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 的場景，感謝觀看。