服务器端请求伪造（SSRF）攻击导致大量科技、工业和媒体组织信息泄露

摘要

服务器端请求伪造（SSRF）是一个Web应用程序漏洞，可将攻击者的请求重定向到防火墙后的内部网络或本地主机。由于使用了元数据API，因此SSRF对云服务构成了特殊的威胁，这些元数据API允许应用程序访问底层云基础架构的信息，例如配置、日志和凭据。原本只能在本地访问这些元数据API，但SSRF漏洞使得这些内容可以从网络进行访问。另外，此类漏洞也绕过了容器的沙箱保护。可以说，SSRF无疑为内部网络侦查、横向移动甚至是远程代码执行打开了一扇新的大门。

默认情况下，容器中的应用程序可以直接访问其主机上的元数据API，从而实现一种特殊的容器逃逸方式。为了深入探究这一问题的严重性，Unit 42的研究人员仔细分析了Jira SSRF漏洞（CVE-2019-8451），并研究了该漏洞对于6个公有云服务提供商（CSP）的影响。这一漏洞也是导致2019年7月Capital One数据泄露的罪魁祸首。

我们的漏洞扫描器发现：

1. 超过7000个公有云中的Jira实例暴露在互联网上；

2. 在7000多个Jira实例中，有45%（3152个）未安装CVE-2019-8451的补丁或更新，容易受到此CVE的攻击；

3. 在3152台易受攻击的主机中，有56%（1779台）泄露了云基础架构的元数据。

根据NVD给出的信息，这个CVE漏洞最初是在v7.6中引入的，但是我们发现这个CVE实际上最早影响v4.3的版本（发布于2011年3月），而并非v7.6（2017年11月）。泄露的元数据可以是内部网络配置，也可以是源代码或凭据。受到这一漏洞影响的组织包括科技类、工业类和媒体类的企业。

服务器端请求伪造

服务器端请求伪造（SSRF）是一个Web应用程序漏洞，它会将恶意请求重定向到服务器的受限资源。攻击者通过欺骗易受攻击的应用程序，将恶意请求转发到任意域名，包括内部网络和本地主机，从而规避了防火墙。SSRF请求的最常见类型是HTTP，但其他有效的统一资源标识符（URI）方案，例如主机文件系统（file:////）、字典服务（dict://）、Redis服务（redis://）都可以实现。只要应用程序支持URI方案，攻击者就可以访问与易受攻击服务器具有信任关系的任何目标。攻击者可以轻松到达目标，而无需进行任何其他身份验证。

SSRF的根本原因在于，Web应用程序需要从另一个域名检索资源来满足请求，但是输入URL未被正确清理，并允许攻击者操纵自定义目标地址。在CVE-2019-8451中，容易受到攻击的API /plugins/servlet/gadgets/makeRequest?url=endpoint从服务提供商终端获取数据，以填充到小工具中。服务器确实验证了查询字符串，并且仅允许白名单内的终端。但是，由于JiraWhiteList类中的逻辑错误，参数字符串中的@符号可以绕过白名单验证。因此，发送到http://vulnerablehost.com/plugins/servlet/gadgets/makeRequest?url=http://vulnerablehost.com@http://targethost.com的请求将会重定向到targethost.com。因此，这个逻辑漏洞使攻击者可以将HTTP请求发送到易受攻击的服务器可以访问的任何目标。

公有云中的元数据API

几乎所有的云服务提供商都会提供一个元数据API，这个API允许VM实例中的进程掌握特定于该VM的信息。元数据服务为应用程序提供了一种简单的方法，可以了解其运行的环境，并相应地调整配置。元数据API提供了诸如实例ID、映像ID、私有IP、公有IP和网络配置之类的信息。有时，还会在元数据服务中放置VM启动和关闭脚本，以便可以使用不同的设置创建基于同一映像的多个VM实例。一些CSP还允许应用程序将动态数据写入元数据API，并将其用作临时数据存储。

元数据API只能从VM实例内部访问，不对主机外部公开。尽管可以将任何私有IP分配给这个API，但大多数公有云服务提供商都使用不可路由的（本地链接）IP地址169.254.169.254。举例来说，一个进程可以在AWS EC2实例中发出curl命令，以检索与该角色相关联的安全凭证，如下图所示：

curl
http://169.254.169[.]254/latest/meta-data/iam/security-credentia
ls/role-name

