云安全 - 研究云环境下对SSRF的检测与防御（以AWS为例）
2020-02-13 11:13:30 Author: xz.aliyun.com(查看原文) 阅读量:515 收藏

意义

  • 研究云环境下的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

$ export AWS_ACCESS_KEY_ID=ASIA....MJ3S
$ export AWS_SECRET_ACCESS_KEY=D397Z....OMdp
$ export AWS_SESSION_TOKEN=AgoJb3....Z4hk=
$ aws s3 ls
2019-09-15 17:10:49 msise-ssrf

使用"窃取到的凭据"6分钟后，GuardDuty确定了"凭证泄露"，但检测到的是"SSRF攻击后的活动"(postSSRF attack activity)，而不是SSRF本身，如Figure 7所示。

Figure 7 GuardDuty post-SSRF exploitation finding upon external credential use

最终可见，GuardDuty无法检测到SSRF攻击和凭据泄露。
因为，如果在"生成这些凭据的EC2实例"之外去使用这些凭据，则GuardDuty会生成一个"发现结果"，类型为UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration。但这并不是发现了SSRF攻击本身，因此可以成功实现SSRF的威胁行动者可能已经有足够的权限执行其他恶意操作。如果攻击者可以通过"命令注入"(command injection)使用凭据发出其他命令，则GuardDuty可能无法识别"攻击后的活动"(post-exploitation activity)。

为什么GuardDuty没起作用？

  • 根据GuardDuty的文档，它分析并生成的"发现结果"的多个源中并不包括"payload content"，而只是3种**元数据：
    • VPC Flow Logs
    • AWS CloudTrail event logs
    • DNS logs

这3个元数据并不足以检测"访问一个link-local地址的SSRF攻击"，因为link-local地址并不会显示在VPC Flow Logs中，也不会发出DNS解析请求。

3.3. Detection using VPC Traffic Mirroring

测试VPC Traffic Mirroring的检测能力。

"VPC流量镜像"(VPC Traffic Mirroring)提供了入站流量和出站流量的拷贝，在哪里提供？
VPC流量镜像在一个Elastic Network Interface (ENI)上，这个ENI已经attached到需要被镜像的source，这个source指向一个指定的target的ENI。
VPC Traffic Mirroring provides a copy of network traffic, both inbound and outbound, on an Elastic Network Interface (ENI) attached to the desired source to the ENI of a designated target.

"VPC流量镜像"服务仅提供获取网络流量的机制，而不处理或分析网络流量。
实现者有责任以"离线配置"(out-of-line configuration)来部署、配置和维护IDS，以生成有意义、有用的安全事件。

Figure 8 Network diagram of lab environment

VPC流量镜像很容易设置，因为一个"镜像会话"(mirroring session)的source和"target都是基于AWS Nitro的实例。虽然AWS VPC Traffic Mirroring的文档使用术语"源"source和"目标"target，在这里可以简单认为，运行了IDS的target(实例)将能够观察到attached到source(实例)的那个ENI的请求和响应。
source ---> target

具体怎么做流量镜像？
研究人员创建了一个流量镜像会话以读取source的所有TCP流量。该会话使用"流量过滤器¾"(Traffic Filter¾)中的0.0.0.0/0的source和destination，从具有漏洞服务的实例上的sourceENI，到具有"第二个"专用ENI的target，读取所有TCP流量。
The researcher created a traffic mirroring session that read all TCP traffic using a 0.0.0.0/0 source and destination in the Traffic Filter¾ from the “source” ENI on the instance with the vulnerable service to a target with a second ENI dedicated.

除了 针对于source(实例)的那些以便于观察到payloads的"流量过滤器规则"之外，AWS仍会评估target(实例)的安全组规则。

Figure 9 AWS VPC Traffic Mirroring filter configuration

研究人员通过测试sudo tcpdump -vi eth1验证了初步配置，其中的eth1就是"第二个"专用ENI专用于镜像会话的"摄取接口"(ingest interface)。 结果输出显示了SSRF攻击请求和响应的内容payloads，表明Snort，Zeek和其他开源工具都可以检测到它们。

Figure 10 Redacted tpcdump output on target once VPC Traffic Mirroring enabled

因为VPC Traffic Mirroring将"被镜像的流量"封装在VXLAN header中，所以部署到一个流量镜像target上的那个IDS必须能够解析VXLAN conventions，以检查payloads、并做告警。
尽管Snort 2.9.14.1可以匹配IP packet中的内容，但是它无法解封装VXLAN，从而无法在“解释TCP flow的更精确规则”中使用"流预处理器"(Stream preprocessor)。
使用适用于VPC Traffic Mirroring的网络入侵检测工具执行测试，研究人员确认了：流量镜像功能并未捕获到"本地请求"( local request)，即通过link-local地址(169.254.169.254)向EC2 IMS发出的那些请求。

