看我如何通使用Lambda函式對AWS帳戶進行攻擊測試
嚴正宣告：本文涉及到的內容和技術僅用於教育和討論目的，嚴禁用於非法用途。
前言
2018年8月3號，我收到了一條神祕的LinkedIn訊息，這條訊息來自Caleb Sima，內容如下：
我不得不承認，我一開始都沒反應過來Caleb想跟我說啥，不過看了一下URL之後（其中包含了Lambda和Shell），我感覺他應該是想告訴我他開發出了一種通過Lambda函式來執行Shell命令的技術。我之前也見過類似的東西，比如說 ofollow,noindex" target="_blank">Lambdash 。幾秒鐘之後，我打算點進去看一看這個Web頁面，然後發現了：
看到這段話之後，我首先得弄清楚Caleb的動機，所以我給他發了一條資訊：
好吧，Caleb是打算讓別人通過Lambda函式來攻擊他的AWS賬號，並最終實現Shell命令的執行。聽起來確實值得一試，畢竟現在很難有人願意把自己的賬號給別人去免費“蹂躪”了，這讓我非常興奮！
第一步：收集情報
首先，我在當前目錄(/var/task)下執行“ ls -IF”命令來提取函式處理器的檔名：
拿到檔名(index.js)之後，我通過執行“cat index.js”命令來獲取函式的原始碼：
實際上，最初的原始碼並沒有讓我感到驚訝，因為它就是普通的利用Lambda函式執行Shell命令的一段程式碼，我之前也已經見過很多類似的了。
我跟我自己說：“好吧，我現在能執行Shell命令了，可是那然後呢？我怎麼才能給這個賬號帶來一點實際的威脅呢？”
於是，我打算收集更多資訊，然後我列出了所有的環境變數，我想看看Caleb有沒有留下一些有用的東西，這裡可以使用‘env’命令：
第二步：冒充Lambda函式
在對環境變數進行滲入分析之後，我發現當一個AWS Lambda函式執行時，它會使用一個由開發者（IAM角色）提供的臨時安全證書。此時需要從AWS STS（安全令牌服務）接收以下三個引數：
AWS_SECRET_ACCESS_KEY AWS_ACCESS_KEY_ID AWS_SESSION_TOKEN
這是三個非常敏感的令牌，但是卻直接在我的螢幕上作為環境變數列印了出來…
如果你不熟悉AWS IAM安全模型的話，我可以告訴你，這是一個非常強大且細粒度非常高的安全許可權模型，模型的具體介紹可參考AWS提供的IAM角色文件：【 傳送門 】。
既然我們已經拿到了AWS STS給函式生成的令牌了，那接下來就好辦了。這裡我可以直接使用令牌來在本地裝置上呼叫AWS的命令列介面。此時我需要通過呼叫下列命令來在本地設定這些環境變數：
/>export AWS_SECRET_ACCESS_KEY = ….. />export AWS_ACCESS_KEY_ID = …. />export AWS_SESSION_TOKEN = ....
為了測試這些令牌，我打算呼叫AWS STS命令列實用工具來獲取當前的呼叫者身份：
/>aws sts get-caller-identity
幾秒鐘之後，命令列工具會給我返回下列資訊：
{
"UserId":"AROA********GL4SXW:exec",
"Account":"1232*****446",
"Arn":"arn:aws:sts::1232*****446:assumed-role/lambda_basic_execution/exec"
}
非常好，現在我就可以在本地執行AWS命令列工具了，而且我還可以偽裝成IAM角色。
當你檢視AWS Lambda Web終端時，你將會看到：
大家可以看到，Caleb其實並沒有用環境變數儲存任何的應用程式隱私資料，這讓我很“生氣”。但是這裡不得不提醒大家一下，很多開發人員確確實實會犯這樣的錯誤，這是值得警惕的一點。
* 參考來源： darkreading ，FB小編Alpha_h4ck編譯，轉載請註明來自FreeBuf.COM