默认情况下，任何用户或进程都具有对元数据API的完全访问权限。一个有趣的发现是，即使是容器中的应用程序（例如：Docker、Kubernetes、ECS、EKS），也可以访问主机的元数据API。从容器访问主机元数据的这种场景既方便又危险。一方面，容器中的应用程序可以查询主机元数据API，并使用附加的凭据来访问其他云服务，例如S3和RDS。另一方面，主机元数据APAI创建了一个容器“逃逸路径”，允许容器化的应用程序直接访问敏感的主机元数据。如果容器遭到破坏，攻击者可以利用这个路径来攻击云中的其他主机或其他服务。这样一来，这一功能的潜在风险要高于收益，因为主机可以通过其他方式与容器共享数据，而不会暴露元数据。

从元数据API检索凭证：

尽管元数据服务永远不会暴露到互联网上，但是它可能会被一些脆弱的、面向互联网的应用程序间接暴露。SSRF漏洞实质上是将元数据服务暴露给整个互联网。攻击者可能使用泄漏的元数据进一步攻击VPC中的其他主机，甚至接管整个云基础架构。其中，我们列举了一些敏感的元数据，以及这些元数据可能产生的潜在影响。

1. IAM数据：可以用于访问其他云服务，例如S3 Bucket或容器注册表。如果将管理员身份附加到实例，或者为该身份提供了过多的特权，那么攻击者还有可能会成功攻击整个云基础架构。

2. 用户数据：用户指定的数据可以存储在元数据中。VM启动和关闭脚本通常也放置在用户数据中。这些数据可以泄露VM能够访问的应用程序配置、VM配置以及其他云资源。在脚本中，也经常能找到硬编码的一些凭证。

3. VM映像ID：如果该映像是公开的，那么恶意攻击者就可以检查VM并设计渗透策略。

4. 网络配置：这部分内容可能会泄露网络信息，例如VM的私有/公用IP、MAC地址、本地主机名、子网以及VPC。

为了防止滥用元数据API，一些云服务提供商在元数据HTTP请求中需要检查特殊的标头。例如，Azure VM会检查是否存在“Metadata: True”标头，而Google Compute Engine检查“Metadata-Flavor: Google”标头。如果不包含特定标头，HTTP请求将会被拒绝。标头的强制要求有效阻止了SSRF访问元数据API的漏洞，因为攻击者无法控制重定向请求中的标头。下面我们列举了6个云服务提供商的元数据API。

来自不同云服务提供商的元数据API服务：

* 其中，GCP开始在元数据API V1中强制执行标头要求。

公有云中存在的CVE-2019-8451漏洞

为了了解SSRF对公有云的真正影响，我们需要找到一个存在SSRF漏洞并且广泛部署在公有云中的应用程序。Jira引起了我们的注意，因为它存在2019年8月发现的SSRF漏洞CVE-2019-8451，并且在无需身份验证的情况下就可以利用这个漏洞。尽管该漏洞对应的补丁立即被发布，但与业务运营紧密相关的Jira软件很少会立即得到更新。系统管理员往往倾向于延迟应用补丁的时间，以避免业务运营的中断。根据Shodan的搜索结果显示，目前有大约25000个Jira实例暴露在互联网上。然后，我们选取了Jira部署数量最多的6个云服务提供商进行了研究。我们研究的目的是确定公有云中易受CVE-2019-8451漏洞攻击的Jira实例数量、这些Jira实例的可利用情况以及泄露元数据的主机数量。我们针对6个公有云服务提供商找到了7002个Jira实例，下图展示了Jira版本的分布情况。

公有云中暴露的Jira版本统计：

考虑到CVE-2019-8451首先在v8.4中进行了修复，上图中有80%的Jira实例版本都低于8.4%，如果没有及时进行修复，则这些实例都容易受到攻击。我们的扫描结果显示，在7002个Jira实例中，有3152个（占比45%）实例尚未打补丁，并且确认为是易受攻击的。下图展示了尚未修复漏洞的10个主要Jira版本。在3152个易受攻击的Jira实例中，其中有1779个（占比56%）实例泄露了主机的元数据。下面的表格中总结了所有云服务提供商的统计信息。DigitalOcean客户的元数据泄漏率最高，达到了93%，其次是Google Cloud客户（80%）、阿里云客户（71%）、AWS客户（68%）和Hetzner客户（21%）。唯一的元数据泄漏数量为0的云服务提供商是Microsoft Azure，因为它对元数据API标头的严格要求有效阻止了所有SSRF请求。尽管GCP在最新的元数据API（v1）中强制执行标头要求，但是如果未明确禁用旧版本API终端（v0.1和v1beta1），攻击者就仍然可以使用旧版本API访问到大多数元数据。

