看我如何通使用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