测试结果，当然是VPC Traffic Mirroring无法检测出3个指标的任何一个。

3.3.1. Detecting SSRF using Zeek

测试Zeek的检测能力。

Zeek，以前叫"Bro"，是一种"网络流量分析"(network traffic analysi,NTA)工具，具有灵活的、基于事件的模型，并支持脚本功能。虽然Zeek是一个专门的基于事件的关联工具，但Zeek 3.0版支持了VXLAN解封装(VXLAN decapsulation)、使用正则表达式的基于签名的检测。

译者注：这里的签名是指Zeek中提供的一种独立的"签名语言"(signature language)，用于进行低级的、Snort格式的正则模式匹配。更多请看Zeek官方资料Signature Framework — Zeek User Manual v3.0.0

有了这些功能，就可以使用以下这2个Zeek"签名定义"(signature definitions)，来标识SSRF请求和响应：

Figure 11 Zeek signature to detect SSRF targeting AWS EC2 IMS (ssrf.sig)

signature aws-ec2-ims-request {
    ip-proto == tcp
    dst-port == 80
    payload /.*meta-data\/iam\/security-credentials/
    event "EC2 Instance Metadata path in request, SSRF attempt"
}
signature aws-ec2-ims-response-access-key {
    ip-proto == tcp
    src-port == 80
    payload /.*\"SecretAccessKey\" :/
    event "Potential AWS IAM temporary credential in HTTP response, successful SSRF exploitation"
}

第一个签名(译者注:可以理解为Zeek的一条检测规则)，可以检测"枚举角色名称的请求"、"获取临时访问凭据的HTTP请求"，因为这两个HTTP请求的path部分，有一部分字符串是相同的，都会被该签名匹配到。

重要的是，该签名省略了路径的“最新”部分，因为特定的IMS协议版本也能被作为获取凭据的目标。使用命令zeek -r request.pcap -s ssrf.sig运行Zeek会生成一个signatures.log文件，该文件详细说明了检测结果：

Figure 12 Zeek signatures.log output showing SSRF detection

3.3.2. Detecting SSRF using Suricata

测试Suricata的检测能力。

虽然Snort当前不支持VXLAN解封装，但Suricata 4.1.5支持。
Suricata是一个开源的入侵检测和防御系统，具有许多与Snort相同的基于签名的功能。尽管Suricata中设置的默认签名集不检测对EC2 IMS的尝试访问，但通过启用VXLAN decoder并为元数据"端点"(endpoint)定义签名后，Suricata可以检测到SSRF尝试。具体检测规则见Figure 13。

Figure 13 Suricata rules that detect SSRF requests and responses with temporary credentials

alert ip any any -> $HOME_NET 80 (msg:"AWS EC2 IMS Recon"; sid:10000001; rev:001; flow:to_server; content:"/metadata/iam/security-credentials";)
alert ip $HOME_NET 80 -> any any (msg:"AWS EC2 IMS Credential Exfil"; sid:10000003; rev:001; flow:to_client,established; content:"\"SecretAccessKey\" :";)

因为Suricata可以正确解释VXLAN封装(VXLAN encapsulation)，所以HTTP活动不会显示为UDP流量，而是显示为基础TCP流。
使用命令suricata -r request.pcap(这个命令很常用！)运行Suricata会生成一个/var/log/suricata/fast.log文件，该文件详细说明了检测：

Figure 14 Suricata alert logs demonstrating detection of SSRF attempts on the EC2 IMS and credential exfiltration

3.4. Detection using iptables

测试iptables的检测能力。

iptables是Amazon Linux上可用的"数据包过滤器"(packet filter)。这种基于规则的功能允许管理员定义用于匹配数据包的参数，然后指定匹配成功时的动作：可用的操作包括"记录"(logging)、"转发"(forwarding)、"丢弃"(dropping)数据包。 观察connectsyscall是监视网络活动的一种非常具体的方法，而iptables提供了匹配条件，包括源IP地址、目标IP地址、协议和目标端口。此外，iptables可以匹配数据包创建者的UID，GID，PID和SID。

有了这种功能，管理员就可以控制EC2实例，在EC2实例中 所有进程都只有唯一的UID，通过使用PID来区分进程，或者在所有进程都被独立的"目的服务主体"(purpose service principals)通过UID或GID区分开的环境中，以最低的误报率可靠地检测SSRF攻击。根据控制环境的不同，可以使用多种方法授权一个进程绑定到一个具有独有UID的"特权端口"(privileged port,The TCP/IP port numbers below 1024)。为了测试iptables是否可以用于检测SSRF，研究人员向Node.js二进制文件授予了"系统功能"(system capability)，允许它使用sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/node命令绑定到1024以下的端口。

  • 然而在生产环境中，更合适的替代策略是：
    • 容器化(containerization)
    • chroot
    • 通过端口地址转换(port address translation)，将负载均衡器的入站HTTP/HTTPS listener映射到主机上的非特权端口(AWS Elastic Load Balancer原生支持这种转换)