容易受到CVE-2019-8451攻击的10个主要Jira版本：

公有云中易受攻击的主机数量和元数据泄漏数量：

从上图中，我们还能得到一个额外发现，排名最高的10个Jira版本中，有2个（v7.3.6和v6.3.6）不在Jira发布的易受攻击版本范围之中。根据Jira和NVD发布的漏洞说明，CVE-2019-8451最初是在v7.6中引入，并且在v8.4中修复。但是，我们的扫描结果表明，这一范围之外的许多版本也容易受到攻击。为了找出受漏洞影响的真正版本范围，我们检查了导致SSRF的漏洞类JiraWhiteList。我们发现，从v4.3开始，这个只有一种方法的简单Java类就已经存在于Jira中。对旧版本Jira软件的进一步研究表明，该漏洞确实影响了早在8年前（2011年3月）发布的v4.3版本。

修复建议和最佳实践

导致SSRF漏洞的根本原因，是缺少适当的输入清理功能。为了从根本上解决问题，开发人员应该在将用户输入传递给应用程序逻辑之前，严格验证用户输入的格式和模式。对于仅负责安装和管理Web应用程序的系统管理员，我们提出了一些建议的预防性措施，可以缓解SSRF漏洞产生的潜在影响，具体包括：

1. 域名白名单：大多数应用程序仅需要于少数域名进行通信，例如数据库和API网关。设置一个允许应用程序进行通信的域名白名单可能会大大减少攻击者能够攻击的服务数量。

2. 零信任网络：一个应用程序永远不应该仅仅因为它们位于同一个内部网络中，就信任另一个应用程序。如果目标服务需要身份验证，那么SSRF漏洞攻击也就无法实现了。认证和授权应该实现在每个应用程序上。

3. Web应用程序防火墙（WAF）：WAF可以检测HTTP请求中的异常模式或恶意内容。但是，WAF通常适用于为已知漏洞或具有明显模式的攻击（例如：SQL注入、XSS）而创建的规则。0-day漏洞可能仍然会绕过WAF。

4. 修复程序和更新：及时修复和更新应用程序，是防范任何漏洞的最简单、最有效方法。但是，这种方式仅限于供应商提供了修复的支持。如果超出支持生命周期的应用程序，可能将不会收到更新。

如上文所述，元数据API也可以由云服务提供商进行充分的保护。但是，如果云服务提供商暂时没有采取保护措施，云用户也可以采取如下预防措施以减少元数据泄漏的风险：

1. 启用云服务提供商的数据API保护：一些云服务提供商提供可以配置的选项，可以保护元数据API。GCP用户可以禁用旧版本的元数据API并强制执行HTTP标头要求。DigitalOcean用户可以在cloud-config脚本中禁用元数据API服务。

2. 阻止元数据IP：可以在VM内部创建防火墙规则，以完全阻止元数据API的IP。还可以创建更为精细的防火墙规则，以仅允许特定的应用程序或用户访问元数据API。

3. 元数据代理：元数据代理和aws-metadata-proxy等开源工具在本机元数据API上方创建一个新层，并为需要访问元数据的应用程序提供粒度控制。

4. 最小特权IAM：IAM角色被附加到VM，以允许VM上的应用程序访问其他云服务。将IAM特权限制为仅应用程序所需的服务是至关重要的。最小特权的做法可以最大限度地减少凭证暴露的风险。

总结

就目前而言，SSRF自身可能并不是一个严重的漏洞，但是当它与元数据API和云基础架构中的错误配置结合使用时，SSRF就为许多其他攻击媒介打开了大门。诸如凭证和网络体系架构之类的敏感元数据可能会泄露，并且可能暴露诸如数据库和存储之类的内部服务。在最坏的情况下，整个云基础架构可能会受到威胁。这项研究仅以Jira漏洞CVE-2019-8451为例，说明了SSRF对云基础架构的影响，但还有数百种其他已知SSRF漏洞的应用程序都可以在云中利用。我们发现云服务提供商已经开始着手保护元数据API，但要完全实施可能还需要一些时间。因此，我们建议系统管理员或云服务用户使用VM系列和Prisma Cloud进行防护，VM系列通过应用程序流量分析来保护云工作负载，Prisma Cloud在公有或私有云环境中提供全栈监控。