和往常一样，我今天早早到了公司， 也就提前了两个小时吧 （现在你们知道我为什么有时间写文章了吧）
想着既然离上班还早，于是我逛起了推特，看看今天是哪位幸运的大佬被我膜拜，不一会，我就发现很多人都转了一条推特，这条推特是关于CVE-2020-13379这个漏洞的
看到这么多人都在转，那一定是很牛逼的漏洞，于是我点了进去...
这是一个Grafana的未授权ssrf漏洞，涉及3.0.1-7.0.1版本。下面是漏洞详情
CVE-2020-13379
漏洞的入口点是/avatar/:hash接口，在Grafana api.go 文件中我们可以看到如下的路由
r.Get("/avatar/:hash", avatarCacheServer.Handler)
这个路由会获取到接口/avatar/:hash中的hash值，并把它路由到secure.grafana.com,代码实现大体如下：
const (
gravatarSource = "https://secure.gravatar.com/avatar/"
)
...
case err = <-thunder.GoFetch(gravatarSource+this.hash+"?"+this.reqParams, this):
代码中的gravatarSource的值就是secure.grafana.com,this.hash的值就是经过URL解码过后的/avatar/:hash中的:hash的值，因为:hash的值可控，所以我们可以注入参数到url中。
而这个secure.gravartar.com有一个特点，如下：
secure.gravartar.com这个网站是国外的一个著名的提供头像等图片的站点，而它还实现了从其它主机加载图片的功能，只要用参数d=指定你要加载的图片地址就行，例如你要加载的图片地址是http://axin.com/1.png,你就可以这么写https://www.gravatar.com/avatar/test?d=http%3a%2f%2faxin.com%2f1.png,注意，冒号斜杠等特殊等字符需要url编码
而这个功能是怎么实现的呢？
其实就是一个重定向，当我们请求https://www.gravatar.com/avatar/test?d=http%3a%2f%2faxin.com%2f1.png
会被重定向到
http://i0.wp.com/axin.com/1.png
我们可以用curl做个试验，如下
那你可能会疑惑了，我指定的地址不是http://axin.com/1.png吗，怎么给我跳到了i0.wp.com这个主机上呀
而且，这个主机怎么拿到我指定地址的图片的？
没错，你可能已经猜到了，这里又有一次重定向
当我们请求i0.wp.com/imageDomain/pathofImage时，会被重定向到imageDoamin/pathofImage这个地址，但是这里的imageDoamin可不是随便什么域名都可以，而是要*.bp.blogspot.com子域下的域名
这是一个白名单的配置，而我们需要做的就是绕过这个白名单，只要绕过了这个白名单，我们就大功告成了
我又探索了一番，发现了如下绕过手法
http://i0.wp.com/axin.com%3f/1.bp.blogspot.com/
通过如上技巧就可以轻松绕过白名单限制，把请求重定向到axin.com,至此就完成了整个ssrf，由于我在复现的过程中发现i0.wp.com已经修复了这种绕过方式，所以我贴一张原作者的图
从图中可以看到，确实是重定向到了我们指定的域名，但是修复过后，发送上述请求不会再重定向，而是返回400
这真是一个悲伤的故事
最后的payload类似这样： https://grafanaHost/avatar/test%3fd%3daxin.com%25253f%253b%252fbp.blogspot.com
再来梳理一下整个流程:
Grafana把字符串test%3fd%3daxin.com%25253f%253b%252fbp.blogspot.com当做:hash,此时，目标服务器会请求到
https://secure.gravatar.com/avatar/anything?d=axin.com%253f%3b/1.bp.blogspot.com/
然后，因为我们使用了d=参数，请求又被重定向到了
http://i0.wp.com/google.com%3f%;/1.bp.blogspot.com/
最后，由于白名单的正则缺陷，我们重定向到我们指定的主机地址axin.com
http://axin.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)
}
最后，漏洞作者给出了他自己的一个payload:
https://grafanaHost/avatar/test%3fd%3dredirect.rhynorater.com%25253f%253b%252fbp.blogspot.com%252fYOURHOSTHERE
但是，由于i0.wp.com修复了正则缺陷，这个payload好像也就失效了...
其他
原文地址： https://rhynorater.github.io/CVE-2020-13379-Write-Up
原文很精彩，我只挑了最最最最基础的漏洞原理讲了讲，漏洞作者可是用这个漏洞横扫了bugbounty呢！
ok，文章写完了，我也该下班了！我们周末见~
