在AWS Elastic Beanstalk中利用SSRF

在本博客中，我们的“ 高级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：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/

源链接

Hacking more

...