使用已知的UID(本例中为1001)作为一个server来处理一些用户请求（我们不希望调用IMS的那些用户请求），可以使用以下iptables命令写入一条检测规则:

sudo iptables -A OUTPUT -p tcp --dport 80 d 169.254.169.254 -m owner --uid-owner 1001 -j LOG

配置完成后，syslog或dmesg会记录下：来自该Node.js服务器的 对IMS的所有访问。 如Figure 15所示：

Figure 15 dmesg output after an iptables LOG rule implemented to log IMS accesses from a publicly accessible server process.

此外，本研究还确定了第2条iptables规则，当把它加到日志规则之后的iptables规则链中时，还可以使用以下命令拒绝出站流量，从而防止SSRF:
sudo iptables -A OUTPUT -p tcp --dport 80 -d 169.254.169.254 -m owner --uid-owner 1001 -j REJECT

应用了这个"reject"规则后，有漏洞的测试程序执行了SSRF，当本地防火墙规则拒绝SSRF连接尝试时，该程序会记录到一个内部错误，由于该程序正确地处理了error情况，所以这条"reject"规则并不会影响用户的体验，Node.js进程向console报告了以下错误:

Figure 16 Application error message when iptables blocked SSRF access via a REJECT rule

iptables需要你具有EC2实例的shell权限：
通过访问EC2实例的shell，系统管理员可以使用"主体隔离"(principal segregation)和iptables来检测和防止SSRF访问IMS。应用程序程序员也可以catch和log这些连接错误，这为安全人员提供另一种方法来识别已被阻止了的SSRF尝试。

没有shell权限就不能使用iptables：
然而，提供给管理员用于部署到其环境的“黑盒(black box)”虚拟设备，比如来自AWS市场，发布者被要求实现适当的SSRF保护，因为客户无法在这些设备上配置基于主机的管控(如iptables)。

3.5. Detection using auditd

测试auditd的检测能力。

auditd是一个系统日志记录工具包，它支持捕获低级别的审计活动。它可以捕获关于各种系统调用(syscalls)的基本信息，并构成许多安全事件检测系统的基础，这些系统将这些数据关联起来并分析潜在的恶意活动。

  • 检测对SSRF攻击有意义的那些系统调用(syscalls)只能有限地缩小误报率。为什么？举几个例子
    • 1.系统调用execve - SSRF攻击连接到已知的主机，但该连接是从具有SSRF漏洞的服务器组件(通常是web服务器)的进程上下文中进行的（并没有生成新进程）。如果一个服务器进程需要生成额外的进程，那么审计execvesyscall(生成一个新程序)并不是可靠的SSRF指示器。
    • 2.系统调用gethostname - 针对IMS的SSRF攻击的目标是一个众所周知的地址，即169.254.169.254，并且不需要将主机名解析为IP地址，所以审计gethostnamesyscall对检测SSRF毫无用处。
    • 3.系统调用connect - 该syscall可以检测针对EC2 IMS的link-local地址169.254.169.254的SSRF活动。通过添加类似Figure 17的审计规则，auditd将socket连接信息记录到了"审计日志"(audit logging)目录中。

Figure 17 Command to add an auditd rule to log the connect() syscall

auditctl -a always,exit -F arch=b64 -S connect

audit.log文件包含了详细信息，有关执行所有已审计的操作的进程上下文的详细信息。
connectsyscall包含：UID，EUID，GID，PID annotations，一个编码了的saddr实参值。
该参数的值是以十六进制格式"socket family"、"port number"、"IP address"进行编码。
对于EC2 IMS来说 saddr = 02000050A9FEA9FE0000000000000000

正如在iptables中所观察到的，安全工程师可以使用"审计记录"(audit records)来观察针对IMS的连接请求，这些请求源自于意外但有效的用户身份。如果管理员对需要IMS访问的进程、不需要IMS访问的进程，使用了不同的uid和gid，则此活动将以较低的误报率识别SSRF请求。

3.6. Discussion of other known detection techniques

其他已知检测技术的讨论。

3.6.1. Inline Firewall Services and Appliances

AWS虚拟私有云(VPC)中的入侵检测和预防系统(IDPS)可以解密和分析流量，有可能观察和阻止访问IMS的尝试。然而，由于云环境使用软件定义网络(SDN)既不支持"广播网络地址"(broadcast network addresses)，传统上不支持"端口镜像"(port mirroring)，或生成捕捉流量的网络交换机或路由器设备，这些策略需要内联设备、基于主机的入侵检测系统(HIDS)，或基于主机的流量转发到IDS collectors。

