在本博客中,我们的“ 高级Web黑客 ”培训课程的首席培训师Sunil Yadav将讨论一个案例研究,其中识别并利用服务器端请求伪造(SSRF)漏洞来访问敏感数据,例如源代码。此外,该博客讨论了可能导致部署在具有持续部署(CD)管道的AWS Elastic Beanstalk上的应用程序的远程执行代码(RCE)的潜在领域。

AWS Elastic Beanstalk

AWS Elastic Beanstalk是AWS提供的平台即服务(PaaS)产品,用于部署和扩展针对各种环境(如Java,.NET,PHP,Node.js,Python,Ruby和Go)开发的Web应用程序。它自动处理部署,容量配置,负载平衡,自动扩展和应用程序运行状况监视。

提供环境

AWS Elastic Beanstalk支持Web Server和Worker环境配置。

Web服务器环境 - 通常适合运行Web应用程序或Web API。
工作环境 - 适合后台工作,长时间运行的流程。
可以通过在zip或war文件中提供有关应用程序,环境和上载应用程序代码的一些信息来配置新应用程序。


图1:创建Elastic Beanstalk环境

配置新环境后,AWS会创建S3 Storage bucket,安全组,EC2实例。它还会创建一个名为aws-elasticbeanstalk-ec2-role的默认实例配置文件,该配置文件使用默认权限映射到EC2实例。

从用户计算机部署代码时,zip文件中的源代码副本将放在名为elasticbeanstalk - region-account-id的S3 Storage bucket中。


图2:Amazon S3 Storage bucket

Elastic Beanstalk不会为其创建的Amazon S3 Storage bucket启用默认加密。这意味着默认情况下,对象以未加密的形式存储在Storage bucket中(并且只能由授权用户访问)。

阅读更多:https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.S3.html

默认实例配置文件的托管策略 - aws-elasticbeanstalk-ec2-role:

AWSElasticBeanstalkWebTier - 授予应用程序将日志上载到Amazon S3并将信息调试到AWS X-Ray的权限。
AWSElasticBeanstalkWorkerTier - 授予日志上载,调试,度量标准发布和工作器实例任务的权限,包括队列管理,领导者选举和定期任务。
AWSElasticBeanstalkMulticontainerDocker - 授予Amazon Elastic Container Service协调群集任务的权限。
策略“ AWSElasticBeanstalkWebTier ”允许对S3 Storage bucket进行有限的列表,读取和写入权限。仅当Storage bucket名称以“ elasticbeanstalk- ” 开头时才能访问Storage bucket,并且还授予了递归访问权限。


图3:托管策略 - “AWSElasticBeanstalkWebTier”
阅读更多:https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html

分析

虽然我们继续使用常规测试,但我们在应用程序中遇到了服务器端请求伪造(SSRF)漏洞。通过对外部域进行DNS调用来确认此漏洞,并通过访问配置为仅允许localhost访问它的“http:// localhost / server-status”进一步验证此漏洞,如下面的图4所示。

http://staging.xxxx-redacted-xxxx.com/view_pospdocument.php?doc=http://localhost/server-status


图4:通过访问受限页面确认SSRF

旦SSRF得到确认,我们便会使用https://ipinfo.io 等服务通过服务器指纹识别确认服务提供商是亚马逊。此后,我们尝试通过多个端点查询AWS元数据,例如:

然后,我们从API“http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role” 中检索了访问密钥,秘密访问密钥和令牌:

图6:AWS元数据 - 检索访问密钥ID,秘密访问密钥和令牌

注意:“ aws-elasticbeanstalk-ec2-role” 的 IAM安全凭证表示应用程序部署在Elastic Beanstalk上。

我们进一步配置了AWS命令行界面(CLI),如图7所示:

图7:配置AWS命令行界面
“aws sts get-caller-identity”命令的输出表明令牌工作正常,如图8所示:

图8:AWS CLI输出:get-caller-identity
所以,到目前为止,这么好。相当标准的SSRF漏洞,对吗?这是有趣的地方......

让我们探索更多的可能性

最初,我们尝试使用AWS CLI运行多个命令以从AWS实例检索信息。但是,由于安全策略的存在,对大多数命令的访问被拒绝,如下面的图9所示:

图9:ListBuckets操作上的访问被拒绝
我们还知道托管策略“AWSElasticBeanstalkWebTier”只允许访问名称以“elasticbeanstalk”开头的S3 buckets :

因此,为了访问S3 bucket ,我们需要知道bucket 名称。Elastic Beanstalk创建名为elasticbeanstalk -region-account-id 的Amazon S3 bucket 。

