文章有点长，但是绝对很值！原文地址：https://notsosecure.com/exploiting-ssrf-aws-elastic-beanstalk
内容速递
该博客主要讲述：发现并利用服务器端请求伪造 (SSRF) 漏洞来访问敏感数据，此外，还讨论了可能导致在 AWS Elastic Beanstalk 上使用持续部署 (CD) 管道部署的应用程序执行远程代码执行 (RCE) 的潜在领域。
AWS Elastic Beanstalk
AWS Elastic Beanstalk 是 AWS 提供的平台即服务 (PaaS) 产品，用于部署和扩展针对 Java、.NET、PHP、Node.js、Python、Ruby 和 Go 等各种环境开发的 Web 应用程序。它自动处理部署、容量配置、负载平衡、自动扩展和应用程序健康监控。
配置环境
AWS Elastic Beanstalk 支持 Web 服务器和 Worker 环境预置。
- Web 服务器环境——通常适合运行 Web 应用程序或 Web API。
- 工作环境——适合后台作业、长时间运行的进程。
可以通过提供有关应用程序、环境的一些信息以及在 zip 或 war 文件中上传应用程序代码来配置新应用程序。下图为创建的Elastic Beanstalk 环境：
配置新环境时，AWS 会创建一个 S3 存储桶、安全组和一个 EC2 实例。它还创建一个名为aws-elasticbeanstalk-ec2-role的默认实例配置文件，该配置文件映射到具有默认权限的 EC2 实例。
从用户计算机部署代码时，zip 文件中的源代码副本被放置在名为elasticbeanstalk region-account-id的 S3 存储桶中,下图为Amazon S3 存储桶：
Elastic Beanstalk 不会为其创建的 Amazon S3 存储桶打开默认加密。这意味着默认情况下，对象未加密存储在存储桶中（并且只能由授权用户访问）。
阅读更多：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 存储桶进行有限的列出、读取和写入权限。仅当存储桶名称以“ elasticbeanstalk- ”开头时才可访问存储桶，并且还授予递归访问权限。
阅读更多：https ://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html
实践过程
当我们继续我们的常规渗透测试时，我们在应用程序中遇到了服务器端请求伪造 (SSRF) 漏洞。通过对外部域进行DNS 调用确认了该漏洞，并通过访问配置为仅允许 localhost 访问它的“localhost/server-status”进一步验证了这一点，下图是通过访问受限页面确认存在SSRF漏洞。
staging.xxxx-redacted-xxxx.com/view_pospdocument.php?doc=localhost/server-status
一旦 SSRF 得到确认，我们就会通过使用https://ipinfo.io等服务的服务器指纹识别来确认服务提供商是亚马逊。此后，我们尝试通过多个端点查询AWS 元数据，例如：
- 169.254.169.254/latest/dynamic/instance-identity/document
- 169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role
我们从 API “169.254.169.254/latest/dynamic/instance-identity/document” 中检索了账户 ID 和区域:
然后，我们从 API “169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role”检索访问密钥、秘密访问密钥和令牌：
注意：“ aws-elasticbeanstalk-ec2-role”的 IAM 安全凭证表明应用程序部署在 Elastic Beanstalk 上。
我们进一步配置了AWS 命令行界面（CLI），如图所示：
“aws sts get-caller-identity”命令的输出表明令牌工作正常，如图所示：
所以，到目前为止，一切都很好。相当标准的 SSRF 漏洞利用，对吧？这就是它变得有趣的地方......
探索更多
最初，我们尝试使用 AWS CLI 运行多个命令以从 AWS 实例中检索信息。但是，由于现有的安全策略，对大多数命令的访问被拒绝，如下图所示：
托管策略“AWSElasticBeanstalkWebTier”只允许访问名称以“elasticbeanstalk”开头的 S3 存储桶：因此，为了访问 S3 存储桶，我们需要知道存储桶名称。Elastic Beanstalk 创建一个名为elasticbeanstalk -region-account-id的 Amazon S3 存储桶。
使用之前检索到的信息找到了存储名称：
- 地区：us-east-2
- 帐号 ID：69XXXXXXXX79
现在，存储桶名称为“ elasticbeanstalk -us-east-2-69XXXXXXXX79 ”。
我们使用 AWS CLI 以递归方式列出了存储桶“elasticbeanstalk -us-east-2-69XXXXXXXX79 ”的存储桶资源：
aws s3 ls s3://elasticbeanstalk-us-east-2-69XXXXXXXX79/
我们通过递归下载 S3 资源来访问源代码，如图所示。
aws s3 cp s3://elasticbeanstalk-us-east-2-69XXXXXXXX79/ /home/foobar/awsdata –recursive
从 SSRF 转向 RCE
现在我们有权将对象添加到 S3 存储桶，我们通过 AWS CLI 在 S3 存储桶中上传了一个 PHP 文件（zip 文件中的 webshell101.php），以探索远程代码执行的可能性，由于更新后的源代码没有部署在 EC2 实例上使得它不起作用，如下两张图所示：
通过 AWS CLI 在 S3 存储桶中上传 webshell:
当前环境下 Web Shell 的 404 错误页面:
由上述情况分析，发现需要如下步骤：
- 使用 CI/CD AWS CodePipeline
- 重建现有环境
- 从现有环境克隆
- 使用 S3 存储桶 URL 创建新环境
使用 CI/CD AWS CodePipeline： AWS CodePipeline 是一项 CI/CD 服务，每当代码发生更改时（基于策略），它都会构建、测试和部署代码。Pipeline 支持将 GitHub、Amazon S3 和 AWS CodeCommit 作为源提供者以及包括 Elastic Beanstalk 在内的多个部署提供者。有关其工作原理的 AWS 官方博客可在此处找到：
就我们的应用程序而言，软件发布是使用 AWS Pipeline、S3 存储桶作为源存储库和 Elastic Beanstalk 作为部署提供商自动发布的。
让我们首先创建一个管道，管道设置如图所示：
选择 S3 存储桶作为源提供者，S3 存储桶名称并输入对象键，添加源阶段如图所示：
配置构建提供程序或跳过构建阶段，跳过构建阶段如图所示：
添加部署提供商作为 Amazon Elastic Beanstalk 并选择使用 Elastic Beanstalk 创建的应用程序，添加部署提供程序如图所示：
将创建一个新管道，新管道创建成功如下图所示：
现在，是时候在 S3 存储桶中上传一个新文件 (webshell) 以执行系统级命令，PHP webshell如图所示：
将文件添加到源提供程序中配置的对象中，在对象中添加 webshell如图所示：
使用 AWS CLI 命令将存档文件上传到 S3 存储桶，在 S3 存储桶中处理 webshell如图所示：
aws s3 cp 2019028gtB-InsuranceBroking-stag-v2.0024.zip s3://elasticbeanstalk-us-east-1-696XXXXXXXXX/
新文件更新后，CodePipeline 立即启动构建过程，如果一切正常，它将在 Elastic Beanstalk 环境中部署代码，管道触发如图所示：
一旦管道完成，我们就可以访问 web shell 并对系统执行任意命令，运行系统级命令如图所示。
在这里，我们获得了成功的 RCE！
重建现有环境：重建环境会终止其所有资源，删除它们并创建新资源。因此，在这种情况下，它将部署 S3 存储桶中最新的可用源代码。最新的源代码包含已部署的 Web shell，重建现有环境如图所示。
重建过程成功完成后，我们可以访问我们的 webshell 并在 EC2 实例上运行系统级命令，从 webshell101.php 运行系统级命令如图所示：
从现有环境克隆：如果应用程序所有者克隆环境，它会再次从 S3 存储桶中获取代码，该存储桶将使用 Web shell 部署应用程序。克隆环境流程如图所示：
创建新环境：在创建新环境时，AWS 提供了两种部署代码的选项，一种用于直接上传存档文件，另一种用于从 S3 存储桶中选择现有存档文件。通过选择 S3 存储桶选项并提供 S3 存储桶 URL，将使用最新的源代码进行部署。最新的源代码包含部署的 web shell。
参考：