内联IDS系统在云环境中存在问题：因为它们倾向于"过载"(overloaded)，在SDN约束下无法有效地实现负载平衡以及部署成本。工程师必须部署大量的collectors以实现全面的"入口"(ingress)、"出口"(egress)覆盖 (C. Mazzariello, 2010)。

工程师必须部署大量的collectors，以实现全面的"进入和出口覆盖"(ingress and egress coverage)(C. Mazzariello, 2010)。取而代之的常见的做法是，通常的做法是在低带宽的"出口点"(egress points)实现IDPS或透明代理，以实现显式的的"whitelisting"和"blocking"功能。

在AWS中，"基于主机的流量转发"(Host-based traffic forwarding)存在问题，因为带宽限制与实例类型相关联，而与附加到它们上的网络接口无关(Amazon Web Services, 2019)。

  • 所以，在AWS中“基于主机的流量转发”通常很消耗资源，例如
    • 方案1 克隆和转发流量到IDS收集器。这所消耗的带宽，取决于实例满足其预期业务需求的可用容量。虽然其他人已经详细介绍了使用基于主机的流量转发使用Snort和Zeek (Reese, 2018)，但对成本敏感且高度可扩展的云workloads通常不会提供一个额外的"应用程序处理实例"(application-handling instances) 仅用于维护"基于转发的IDS解决方案"的网络容量。
    • 方案2 HIDS解决方案。 与方案1类似的是，HIDS解决方案在云环境中也受到资源限制，可能导致高计算利用率和packet loss(P. K. Shelke, 2012).

3.6.2. AWS WAF

AWS提供了名为AWS WAF的web应用程序防火墙(web application firewall, WAF)，其操作类似于基于嵌入式设备的WAF解决方案。实现者必须使用AWS的CDN CloudFront来启用AWS WAF。与专业的WAF设备不同，AWS WAF具有相对较少的内置规则来检测对应用程序的OWASP威胁，即用于SQL注入和XSS的"签名"(signatures,注:可以理解为匹配payload的规则)。然而，WAF管理员可以配置字符串和正则表达式匹配条件来检测和阻止SSRF，其他安全工程师已经证明了这一点(Sripati, 2019)。

一般来说，依靠像CDN这样的高度分布式系统 来为"内容审查"(content inspection)提供扩展点来检测SSRF活动是昂贵的，因为进入壁垒对所有企业或所有公开暴露的wrokloads来说可能都是不经济的(Modi, 2017)。但是，在已经使用CloudFront CDN的AWS上的workloads中，使用AWS WAF的ACL来匹配IMS的link-local地址169.254.169.254，可能是一个有意义的"分层防御控制"(layered defensive control)。因为AWS WAF是在HTTP传输层上操作的，所以这个地址可能不太容易出现二进制数据(比如图像文件)中的误报。

3.6.3. Comparing EC2 IP addresses at AssumeRole with Credential Use

官方资料：什么是 AWS CloudTrail？

# AWS CloudTrail 是一项 AWS 服务，可帮助对您的 AWS 账户进行监管、合规性检查、操作审核和风险审核。用户、角色或 AWS 服务执行的操作将记录为 CloudTrail 中的事件。事件包括在 AWS 管理控制台、AWS Command Line Interface 和 AWS 开发工具包和 API 中执行的操作。
# 在您创建 AWS 账户时，将对账户启用 CloudTrail。当您的 AWS 账户中发生活动时，该活动将记录在 CloudTrail 事件中。您可以通过转到事件历史记录来轻松查看 CloudTrail 控制台中的最新事件。要持续记录 AWS 账户中的活动和事件，请创建跟踪。
# 您的 AWS 账户活动的"可见性"是安全和运营最佳实践的重要方面。您可以使用 CloudTrail 来查看、搜索、下载、归档、分析和响应您的 AWS 基础设施中的账户活动。您可以确定谁或哪个组件对哪些资源执行了哪些操作、事件发生的时间以及其他细节，来帮助您分析和响应 AWS 账户中的活动。
# 您可将 CloudTrail 集成到使用 API 的应用程序、为您的组织自动创建跟踪、检查创建的跟踪的状态，以及控制用户查看 CloudTrail 事件的方式。