我们使用之前检索到的信息找到了bucket 名称,如图4所示。

地区:us-east-2
帐号:69XXXXXXXX79
现在,存储桶名称为“ elasticbeanstalk- us-east-2-69XXXXXXXX79 ”。

我们使用AWS CLI以递归方式列出了bucket “elasticbeanstalk -us-east-2-69XXXXXXXX79 ”的bucket resources :

aws s3 ls s3:// elasticbeanstalk-us-east-2-69XXXXXXXX79 /


图10:列出Elastic Beanstalk的S3 Bucket
我们通过递归下载S3资源来访问源代码,如图11所示。

aws s3 cp s3:// elasticbeanstalk-us-east-2-69XXXXXXXX79 / / home / foobar / awsdata -recursive

图11:递归复制所有S3 Bucket Data

从SSRF转向RCE

现在我们有权将对象添加到S3 bucket,我们通过S3 bucket中的AWS CLI上传了一个PHP文件(在zip文件中的webshell101.php),以探索远程代码执行的可能性,但它不起作用因为更新的源代码未部署在EC2实例上,如图12和图13所示:

图12:在S3 bucket中通过AWS CLI上传webshell

图13:当前环境中Web Shell的404错误页面
我们把这个带到了我们的实验室,探讨了一些可能导致我们成为RCE的潜在开发场景。潜在的情景是:

  • 使用CI / CD AWS CodePipeline
  • 重建现有环境
  • 从现有环境克隆
  • 使用S3 bucket URL创建新环境

使用CI / CD AWS CodePipeline:AWS CodePipeline是一种CI / CD服务,可在每次代码更改(基于策略)时构建,测试和部署代码。Pipeline支持GitHub,Amazon S3和AWS CodeCommit作为源提供程序和多个部署提供程序(包括Elastic Beanstalk)。有关其工作原理的AWS官方博客可在此处找到:
https://aws.amazon.com/cn/getting-started/tutorials/continuous-deployment-pipeline/


在我们的应用程序中,软件版本使用AWS Pipeline,S3存储桶作为源存储库,Elastic Beanstalk作为部署提供程序自动执行。

让我们首先创建一个管道,如图14 所示:

图14:管道设置
选择S3 bucket作为源提供程序,S3 bucket name并输入对象键,如图15所示:

图15:添加源阶段
配置构建提供程序或跳过构建阶段,如图16所示:

图16:跳过构建阶段
将部署提供程序添加为Amazon Elastic Beanstalk并选择使用Elastic Beanstalk创建的应用程序,如图17所示:

图17:添加部署提供程序
创建一个新管道,如下面的图18所示:

图18:成功创建新管道
现在,是时候在S3 bucket 中上传一个新文件(webshell)来执行系统级命令,如图19所示:

图19:PHP webshell
在源提供程序中配置的对象中添加该文件,如图20所示:

图20:在对象中添加webshell
使用AWS CLI命令将存档文件上载到S3 bucket,如图21所示:

图21:S3中的Cope webshell
aws s3 cp 2019028gtB-InsuranceBroking-stag-v2.0024.zip s3:// elasticbeanstalk-us-east-1-696XXXXXXXXX /

更新新文件的那一刻,CodePipeline立即启动构建过程,如果一切正常,它将在Elastic Beanstalk环境中部署代码,如图22所示:

图22:管道触发
管道完成后,我们就可以访问Web shell并对系统执行任意命令,如图23所示。

图23:运行系统级命令
在这里我们获得了成功的RCE!
重建现有环境: 重建环境会终止其所有资源,删除它们并创建新资源。因此,在这种情况下,它将从S3 bucket部署最新的可用源代码。最新的源代码包含部署的Web shell,如图24所示。

图24:重建现有环境
成功完成重建过程后,我们可以访问我们的webshel​​l并在EC2实例上运行系统级命令,如图25所示:

图25:从webshel​​l101.php运行系统级命令
从现有环境克隆:如果应用程序所有者克隆环境,它将再次从S3 bucket中获取代码,该存储桶将使用Web shell部署应用程序。克隆环境流程如图26所示:

图26:从现有环境克隆
创建新环境: 在创建新环境时,AWS提供了两个部署代码的选项,一个用于直接上载存档文件,另一个用于从S3 bucket中选择现有存档文件。通过选择S3存储桶选项并提供S3 bucket URL,将使用最新的源代码进行部署。最新的源代码包含部署的Web shell。

参考文献:

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/iam-instanceprofile.html
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.S3.html
https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html
https://gist.github.com/BuffaloWill/fa96693af67e3a3dd3fb
https://ipinfo.io

原文地址:https://www.notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