服务端请求仿冒（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%（315两个）未安裝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）计划方案，比如服务器系统文件（词典服务项目（服务项目（都能够完成。只需应用程序适用URI计划方案，攻击者就可以访问与易受攻击 *** 服务器具备信赖关联的一切总体目标。攻击者能够轻轻松松抵达总体目标，而不用开展一切别的身份认证。

SSRF的直接原因取决于，Web应用程序必须从另一个网站域名查找資源来考虑请求，可是键入URL未被恰当清除，并容许攻击者控制自定总体目标详细地址。在CVE-2019-8451中，非常容易遭受进攻的API /plugins/servlet/gadgets/makeRequest?url=endpoint从服务供应商终端设备读取数据，以填充到实用工具中。 *** 服务器的确认证了查看字符串数组，而且仅容许授权管理内的终端设备。可是，因为JiraWhiteList类中的逻辑错误，主要参数字符串数组中的@标记能够绕开授权管理认证。因而，发送至的请求可能跳转到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

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地址、当地IP地址、子网及其VPC。

为了更好地避免 乱用元数据API，一些云服务供应商在元数据HTTP请求中必须查验独特的标题文字。比如，Azure VM会查验是不是存有“Metadata: True”标题文字，而Google Compute Engine查验“Metadata-Flavor: Google”标题文字。假如不包含特殊标题文字，HTTP请求可能被拒绝。标题文字的强制性规定合理阻拦了SSRF访问元数据API的漏洞，由于攻击者控制不了跳转请求中的标题文字。下边大家例举了6个云服务供应商的元数据API。