意义

  • 研究云环境下的SSRF意义:
    • 1.有助于 已授权的渗透测试,更好地利用云环境下的SSRF漏洞
    • 2.有助于 提高企业云安全能力(增强对云环境下的SSRF攻击的检测、防御)
    • 3.有助于 安全研究人员继续探索
    • ...

意义较大,故逐字翻译,带上了注释,以供参考。

《Detecting Server-Side Request Forgery Attacks on Amazon Web Services》
Author: Sean McElroy
Advisor: Tanya Baccam
Accepted: November 9, 2019

摘要

"云基础架构"(Cloud infrastructure)通过提供丰富的APIs,为企业提供了显着优势:让企业具备了对环境进行大规模地自动化管理的能力。
与此同时,威胁行动者也可通过未授权访问云环境的"管理API"(management APIs),迅速获取大量敏感数据。业内已经记录过了利用SSRF漏洞->访问云提供商自带的管理API->获取云服务器访问权限的技术。
但是,成熟的企业有时候甚至在安全事件发生后的几个月内,都未能发现某些最值得关注的违规行为。企业使用云服务的情况越来越多,企业需要一些有效的方法来检测SSRF类型的攻击尝试,以识别威胁并"缓解漏洞"(mitigate vulnerabilities)。
本文研究了多种工具和技术,以检测Amazon Web Services (AWS)环境中的SSRF活动,该工具和技术可用于实时监视针对AWS API的SSRF攻击尝试。研究结果概述了4种不同的策略的有效性,以回答安全专业人员的这个问题“是否可以利用其他供应商提供的、或是开源的那些工具来检测SSRF攻击”。

1. Introduction

因为在技术更新周期中,企业已经用高度可扩展的外包产品(云服务)取代了本地设备。所以"云基础设施即服务"(Cloud infrastructure-as-a-service)提供商经历了巨大的增长。

  • 云服务提供商
    • Amazon Web Services (AWS)
    • Microsoft Azure
    • Google Cloud Engine
    • ...
  • 云服务对于企业的吸引力
    • 优化成本
    • 无需为基础设施做大量投资即可进行实验
  • 云服务提供商 为计算、存储提供的云服务通常有2种计费模式
    • "按分钟数计费的模式"(Per-minute billing models)
    • "按工作量计费的模式"(workload bidding models)

云服务吸引了技术人员和开发人员,比如即付即用"(Pay-as-you-go)的"机器学习分析"、"自然语言处理"等服务。

云服务提供商的管理面板的丰富API,允许以最小的人工工作,即可进行大规模的复杂部署。 新的工具链已经出现(如Ansible、Terraform等),以实现"基础设施即代码"(infrastructure as code)并跟踪全球的分布式资源的状态,这突显了这些API的广度。如果不用云服务,管理它们将是越来越复杂。 首先,这些云服务旨在实现快速"原型设计"(prototyping),采用和部署,并采用一个值得信任的、优先考虑自动化的模式。

易受SSRF攻击的系统都有一个共同的注入漏洞:输入验证不足,不当的处理允许未授权的访问或修改"下层系统"或"连通的系统"(OWASP, 2017)。当一个client可以将命令注入到server进程,而server进程又从该进程的上下文中重新发出该命令时,就可以认定存在SSRF漏洞。
攻击者可以利用SSRF漏洞发出HTTP请求到内部资源,对于AWS,可以访问的敏感内部资源就是EC2的
"实例元数据服务"(Instance Metadata service,IMS)。IMS在许多方面提供了自动化工具,包括返回"临时凭证"(temporary credentials),攻击者可以通过AWS API来利用这些凭证以实现访问和操作其他云资源。

译者注:众所周知,Amazon Elastic Compute Cloud (Amazon EC2)中的每个实例,都可以通过执行curl -s http://169.254.169.254/user-data/,对IP169.254.169.254发出HTTP请求,来获取该云实例自身的元数据。

非云环境的情况
"本地"(on-premises)或"共存"(co-located)环境为工程师提供了安装入侵检测系统(IDS)的机会,入侵检测系统可以检测注入和SSRF攻击。

