摘要
服务器端请求伪造（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-credentials/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中强制执行标头要求。
