Paperclip中的伺服器端請求偽造（SSRF）漏洞分析

新聞 02-04

可能有的同學已經收到了GitHub在2018年1月22日推送的

CVE-2017-0899漏洞警告了。這個漏洞存在於Paperclip gem之中，是一個高危漏洞，目前Paperclip代碼庫的v5.2.0版本已經成功修復了這個漏洞。在這篇文章中，我們將會跟大家詳細介紹該漏洞的成因，利用方式，漏洞影響，以及可行的修復方案。

本文將不再給大家介紹關於伺服器端請求偽造（SSRF）的內容，如果你之前不了解這個漏洞的話，建議大家自行學習了解。我們這裡給大家提供一些參考資料：

https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF

https://github.com/cujanovic/SSRF-Testing

https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

問題描述

Paperclip代碼庫引入了一種名叫「IO適配器」的概念，這種模式提供了多種方法來將一份「文件」傳遞給Paperclip代碼庫。而本文所要介紹的漏洞將會影響Paperclip的其中兩個IO適配器，這兩個適配器均能接受URL地址作為附帶數據：

lib/paperclip/io_adapters/http_url_proxy_adapter.rb

lib/paperclip/io_adapters/uri_adapter.rb

當程序在使用這些適配器時，Paperclip將會以代理的形式從傳遞過來的URL網站地址中下載指定文件。

如果提供的文件或附帶數據是以『

http://』或『https://』開頭的話，程序將會調用『http_url_proxy_adapter.rb』。需要注意的是，Paperclip的文檔中並沒有記載有這種行為，而代碼庫也並不會執行任何的數據驗證以防止受到伺服器端請求偽造（SSRF）攻擊。

存在漏洞的Rails代碼樣本（使用了Paperclip）

從下面給出的代碼段中可以看到，Rails控制器可以接受一個「附件」請求參數，並將數據傳遞給『GenericAttachment』模塊（該模塊需要實現Paperclip的『has_attached_file』方法）。

漏洞利用PoC

通常情況下，

『attachment』

可以是多種形式的參數，其中可以包含二進位代碼或base64編碼數據等形式的文件內容。為了觸發存在漏洞的適配器，我們需要提交一個URL地址。

URL需要在『attachment』參數中提交，隨後便會被『http_url_proxy_adapter』解析。接下來程序會請求AWS EC2元數據IP, 169.254.169.254（AWS EC2實例外無法訪問），並將數據以附件文件進行存儲。這樣一來，攻擊者將有可能利用應用程序中的其他功能（允許查看文件數據的功能）來恢復這些響應數據，具體需要取決於存在漏洞的應用程序以及支持的數據類型。

當附帶數據（附件）類型為「URI」類型時，程序將會調用『uri_adapter』這個IO適配器（http_url_proxy_adapter繼承了uri_adapter）。下面給出的是存在漏洞的代碼段樣本：

跟『http_url_proxy_adapter』不同的是，『uri_adapter』的行為是可以在Paperclip的文檔【

傳送門

】中找到的。如果用戶輸入的數據是一條未經驗證的URL地址，然後將其設置成一個URI對象，最後以附件數據的形式提交給適配器的話，那麼這將有可能觸發這個SSRF漏洞。

漏洞影響

『http_url_proxy_adapter』是可以直接通過HTTP請求參數直接調用的，因此所有使用了Paperclip並且沒有對用戶輸入進行驗證的應用程序都將有可能受到SSRF攻擊。『uri_adapter』同樣可以被利用來執行SSRF攻擊，但是這個漏洞在利用過程中必須創建要給URI對象，並在附帶數據中進行解析。

伺服器端請求偽造（SSRF）漏洞可以被利用於：