云环境的情况
但从历史上看,像AWS这样的云服务,既不允许在其管理的基础设施中配置物理设备,也没有提供可以利用传统的"数据包捕获和分析技术"(packet capture and analysis techniques)用于检测威胁的功能:"port mirroring"或"span port"。 虽然管理员可以在AWS中部署"内联虚拟设备"(inline virtual appliances),例如"审查代理"(inspection proxies),但可伸缩性模式通常需要"多层的弹性负载均衡器"(multiple layers of Elastic Load Balancers)去支持内联IDS策略。此外,直到2017年,弹性负载均衡器只能处理TCP流量(Amazon Web Services, 2017)。

然而,最近可用的特性,如"AWS VPC流量镜像"(AWS VPC Traffic Mirroring),现在原生支持云环境下的带外IDS设计。此外,SSRF攻击通常会留下一些artifacts,可以通过"云原生"(cloud-native)威胁检测产品检测到,如Amazon GuardDuty等。有时还会通过"主机设施"(host facilities)如auditd和iptables等检测到。

本文研究了开源的、以及云服务商提供的这些工具和技术在“检测这些SSRF攻击尝试”的有效性。

2. Research Method

注入漏洞已被充分记录,并被广泛使用了20多年(rain.forest.puppy,1998)。
SSRF攻击通常被描述为“诱使存在SSRF漏洞的系统发送HTTP请求的攻击”,但它可以利用可通过一个URI来寻址其他应用层协议,或者在收集敏感数据之外还可以做更多的事情。

  • SSRF攻击向量
    • HTTP
    • FTP (ERPScan, 2013)
    • 能够映射内部环境的XXE攻击(Institute of Information Security, 2015)
    • 能够实现远程代码执行的SSRF变体。这些SSRF变体在用作传递Shellshock payload的一个通道时可实现远程代码执行(Kettle, 2017)
  • 通常,可回显的SSRF漏洞才能"控制"AWS API, 即满足3个条件:
    • 可注入
    • 可处理,应用能够错误处理payload, 并向AWS API发出请求
    • 可回显,攻击者可以观察到AWS API的响应

Figure 1 Overview of an SSRF attack against EC2 Instance Metadata Service to access a protected S3 bucket

下面,Figure 2提供了一个满足这3个条件的web应用程序示例:有SSRF漏洞的Node.js Express。

Figure 2 Excerpt of a Node.js Express program vulnerable to SSRF

const request = require('request');
app.get('/avatar’, function(req, response){
    request.get(request.query['url']).pipe(response);
});

此示例程序的功能:它在webserver上执行,打开并读取一个文件的内容,然后将其返回给调用者,即使该url参数是到远程系统的url。
为什么说此示例程序具有SSRF漏洞?因为一个输入参数的作用是指定文件的位置,且该函数未做任何输入验证,所以攻击者可以利用这个SSRF漏洞使webserver发出一个HTTP GET请求,从而间接访问webserver相关的"受保护的资源"(本应该只有webserver本身才能直接访问的"受保护的资源")。

  • 这项研究在一个运行于Amazon Linux 2的实例(即AWS EC2 t3a.small实例)进行实验:
    • web应用 - 在这个实例上部署了有SSRF漏洞的Node.js应用程序“示例程序”(Art, 2016)。
    • 明文流量 - Elastic Load Balancer终止了TLS(注:应是指解密、卸载TLS流量)以提供该服务器流量的明文分析。
    • 实验操作 - 通过发送SSRF payload到EC2 IMS,payload中的url为http://169.254.169.254/iam/security-credentials/role-name
    • 成功标志 - 如果外部的测试发送以上payload后,能够从内部实例获取到了"临时凭证",则成功。
  • 对于每个测试,研究人员均审查了云上设施(Amazon GuardDuty,AWS VPC Traffic Mirroring)、基于主机的设施(auditd、iptables)。以确定2个问题:
    • 1.是否每个系统都可以准确识别请求或响应
    • 2."发现结果"(findings)是否可以区分出 "真实攻击" 和 "非攻击" 的EC2 IMS访问

利用AWS云的动态能力,研究人员在每次测试前都重新创建了靶机(有漏洞的目标主机),以确保观察到确实使用了新的临时凭证。如果不这么做的话就无法观察,因为临时凭证可能几个小时都不会变。

本实验用的实例类型为t3a.small,它足以最小化测试这4种检测方法,因为t3a.small是被称为“AWS Nitro”的下一代实例的一部分。“AWS Nitro”支持VPC流量镜像(Amazon Web Services, 2017)。

3. Findings and Discussion

3.1. AWS Attack Surface Area

