漏洞發現過程

之前我一直在學校學習我比較討厭的科目知識，所以最近我決定放松休息一下，我告訴自己必須要在HackerOne平臺中的Vimeo漏洞眾測中有所發現。于是，我就直接想測試一下Vimeo平臺的上傳功能，尤其是通過Google云端硬盤 (Google Drive)上傳到Vimeo的一些功能特性，所以，在我的Google云端硬盤中我選擇了一個特定視頻文件，把它執行到Vimeo的上傳操作，然后用BurpSuite查看它的具體上傳請求信息。

從上圖可見，上傳視頻文件的具體URL鏈接中包含了Google云盤中的相關身份驗證信息，以便讓Vimeo后端服務器能有權限從Google云盤中獲取到相應文件，具體的驗證信息存在于請求頭的header參數中。

所以，看到這里我就想在自己的VPS中架設一個環境，發起上傳視頻文件到Vimeo平臺的操作，看看上傳請求發起后，在Vimeo后端服務器和我的VPS服務器之間會發生什么情況。經測試，從我VPS端上傳到Vimeo后，我VPS中的具體網絡情況如下，Vimeo后端響應回來的消息有些奇怪，尤其是其黃色部分。

其黃色部分的Range,和Content-Range等引起了我的注意，但從其名字中我也大概能猜測到其大致用途。可以這樣假設，大多數時候，因為用戶上傳的視頻文件都是比較大的，所以Vimeo不會用一個上傳請求來實現對整個文件的上傳。但如果用戶需要上傳的視頻文件較小，那么Vimeo就會實現一次請求上傳了。所以這樣來看，Vimeo對用戶需要上傳的大視頻文件都是采取每次請求部份文件，然后多次請求，再實現最終整個文件的組裝完成。整個上傳流程大概的邏輯如下：

也就是說，Vimeo服務器請求用戶需要上傳的視頻文件時，它會判斷如果文件足夠小，那么建立一次連接就可以上傳完成，就不需要后續再建立連接了。基于此，我突然想到，如果我不向Vimeo服務端發送整個上傳文件會如何呢？比如，按以上原理，如果我的VPS告訴Vimeo后端服務器，我需要上傳的文件有500B，那么Vimeo后端服務器就會來取走這500B，但是，如果現在我的VPS告訴Vimeo后端服務器我的文件只有200B，那么之后會發生什么呢？說白了，也就是看看Vimeo后端對大文件上傳的具體操作行為，來試試看。

在此，我用Python編寫了一個腳本來監測Vimeo的這種取大文件的操作，我需要上傳的視頻文件長度共554231B。測試發現，當Vimeo后端服務器來取我的這個554231B大文件時，監測腳本顯示，第一次Vimeo后端只會讀取8228B長度的部份文件內容！

Cool，Vimeo后端在取完8228B長度的部份文件后，會再接著往下取文件的其余部份，由此，一個SSRF場景在我腦海中油然而生。如果我的VPS告訴Vimeo后端服務器一個重定向響應，那Vimeo后端服務器會跟著跳轉嗎？還是會存儲這個重定向響應？還是繼續接著往下讀取文件其余部份？我的構思場景邏輯如下，Vimeo后端在取完第一次的8228B長度的部份文件內容后，會繼續發起對后續文件的讀取，這個時候，我在后續文件內容中插入一個惡意文件內容-http://evil.com/Hello.txt，其文件內容為HelloWorld!zzz，共15個字節。那么Vimeo后端在讀取余下的546094字節文件時，會一并請求我們惡意插入的鏈接http://evil.com/Hello.txt，把HelloWorld!zzz也順利讀取到。

由于一些Web托管服務端對上述攻擊場景作了安全限制，所以我自己動手搭建了一個主機網站進行測試實現，很幸運，我的猜想是對的！按照以上思路在對Vimeo后端的視頻文件上傳中，可以成功實現上述預計的攻擊測試場景。

Notice: 在Vimeo服務中，我們可以下載原始的上傳文件，所以根據這種下載路徑，我們也能輕松構造對響應的一些假冒偽造操作。

漏洞利用

經過測試，我發現Vimeo后端服務相關操作是建立在Google云上的，它后端部署了一個谷歌云實例，而且請求這個實例http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token，可以發現其默認的API訪問token！那么有了這個token之后，我就能把我的公共SSH密鑰添加到實例中，然后再通過我的私鑰去連接它，就能連接到Vimeo在Google云上的實例，按照上述我們預設的步驟成功實現SSRF。（此處可參考另一Vimeo SSRF漏洞）

總結

以上是生活随笔為你收集整理的挖洞经验：通过Vimeo的文件上传功能发现其SSRF漏洞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。