AWS中，由于EC2实例在启动时就会承担其关联的IAM角色，则“内部AWS EC2服务对 AssumeRole(承担角色) 的调用”这个过程是AWS CloudTrail中的一条"已记录事件"(logged event)。因为IMS至少每6个小时为每个实例生成唯一的临时访问密钥，所以，当一个EC2实例承担一个IAM角色时，CloudTrail可以记录到该EC2实例的IP地址，并将这些IP地址与CloudTrail中记录的其他API调用相关联。
该检测技术提供了观察能力：能够观察到在"生成临时凭证的实例"之外发生的"临时凭证使用"情况，这可能指明了"SSRF攻击成功地提供了未经授权的访问"(Bengtston, 2018)。

  • 译者注：这种检测技术所关联的数据来源是 AWS CloudTrail记录到的日志 中的信息
    • 1.当一个EC2实例承担一个IAM角色时的IP地址
    • 2.CloudTrail中的其他API调用信息
  • 但是 攻击者能够躲避上述的这种"记录访问凭证的生成、并随时间关联其使用情况"的检测技术
    • 因为能够访问IMS以获取凭证的攻击者，他很可能就在同一个实例中去访问AWS API(Fernandez, 2019)。这样的话访问AWS API的IP就是实例的IP，看不出IP的异常。
  • 并且 这种检测技术需要获取CloudTrail logs中的信息，这在实际环境中的实施、操作都很复杂。
    • 理由1 在利用多个"地区"(regions)实现的弹性的环境中，获取CloudTrail logs中的信息比较困难。(Amazon Web Services,2019)。而CloudTrail Logs 和 AWS Security Token Service(能够创建临时凭证) 都可以在地区内、或者全球范围内 运行。
    • 理由2 像AWS Elastic Kubernetes Service (EKS)之类的"托管式容器化服务"(managed containerized service)产品，它们的趋势是在单个EC2实例上"复用"(multiplex)和"轮换"(rotate)多个容器、多个IP地址，但每个实例都只具有唯一的IAM角色。那么使用该方法去关联可疑的SSRF活动时，将面临重大挑战。
      • 译者注：这种检测方法的精确程度最多只能到实例级别 - 比如根据CloudTrail记录到的日志发现有异常，一个云实例只有唯一的IAM角色，找到了单个云实例A，但上面有多个容器，怎么确定是哪个容器有异常呢？
      • 译者注：这种检测方法具有误报率 - 比如单个云实例B，有容器1和容器2(有各自的IP)，那么容器调用云实例B的AWS API时，则很可能被误报。

4. Recommendations and Implications

建议和启示。

4.1. Recommendations for Practice

实践建议。

4.1.1. Configuration Best Practices

配置最佳实践。

  • Amazon Web Services的管理员应该熟悉并遵循已发布的最佳实践
    • 1.AWS Well-Architected Framework文档。具体来说，管理员应启用VPC Flow Logs和Amazon GuardDuty，以检测SSRF后造成的"环境外部的IMS凭证使用尝试"。
    • 2.存在多种持续监控工具，如工具Cloud Conformity和Prowler，分别用于衡量AWS账户是否符合AWS Well-Architected Framework 和 "AWS基础基准"Center for Internet Security(CIS) Amazon Web Services Foundations Benchmark。
    • 3.安全团队应部署检测工具，以监控这些控制在AWS账户中的实现情况。 特别是对于那些依赖人工管理而不是高度自动化的环境，一些变更可能会带来差异和潜在的安全性配置错误。

除非EC2实例需要访问AWS API，否则管理员不能将IAM角色附加到实例上。必要时，当将"IAM策略语句"(IAM policy statements)attach到用于该目的的角色时，IAM策略的"作者"(authors)应该使用"最小权限方法"(least-privileges methodology)仔细地构造语句。"作者"(authors)还应该利用可以限制"服务访问"(service access)的"IAM策略条件"(IAM policy conditions)，这样一来在该环境之外，由IMS发出的、被攻击者通过SSRF攻击得到的"临时访问凭证"的价值变得很有限。与所有的技术管控一样，知识丰富的团队应该定期审查IAM角色使用和"IAM策略语句"(IAM policy statements)。

作为一条"分层管控"(layered control)，基于主机的管控(如iptables之类)会记录日志并阻止对IMS的访问，除非这些访问来自于已知的那些进程(这些进程具有合法需求, 即具有 读取云实例的元数据、获取临时访问凭据以代表实例访问其他AWS services的合法需求)。
As a layered control, host-based controls like iptables that log and prevent access to the IMS except when originating from processes that have a known, legitimate need to read instance metadata or obtain temporary access credentials to act on behalf of an instance to access other AWS services.

此外，考虑到VPC Traffic Mirroring现在允许已有的入侵检测工具监视、告警可疑的流量，安全工程师应该审查已开发的Zeek或Suricata规则(它们是作为本研究的一部分而开发的规则)，以便将它们包含到Amazon Web Services的IDS部署中，特别是服务于"外部流量"(external traffic,即和外部交互的流量)的那些AWS实例中。