AWS发布了一些最佳实践,这些最佳实践不鼓励配置长期有效的"AWS API凭据"(AWS API credentials),并鼓励通过"实例配置文件"(Instance Profile)将"身份和访问管理(Identity and Access Management,IAM)角色"应用于EC2实例。
当"策略"(Policies)被附加到一个IAM角色(链接到一个"实例配置文件"的IAM角色)的时候 "策略"(Policies)授予了被应用到实例的"AWS资源"的权限。运行在EC2实例上的那些 与"实例配置文件"关联了的IAM角色的进程,可以通过查询EC2 IMS获得临时的AWS API凭据,具体方法就是在众所周知的link-local的IP地址169.254.169.254处查询。(Amazon Web Services, 2019).

运行在 具有一个与"实例配置文件"相关联的IAM角色的EC2实例上的 这些进程,才能够通过查询EC2 IMS获得临时AWS API凭据,方法是查询众所周知的 link-local IP地址169.254.169.254.(Amazon Web Services, 2019).
原文:Processes running on an EC2 instance with an IAM role associated with the instance profile can obtain temporary AWS API credentials by querying the EC2 IMS, at the well-known, link-local IP address 169.254.169.254. (Amazon Web Services, 2019).

EC2实例被隐式信任地访问在169.254.169.254上提供的IMS,不需要特殊的HTTP request header,不需要做身份验证。

  • 当EC2实例与一个IAM角色相关联时,可以使用这2个path来发现该IAM角色的名称,并使用该角色已被授予的权限从临时凭据获取一个"访问密钥"(access key):
    • 1.iam/info
    • 2.iam/security-credentials/role-name
  • 为了衡量每一个"检测研究"活动,找了3个有意义的、可观测的指标:
    • 指标1. 能否检测到一个HTTP请求(payload1),该请求尝试获取 已经attached到“靶机”的那个IAM角色的名称 (the request for the name of the IAM role attached to the vulnerable machine)
    • 指标2. 能否检测到一个HTTP请求(payload2),该请求尝试从EC2 IMS 获取一个凭证
    • 指标3. 能否检测到一个HTTP response,该响应从EC2 IMS处响应,其中包含了一个"临时访问密钥"(temporary access key)

3.2. Detection using Amazon GuardDuty

测试Amazon GuardDuty的检测能力。

简介:AWS将GuardDuty描述为“持续的安全监控服务”(Amazon Web Services, 2019),尽管它不是传统的IDS、IPS。该服务为管理员提供了“上传可信或恶意IP地址列表”的能力,这些列表将指导管理员对"发现结果"(findings)的评估,尽管它没有为其内置的"结果类型"(finding types)提供其他配置选项。尽管GuardDuty在事件发生后生成结果的速度相对较快,但它并不是一个实时的检测机制。

指标1. 能否检测到一个HTTP请求(payload1),该请求尝试获取 已经attached到“靶机”的那个IAM角色的名称

在本测试的第一部分中,发送HTTP请求到https://site/?url=http://169.254.169.254/latest/meta-data/iam/info

EC2 IMS返回的Response 见Figure 3:

Figure 3 Vulnerable application exposing EC2 IAM Role after SSRF

如下图Figure 4,在一小时之后的一段时间内,GuardDuty对这个"收集角色的名称的HTTP请求",没有发现任何"侦察结果"(reconnaissance findings)。这一步是“从IMS中获取临时凭证”的第一步。

Figure 4 GuardDuty without findings after an SSRF attack

指标2. 能否检测到一个HTTP请求(payload2),该请求尝试从EC2 IMS 获取一个凭证

接下来,访问https://site/?url=http://169.254.169.254/latest/metadata/iam/security-credentials/msise-ssrf-ec2-role将取回一个临时访问凭证,见Figure 5。

Figure 5 Exfiltrated AWS temporary credential after successful SSRF

同样,经过一个小时的观察,GuardDuty并未发现SSRF攻击

指标3. 能否检测到一个HTTP response,该响应从EC2 IMS处响应,其中包含了一个"临时访问密钥"(temporary access key)

从远程计算机运行以下命令(见Figure 5),即使用"窃取到的凭据"来列出这个帐户中的S3 buckets:

Figure 6 Post-SSRF exploitation commands to confirm AWS API access
```

点击收藏 | 2 关注 | 1
登录 后跟帖