在AWS Elastic Beanstalk中利用SSRF

译者注:本文将出现大量AWS官方词汇，对于一些中文字面意思难以理解的词汇，为便于读者理解将在首次出现时同时给出中英词汇，方便读者在AWS官方文档中查阅。（中文文档与英文文档）

本文，我们“ Advanced Web Hacking”培训课程的首席培训师Sunil Yadav将讨论一个案例研究:识别并利用一种服务器端请求伪造（SSRF）漏洞来访问敏感数据（例如源代码）。此外，该博客还讨论了可能导致（使用持续部署管道，即Continuous Deployment pipeline）部署在AWS Elastic Beanstalk上应用程序远程代码执行（RCE）的风险点。

AWS Elastic Beanstalk

AWS Elastic Beanstalk（译者注:官方译为平台即服务技术，通常以英文原文出现，故不作翻译）是AWS提供的一款平台即服务（PaaS）产品，主要用于部署和扩展各种开发环境的Web应用程序（如Java，.NET，PHP，Node.js，Python，Ruby和Go等）。它支持自动化的部署，容量分配，负载均衡，自动扩展（auto-scaling）和应用程序运行状况监视。

 

准备环境

AWS Elastic Beanstalk支持Web服务器(Web Server)和工作线程(Worker)两种环境配置。

在zip或war文件中提供有关应用程序，环境和上传应用程序代码的信息来配置新应用程序。

图1：创建Elastic Beanstalk环境

新环境配置后，AWS会自动创建S3存储桶(Storage bucket)、安全组、EC2实例以及aws-elasticbeanstalk-ec2-role（默认实例配置文件，按照默认权限被映射到EC2实例）。<br />从用户计算机部署代码时，zip文件中的源代码副本将被放入名为elasticbeanstalk – region-account-id的S3存储桶中。

图2：Amazon S3存储桶

Elastic Beanstalk默认不加密其创建的Amazon S3存储桶。这意味着默认情况下，对象以未加密的形式存储在桶中（并且只能由授权用户访问）。详见：https：//docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.S3.html默认实例配置文件的托管策略 – aws-elasticbeanstalk-ec2-role：

策略“ AWSElasticBeanstalkWebTier ”允许对S3存储桶有限的列取，读取和写入权限。只有名称以“ elasticbeanstalk- ” 开头且有递归访问权限的存储桶才能被访问。

图3：托管策略 – “AWSElasticBeanstalkWebTier”

详见：https：//docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.html

 

分析

在日常渗透测试中，我们遇到了某应用程序的服务器端请求伪造（SSRF）漏洞。通过对外部域进行DNS调用(译者注:属于带外攻击OOB一种)确认漏洞，并通过访问仅允许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/dynamic/instance-identity/document”中获取帐户ID和地区信息：

图5：AWS元数据-获取帐户ID和地区信息

然后，通过API“http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role”获取访问密钥ID，加密访问密钥和令牌：

图6：AWS元数据-获取访问密钥ID、加密访问密钥和令牌

注意：“ aws-elasticbeanstalk-ec2-role” 中 IAM安全凭证表示应用程序部署在Elastic Beanstalk上。<br />我们进一步在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存储桶：<br />因此，我们需要先知道存储桶名称，才能访问S3存储桶。Elastic Beanstalk创建了名为elasticbeanstalk-region-account-id的Amazon S3存储桶。我们使用之前获取的信息找到了存储桶名称，如图4所示。

存储桶名称为“ elasticbeanstalk- us-east-2-69XXXXXXXX79 ”。我们使用AWS CLI以递归方式列出它的桶资源：aws s3 ls s3//elasticbeanstalk-us-east-2-69XXXXXXXX79/

图10：列出Elastic Beanstalk的S3存储桶

我们通过递归下载S3资源来访问源代码，如图11所示。aws s3 cp s3：// elasticbeanstalk-us-east-2-69XXXXXXXX79 / / home / foobar / awsdata -recursive

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

 

从SSRF到RCE

现在我们有权限将对象添加到S3存储桶中，我们通过AWS CLI向S3存储桶中上传一个PHP文件（zip文件里webshell101.php），尝试实现远程代码执行。然而并不起作用，因为更新的源代码未部署在EC2实例上，如图12和图13所示：

图12：在S3存储桶中通过AWS CLI上传webshell

图13：当前环境中Web Shell的404错误页面

我们围绕这个开展了一些实验并整理了一些可能导致RCE的潜在利用场景：

使用CI/CD AWS CodePipeline：AWS管道是一种CI/CD服务，可（基于策略）在每次代码变动时构建，测试和部署代码。管道支持GitHub，Amazon S3和AWS CodeCommit作为源提供方和多个部署提供方（包括Elastic Beanstalk）。有关其工作原理可见此处AWS官方博客：

在我们的应用程序中，软件版本管理使用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存储桶中上传一个新文件（webshell）来执行系统命令，如图19所示：

图19：PHP webshell

在源提供方配置的对象中添加该文件，如图20所示：

图20：在对象中添加webshell

使用AWS CLI命令将存档文件上传到S3存储桶，如图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存储桶部署最新的可用源代码。最新的源代码包含部署的Web shell，如图24所示。

图24：重建现有环境

成功完成重建过程后，我们可以访问我们的webshell并在EC2实例上运行系统命令，如图25所示：

图25：从webshell101.php运行系统级命令

从现有环境克隆：如果应用程序所有者克隆环境，它将再次从S3存储桶中获取代码，该存储桶将部署一个带有Web shell的Web应用。克隆环境流程如图26所示：

图26：从现有环境克隆

创建新环境： 在创建新环境时，AWS提供了两个部署代码的选项，一个用于直接上传存档文件，另一个用于从S3存储桶中选择现有存档文件。通过选择S3存储桶选项并提供S3存储桶URL，将会使用最新的源代码进行部署。而被部署的最新源代码中含有Web shell。

 

参考文档：

源链接

Hacking more

...