作者：ruiqiang@云鼎實驗室
原文鏈接：https://mp.weixin.qq.com/s/NesaxzuULBkkLBPkg7i8wQ

前言

Web應用托管服務是一種常見的平臺即服務產品（PaaS），可以用來運行并管理Web類、移動類和API類應用程序。Web應用托管服務的出現，有效地避免了應用開發過程中繁瑣的服務器搭建及運維，使開發者可以專注于業務邏輯的實現。在無需管理底層基礎設施的情況下，即可簡單、有效并且靈活地對應用進行部署、伸縮、調整和監控。

Web應用托管服務作為一種云上服務，其中也會應用到的元數據服務進行實例元數據查詢，因此不得不考慮元數據服務安全對Web應用托管服務安全性的影響。

通過“淺談云上攻防”系列文章《淺談云上攻防——元數據服務帶來的安全挑戰》一文的介紹，元數據服務為云上業務帶來的安全挑戰想必讀者們已經有一個深入的了解。Web應用托管服務中同樣存在著元數據服務帶來的安全挑戰，本文將擴展探討元數據服務與Web應用托管服務這一組合存在的安全隱患。

Web應用托管服務中的元數據安全隱患

在Web應用托管服務中的元數據安全隱患章節中，我們將以AWS 下的Elastic Beanstalk服務進行舉例，以此介紹一下攻擊者如何攻擊Web應用托管服務并利用元數據服務獲取信息發起后續攻擊，最終對用戶資產造成危害。

AWS Elastic Beanstalk 是 AWS 提供的平臺即服務 (PaaS) 產品，用于部署和擴展為各種環境（如 Java、.NET、PHP、Node.js、Python、Ruby 和 Go）開發的 Web 應用程序。Elastic Beanstalk 會構建選定的受支持的平臺版本，并預置一個或多個AWS資源（如 Amazon EC2 實例）來運行應用程序。

Elastic Beanstalk 的工作流程如下：

在使用Elastic Beanstalk 部署Web 應用程序時，用戶可以通過上傳應用程序代碼的zip 或 war 文件來配置新應用程序環境，見下圖：

在進行新應用程序環境配置時，Elastic Beanstalk服務將會進行云服務器實例創建、安全組配置等操作。

與此同時， Elastic Beanstalk也將創建一個名為 elasticbeanstalk-region-account-id 的 Amazon S3 存儲桶。這個存儲桶在后續的攻擊環節中比較重要，因此先簡單介紹一下：Elastic Beanstalk服務使用此存儲桶存儲用戶上傳的zip與war 文件中的源代碼、應用程序正常運行所需的對象、日志、臨時配置文件等。

elasticbeanstalk-region-account-id中存儲的對象列表以及其相關屬性可參見下圖：

Elastic Beanstalk服務不會為其創建的 Amazon S3 存儲桶啟用默認加密。這意味著，在默認情況下，對象以未加密形式存儲在存儲桶中（并且只有授權用戶可以訪問）。

在了解Elastic Beanstalk的使用之后，我們重點來看一下元數據服務與Elastic Beanstalk服務組合下的攻擊模式。

正如上一篇文章提到的：當云服務器實例中存在SSRF、XXE、RCE等漏洞時，攻擊者可以利用這些漏洞，訪問云服務器實例上的元數據服務，通過元數據服務查詢與云服務器實例綁定的角色以及其臨時憑據獲取，在竊取到角色的臨時憑據后，并根據竊取的角色臨時憑據相應的權限策略，危害用戶對應的云上資源。

而在Elastic Beanstalk 服務中也同樣存在著這種攻擊模式，Elastic Beanstalk 服務創建名為aws-elasticbeanstalk-ec2-role的角色，并將其與云服務器實例綁定。

我們關注一下aws-elasticbeanstalk-ec2-role角色的權限策略： 從AWS官網可知，Elastic Beanstalk服務為aws-elasticbeanstalk-ec2-role角色提供了三種權限策略：用于 Web 服務器層的權限策略；用于工作程序層的權限策略；擁有多容器 Docker 環境所需的附加權限策略，在使用控制臺或 EB CLI 創建環境時，Elastic Beanstalk 會將所有這些策略分配給aws-elasticbeanstalk-ec2-role角色，接下來分別看一下這三個權限策略。

AWSElasticBeanstalkWebTier – 授予應用程序將日志上傳到 Amazon S3 以及將調試信息上傳到 AWS X-Ray 的權限，見下圖：

AWSElasticBeanstalkWorkerTier – 授予日志上傳、調試、指標發布和工作程序實例任務（包括隊列管理、定期任務）的權限，見下圖：

AWSElasticBeanstalkMulticontainerDocker – 向 Amazon Elastic Container Service 授予協調集群任務的權限，見下圖：

從上述策略來看，aws-elasticbeanstalk-ec2-role角色擁有對“elasticbeanstalk-”開頭的S3 存儲桶的讀取、寫入權限以及遞歸訪問權限，見下圖：

通過權限策略規則可知，此權限策略包含上文介紹的elasticbeanstalk-region-account-id存儲桶的操作權限。

elasticbeanstalk-region-account-id存儲桶命名也是有一定規律的：elasticbeanstalk-region-account-id存儲桶名由“elasticbeanstalk”字符串、資源region值以及account-id值組成，其中elasticbeanstalk字段是固定的，而region與account-id值分別如下：

  • l region 是資源所在的區域（例如，us-west-2）
  • account-id 是Amazon賬戶 ID，不包含連字符（例如，123456789012）

通過存儲桶命名規則的特征，在攻擊中可以通過目標的信息構建出elasticbeanstalk-region-account-id存儲桶的名字。

