译者注:本文将出现大量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)两种环境配置。
- Web服务器环境 – 主要适合运行Web应用程序或Web API。
- 工作线程环境 – 适合后台工作,长时间运行的流程。
在zip或war文件中提供有关应用程序,环境和上传应用程序代码的信息来配置新应用程序。
新环境配置后,AWS会自动创建S3存储桶(Storage bucket)、安全组、EC2实例以及aws-elasticbeanstalk-ec2-role(默认实例配置文件,按照默认权限被映射到EC2实例)。<br />从用户计算机部署代码时,zip文件中的源代码副本将被放入名为elasticbeanstalk – region-account-id的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 – 授予日志上传,调试,指标发布(metric publication)和Woker实例任务的权限,其中包括队列管理,领导选择(leader election)和定期任务。
- AWSElasticBeanstalkMulticontainerDocker – 授予Amazon Elastic容器服务协调集群任务的权限。
策略“ 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
在SSRF确认存在后,我们(使用https://ipinfo.io等服务)通过服务器指纹识别确认服务提供商为亚马逊。此后,我们尝试通过多个端点查询AWS元数据,例如:
- http://169.254.169.254/latest/dynamic/instance-identity/document
- http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role
通过API“http://169.254.169.254/latest/dynamic/instance-identity/document”中获取帐户ID和地区信息:
注意:“ aws-elasticbeanstalk-ec2-role” 中 IAM安全凭证表示应用程序部署在Elastic Beanstalk上。<br />我们进一步在AWS命令行界面(CLI)中配置,如图7所示:
“aws sts get-caller-identity”命令的输出表明令牌有效,如图8所示:
图8:AWS CLI输出:get-caller-identity
到目前位置,一切顺利,可以确定这是个标准的SSRF漏洞。不过好戏还在后头…..我们好好发挥下:最初,我们尝试使用AWS CLI运行多个命令来从AWS实例获取信息。但是如下面的图9所示,由于安全策略,大多数命令被拒绝访问:
之前介绍过托管策略“AWSElasticBeanstalkWebTier”只允许访问名称以“elasticbeanstalk”开头的S3存储桶:<br />因此,我们需要先知道存储桶名称,才能访问S3存储桶。Elastic Beanstalk创建了名为elasticbeanstalk-region-account-id的Amazon S3存储桶。我们使用之前获取的信息找到了存储桶名称,如图4所示。
- 地区:us-east-2
- 帐号:69XXXXXXXX79
存储桶名称为“ elasticbeanstalk- us-east-2-69XXXXXXXX79 ”。我们使用AWS CLI以递归方式列出它的桶资源:aws s3 ls s3//elasticbeanstalk-us-east-2-69XXXXXXXX79/
我们通过递归下载S3资源来访问源代码,如图11所示。aws s3 cp s3:// elasticbeanstalk-us-east-2-69XXXXXXXX79 / / home / foobar / awsdata -recursive
从SSRF到RCE
现在我们有权限将对象添加到S3存储桶中,我们通过AWS CLI向S3存储桶中上传一个PHP文件(zip文件里webshell101.php),尝试实现远程代码执行。然而并不起作用,因为更新的源代码未部署在EC2实例上,如图12和图13所示:
图12:在S3存储桶中通过AWS CLI上传webshell
我们围绕这个开展了一些实验并整理了一些可能导致RCE的潜在利用场景:
- 使用CI/CD AWS CodePipeline(持续集成/持续交付AWS管道)
- 重建现有环境
- 从现有环境克隆
- 使用S3存储桶URL创建新环境
使用CI/CD AWS CodePipeline:AWS管道是一种CI/CD服务,可(基于策略)在每次代码变动时构建,测试和部署代码。管道支持GitHub,Amazon S3和AWS CodeCommit作为源提供方和多个部署提供方(包括Elastic Beanstalk)。有关其工作原理可见此处AWS官方博客:
在我们的应用程序中,软件版本管理使用AWS Pipeline,S3存储桶作为源仓库,Elastic Beanstalk作为部署提供方实现自动化。首先创建一个管道,如图14 所示:
选择S3 bucket作为源提供方,S3 bucket name并输入对象键,如图15所示:
配置构建提供方或跳过构建阶段,如图16所示:
将部署提供方设置为Amazon Elastic Beanstalk并选择使用Elastic Beanstalk创建的应用程序,如图17所示:
创建一个新管道,如下面的图18所示:
之后在S3存储桶中上传一个新文件(webshell)来执行系统命令,如图19所示:
在源提供方配置的对象中添加该文件,如图20所示:
使用AWS CLI命令将存档文件上传到S3存储桶,如图21所示:
aws s3 cp 2019028gtB-InsuranceBroking-stag-v2.0024.zip s3://elasticbeanstalk-us-east-1-696XXXXXXXXX/
更新文件时,CodePipeline立即启动构建过程。如果一切正常,它将在Elastic Beanstalk环境中部署代码,如图22所示:
图22:管道触发
管道完成后,我们就可以访问Web shell并对系统执行任意命令,如图23所示。
成功实现RCE!重建现有环境: 重建环境会终止删除、所有资源并创建新资源。因此,在这种情况下,它将从S3存储桶部署最新的可用源代码。最新的源代码包含部署的Web shell,如图24所示。
成功完成重建过程后,我们可以访问我们的webshell并在EC2实例上运行系统命令,如图25所示:
从现有环境克隆:如果应用程序所有者克隆环境,它将再次从S3存储桶中获取代码,该存储桶将部署一个带有Web shell的Web应用。克隆环境流程如图26所示:
创建新环境: 在创建新环境时,AWS提供了两个部署代码的选项,一个用于直接上传存档文件,另一个用于从S3存储桶中选择现有存档文件。通过选择S3存储桶选项并提供S3存储桶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
发表评论
您还未登录,请先登录。
登录