在本研究中评估了的这些检测机制中，只发现了以下2种检测机制，能够在IMS凭据被盗用之前检测到SSRF，也就是在“凭据用于尝试未经授权的云环境访问或修改”之前就可以检测到。

  • 2种检测机制 能够在IMS凭据被盗用之前检测到SSRF
    • 1.the host-based packet filter iptables
    • 2.VPC Traffic Mirroring using Zeek or Suricata

虽然这两种方法都是有效的，但是VPC Traffic Mirroring的优势在于它能够对所有AWS EC2资源提供"检测覆盖"(detective coverage)，包括了虚拟设备(AWS帐户持有人无法直接对其进行交互式登录、或管理员级的配置权限的虚拟设备)。

4.1.2. Effectiveness of Layered Detection Techniques

鉴于启用VPC Flow Logs和GuardDuty的成本相对较低，尽管本研究发现的检测功能仅限于SSRF攻击之后的活动，但强烈建议在AWS云上具有敏感数据的企业，应该启用该服务并密切监控它，至少应该关注"结果类型"(finding type)为UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration的结果。

但是，由于"SSRF攻击后的活动"(post-SSRF exploit activity)发生的时间点 可能在SSRF攻击成功的那个时间点之后很多，因此使用iptables和auditd来监视主机上的活动，是扩展检测能力以识别SSRF攻击尝试的合乎逻辑的下一步。
根据法规要求或行业合规性标准，具有敏感数据的环境通常需要具有"集中式日志记录设施"(centralized logging facilities)，并且通过使用自动化部署iptables来记录、告警来自于(业务)服务器的那些本不需要访问IMS的尝试（检测依赖的数据源是"集中式日志记录设施"），管理员可以在他们能直接控制的那些服务器里尽早地发现SSRF攻击，即管理员获得了额外的、不重复的"可见性"。
使用iptables，管理员除了可以受益于"分层检测"(layered detection)，还可以配置"预防式的管控措施"(preventative control)。

VPC Traffic Mirror和传统的IDS解决方案需要额外的成本和专业知识才能捕获、存储、分析"发现结果"(findings)，并根据"发现结果"采取行动。但是，在云环境中，资源投资不是唯一的因素，因为IDS必须能够接收未加密的"网络数据包"(network packets)，或具有对它们进行解密的能力。
通常，云配置最佳实践要求尽可能对"静态数据"(data at rest)和"传输中的数据"(data in transit)都启用加密。特别是对于利用"云提供商证书颁发机构"(cloud provider certificate authorities)提供的自动证书颁发的环境，这可能会带来问题，因为在使用完全托管的提供商CA解决方案时，私钥通常不可用。为了获得VPC Traffic Mirroring的优势，企业必须考虑"TLS termination"(注:应该是指TLS解密、TLS卸载)在云负载均衡器上的利弊，并在其之后的网络接口上镜像未加密的流量。一些公司可能具有法律或合规性要求，从而限制了他们采用此检测层的能力。面对这样的利弊折衷时，如果他们在其环境中已经部署了“黑盒(black box)”虚拟设备，则应考虑对管控措施进行弥补、补充。

4.1.3. Challenges Regarding the Evolution of the SSRF Techniques

考虑SSRF技术进化带来的挑战。

因为针对AWS EC2 IMS的SSRF请求是指向一个静态IP地址，所以在HTTP请求中检测link-local的IP地址(例如169.254.169.254)、或直接检测path如iam/security-credentials，都很容易输入到IDS或WAF签名(signature,可理解为规则)中。
应该注意到攻击者的对抗，"过滤器绕过技术"(Filter bypass techniques)可以使用"不同进制"来混淆URL，即用十进制、八进制和十六进制混合表示一个IP，如169.0xfe.0251.254 等价于 169.254.169.254。

（译者注：已总结至 notes - SSRF 绕过技巧，IP地址的不同形式 - 进制转换）。

这样一来，防御者的简单的静态文本、或正则表达式规则匹配都无法识别这种"躲避技术"(evasion techniques)，除非管理员使用更复杂的检测引擎来识别这些不常规的 payloads。

  • 最近，使用SSRF攻击规避检测的新方法包括：
    • 1."请求分割"(Request Splitting) - 使用特定的Unicode字符，利用HTTP基于文本的特性，以在请求中使用"协议控制字符"(protocol control indicators)来分割行，以实现能够传递SSRF payload的注入(Kelly, 2018)。Security Bugs in Practice: SSRF via Request Splitting
    • 2."请求夹带"(Request Smuggling) - 使用格式不正确的HTTP headers或利用Web服务器的特定"解析"(parsing)行为，将来自攻击者的请求注入到同一目标的另一个请求的开头 (C. Linhart, 2005)。这种技术首次在2005年的出版物中进行了描述，HTTP的灵活性、宽容性继续为"HTTP解析漏洞"(HTTP parsing vulnerabilities)注入了新的活力，最近，它通过在称为HTTP Desync技术的变体中利用Transfer-Encoding和Content-Encoding的不同行为展示了新的特性以用于进行注入，包括SSRF (Kettle, HTTP Desync Attacks: Request Smuggling Reborn, 2019)。防止HTTP Desync的一种技术可能是使用CDN（例如Cloudflare, Amazon CloudFront, Imperva Cloud WAF）作为"TLS termination"点(注:应该是指TLS解密、TLS卸载)，前提是这个CDN能够提供比它保护的这个"源"(origins)更严格的HTTP解析。