接下來介紹一下Elastic Beanstalk中元數據安全隱患。

用戶在使用Elastic Beanstalk中部署Web應用程序時，如果用戶的Web應用程序源代碼中存在SSRF、XXE、RCE等漏洞，攻擊者可以利用這些漏洞訪問元數據服務接口，并獲取account-id、Region以及aws-elasticbeanstalk-ec2-role角色的臨時憑據，并通過獲取到的信息對S3存儲桶發起攻擊，account-id、Region以及aws-elasticbeanstalk-ec2-role角色的臨時憑據獲取方式如下：

以Elastic Beanstalk中部署Web應用程序中存在SSRF漏洞為例，攻擊者可以通過發送如下請求以獲取account-id、Region：

https://x.x.x.x/ssrf.php?url=http://169.254.169.254/latest/dynamic/instance-identity/document

從響應數據中Accountid、Region字段獲取account-id、Region值，攻擊者可以以此構造出目標elasticbeanstalk-region-account-id存儲桶名稱。

攻擊者可以發送如下請求以獲取aws-elasticbeanstalk-ec2-role角色的臨時憑據：

https://x.x.x.x/ssrf.php?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ AWS-elasticbeanstalk-EC2-role

從響應數據中獲取aws-elasticbeanstalk-ec2-role角色的臨時憑據：AccessKeyId、SecretAccessKey、Token三個字段值。

隨后，攻擊者使用獲取到的aws-elasticbeanstalk-ec2-role角色的臨時憑據，訪問云API接口并操作elasticbeanstalk-region-account-id存儲桶。

上述攻擊模式的攻擊流程圖如下：

elasticbeanstalk-region-account-id存儲桶對Elastic Beanstalk服務至關重要，在攻擊者獲取elasticbeanstalk-region-account-id存儲桶的操作權限之后，可以進行如下的攻擊行為，對用戶資產進行破壞。

獲取用戶源代碼

在獲取elasticbeanstalk-region-account-id存儲桶的控制權后，攻擊者可以遞歸下載資源來獲取用戶Web應用源代碼以及日志文件，具體操作如下：

aws s3 cp s3:// elasticbeanstalk-region-account-id/ /攻擊者本地目錄 –recursive

攻擊者可以通過在AWS命令行工具中配置獲取到的臨時憑據，并通過如上指令遞歸下載用戶elasticbeanstalk-region-account-id存儲桶中的信息，并將其保存到本地。

獲取實例控制權

除了竊取用戶Web應用源代碼、日志文件以外，攻擊者還可以通過獲取的角色臨時憑據向elasticbeanstalk-region-account-id存儲桶寫入Webshell從而獲取實例的控制權。

攻擊者編寫webshell文件并將其打包為zip文件，通過在AWS命令行工具中配置獲取到的臨時憑據，并執行如下指令將webshell文件上傳到存儲桶中：

aws s3 cp webshell.zip s3:// elasticbeanstalk-region-account-id/

當用戶使用AWS CodePipeline等持續集成與持續交付服務時，由于上傳webshell操作導致代碼更改，存儲桶中的代碼將會自動在用戶實例上更新部署，從而將攻擊者上傳的webshell部署至實例上，攻擊者可以訪問webshell路徑進而使用webshell對實例進行權限控制。

更多安全隱患

除了上文章節中介紹的安全隱患，Web應用托管服務中生成的錯誤的角色權限配置，將為Web應用托管服務帶來更多、更嚴重的元數據安全隱患。

從上文章節來看，Elastic Beanstalk服務為aws-elasticbeanstalk-ec2-role角色配置了較為合理的權限策略，使得即使Web應用托管服務中托管的用戶應用中存在漏洞時，攻擊者在訪問實例元數據服務獲取aws-elasticbeanstalk-ec2-role角色的臨時憑據后，也僅僅有權限操作Elastic Beanstalk服務生成的elasticbeanstalk-region-account-id S3存儲桶，并非用戶的所有存儲桶資源。這樣一來，漏洞所帶來的危害并不會直接擴散到用戶的其他資源上。

但是，一旦云廠商所提供的Web應用托管服務中自動生成并綁定在實例上的角色權限過高，當用戶使用的云托管服務中存在漏洞致使云托管服務自動生成的角色憑據泄露后，危害將從云托管業務直接擴散到用戶的其他業務，攻擊者將會利用獲取的高權限臨時憑據進行橫向移動。

通過臨時憑據，攻擊者可以從Web應用托管服務中逃逸出來，橫向移動到用戶的其他業務上，對用戶賬戶內眾多其他資產進行破壞，并竊取用戶數據。具體的攻擊模式可見下圖： 由于攻擊者使用Web應用托管服務生成的合法的角色身份，攻擊行為難以被發覺，對用戶安全造成極大的危害。

針對于這種情況，首先可以通過加強元數據服務的安全性進行緩解，防止攻擊者通過SSRF等漏洞直接訪問實例元數據服務并獲取與之綁定的角色的臨時憑據。

此外，可以通過限制Web應用托管服務中綁定到實例上的角色的權限策略進行進一步的安全加強。在授予角色權限策略時，遵循最小權限原則。

最小權限原則是一項標準的安全原則。即僅授予執行任務所需的最小權限，不要授予更多無關權限。例如，一個角色僅是存儲桶服務的使用者，那么不需要將其他服務的資源訪問權限（如數據庫讀寫權限）授予給該角色。

參考文獻

https://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/iam-instanceprofile.html

https://notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/

https://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/concepts-roles-instance.html

https://generaleg0x01.com/2019/03/10/escalating-ssrf-to-rce/

https://mp.weixin.qq.com/s/Y9CBYJ_3c2UI54Du6bneZA

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1680/