（译者注：已总结至 notes - SSRF 绕过技巧）。

4.1.4. Recommendations for Cloud Providers

通常，SSRF攻击仅对HTTP请求的host和path的控制来成功利用，通常不能注入或操作其他HTTP headers。以Google Cloud的Compute Engine为例，它已经实现了访问管理API所需的header和值为Metadata-Flavor：Google，以减少无法设置该header的那些SSRF攻击的成功(Google，2019)。AWS没有这样的保护，但是如果AWS增加一个“SSRF攻击很难去模仿的”访问EC2 IMS的前提要求，这可能会降低SSRF成功的可能性。

EC2 IMS提供了一个可预测的目标，攻击者都知道的link-local地址。当前，AWS WAF均不包括默认内容检查规则去检测：包含169.254.169.254地址的请求或包含临时访问密钥的响应。
在AWS的情况下，通常对于云提供商而言，如果能默认包括许多覆盖SSRF用例的WAF规则，将提高其客户的"常规检测功能"(general detective capabilities)。

A temporary key obtained by an instance through IMS can issue API calls from outside of AWS infrastructure, in part, because before the advent of AWS PrivateLink in November 2017, AWS API calls within cloud networks were routed externally, over the public internet. (Amazon Web Services, 2017). If cloud providers, including AWS, required caller authentication to access sensitive operations and limited callers’ use of temporary access credentials to the internal, it could reduce the damage potential of an SSRF attack.

此外，虽然按照惯例，临时访问密钥以字符ASIA开头，但是这种密钥并不隐式地局限于"调用方"(caller)。实例通过IMS获得的临时密钥可以从AWS基础设施的"外部"发出API调用，部分原因是在2017年11月AWS PrivateLink出现之前，AWS在云网络内的API调用是通过公网Internet从外部路由的(Amazon Web Services, 2017)。如果云服务提供商(包括AWS)要求"调用方"(caller)身份验证才能访问敏感操作，并限制"调用方"对内部的临时访问凭证的使用，则可以减少SSRF攻击的潜在危害。

4.2. Implications for Future Research

对未来研究的意义。

  • 常见场景
    • 1.把已有业务迁移上云
      • 许多公司将"业务"(workloads)迁移到云。传统上，这被IT专业人员称为“lift and shift”操作，因为IT专业人员使用熟悉的技术将在"本地基础设施"(on-premises infrastructures) 或 "位于同一位置的"(co-located)数据中心的虚拟机 换为 作为EC2实例运行的虚拟机。使用熟悉的那些操作系统并提供"交互式管理访问"(interactive administrative access)。
    • 2.直接利用云上环境 对业务做重新开发
      • 很多公司也会利用新颖的云服务(AWS Elastic Kubernetes Services、AWS Fargate、AWS Lambda等) 直接在云上开发新的"业务"(workloads)，所有这些服务都提供了"计算环境"但抽象了"管理访问"(administrative access)，为云提供商保留了"管控规划"(control plan)。

每一个云服务商的产品都为“有SSRF漏洞的应用程序和代码”提供了机会，并且每一个产品都限制了安全专业人员使用传统工具检测并阻止此类攻击的能力。可能存在“仅限于于云基础设施的检测技术”，同时安全研究人员应继续寻找更多"分层管控"(layered controls)，以保护敏感数据免受云环境中SSRF漏洞的影响。

5. Conclusion

总而言之，云无法幸免于SSRF漏洞带来的危害，并且存在实用的技术来检测、防止对存在SSRF漏洞的应用程序的攻击。 企业如果在云中传输或存储了敏感数据，则应该执行适当的检测管控措施，以识别SSRF攻击尝试，而不是等到知道了某企业发生了数据泄露事件。通过在云上利用这些完善的工具，安全专业人员可以保护云上的"业务"(workloads)，避免针对AWS API、EC2 IMS的SSRF攻击。

云能够成为一个经济、高效、安全的地方，能够进行大规模的快速创新。

References

Amazon Web Services. (2017, September 7). Announcing Network Load Balancer for Elastic Load Balancing. Retrieved from About AWS:
https://aws.amazon.com/about-aws/whats-new/2017/09/announcing-network-load-balancer-for-elastic-load-balancing/

Amazon Web Services. (2017, November). AWS re:Invent 2017: NEW LAUNCH!

Amazon EC2 Bare Metal Instances (CMP330). Retrieved October 7, 2019, from Amazon Web Services channel on YouTube.com: https://www.youtube.com/watch?v=o9_4uGvbvnk

Amazon Web Services. (2017, November 8). Introducing AWS PrivateLink for AWS Services. Retrieved from About AWS: https://aws.amazon.com/about-aws/whats-new/2017/11/introducing-aws-privatelink-for-aws-services/

Amazon Web Services. (2019, September 6). CloudTrail Concepts. Retrieved from AWS CloudTrail User Guide:
https://docs.aws.amazon.com/en_pv/awscloudtrail/latest/userguide/cloudtrail-concepts.html

Amazon Web Services. (2019, October). Elastic Network Interfaces. Retrieved from Amazon Elastic Compute Cloud User Guide for Linux Instances:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html

Amazon Web Services. (2019, September 21). Instance Metadata and User Data.
Retrieved from AWS Documentation for EC2:
https://docs.aws.amazon.com/en_pv/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Amazon Web Services. (2019, October 1). What Is Amazon GuardDuty? Retrieved from Amazon Guard Duty User Guide:
https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html

Art, S. (2016, September 26). Nodejs-SSRF-App. Retrieved October 8, 2019, from GitHub.com: https://github.com/sethsec/Nodejs-SSRF-App/

Bengtston, W. (2018, August 8). Netflix Cloud Security: Detecting Credential Compromise in AWS. Retrieved from The Netflix Tech Blog:
https://medium.com/netflix-techblog/netflix-cloud-security-detecting-credential-compromise-in-aws-9493d6fd373a

C. Linhart, A. K. (2005). HTTP Request Smuggling. Watchfire.
C. Mazzariello, R. B. (2010). Integrating a Network IDS into an Open Source Cloud Computing Environment. 2010 Sixth International Conference on Information Assurance and Security (IAS). IEEE.
ERPScan. (2013, March 27). SSRF DoS Relaying. Retrieved from ERPScan.io Blog:
https://erpscan.io/press-center/blog/ssrf-dos-relaying/

Fernandez, G. (2019, September 3). Metadata abuse in AWS. Retrieved from Technology with a business perspective.:
https://medium.com/@gonfva/metadata-abuse-in-aws-d264274f5764

Google. (2019, October 01). Storing and retrieving instance metadata. Retrieved from Compute Engine Documentation: https://cloud.google.com/compute/docs/storing-retrieving-metadata

Institute of Information Security. (2015, April 16). Server Side Request Forgery (SSRF).
Retrieved from Institute of Information Security Blog:
https://iisecurity.in/blog/server-side-request-forgery-ssrf/

Kelly, R. (2018, September 10). Security Bugs in Practice: SSRF via Request Splitting.
Retrieved from Personal blog:
https://www.rfk.id.au/blog/entry/security-bugs-ssrf-via-request-splitting/

Kettle, J. (2017, July 27). Cracking the lens: targeting HTTP's hidden attack-surface.
Retrieved from PortSwigger Research:
https://portswigger.net/research/cracking-the-lens-targeting-https-hidden-attack-surface

Kettle, J. (2019). HTTP Desync Attacks: Request Smuggling Reborn. PortSwigger Web Security.
Modi, C. &. (2017, March). Virtualization layer security challenges and intrusion detection/prevention systems in cloud computing: a comprehensive review.
Journal of Supercomputing, 73(3), 1192-1234.

OWASP. (2017). Top 10-2017 A1-Injection. Retrieved from The Open Web Application Security Project: https://www.owasp.org/index.php/Top_10-2017_A1-Injection

P. K. Shelke, S. S. (2012, May). Intrusion Detection System for Cloud Computing.
International Journal of Scientific & Technology Research(4).

rain.forest.puppy. (1998, December 25). NT Web Technology Vulnerabilities. Phrack Magazine, 8(54). Retrieved from http://phrack.org/issues/54/8.html

Reese, S. (2018, January 15). Network Traffic Capture in Virtual Enviroments. Retrieved from rsreese.com: https://www.rsreese.com/network-traffic-capture-in-virtual-enviroments/

Sripati, P. (2019, September 26). How To Secure Web Applications With AWS WAF?
Retrieved from AWS Architect Certification Training:
https://www.edureka.co/blog/secure-web-applications-with-aws-waf/


文章来源: http://xz.aliyun.com/t/7198
如有侵权请联系:admin#unsafe.sh