記一次5000美金的文件上傳漏洞挖掘過程

大家好，最有趣的功能之一是文件上傳，文件上傳中的漏洞通常會導致您進入關鍵或高嚴重性，所以讓我們從我在bug bunting時遇到的這個場景開始

假設我們的目標域是 target.com

在尋找我們的目標時，我遇到了 edu.target.com 子域，該程序提供的服務是一個教學平臺，因為有不同類型的用戶，如學生和教師，旨在幫助學生學習與技術相關的主題，如軟件工程機器人等…

開始我們的故事吧 我遇到了上傳功能，試圖上傳一張圖片來分析這個功能是如何工作的

讓我們嘗試上傳 PHP 腳本

我發現服務器沒有響應

經過對應用程序行為的一些分析，我發現如果請求沒有通過驗證，連接將被關閉，服務器將不會響應請求

現在讓我們嘗試繞過對 php 擴展的驗證

讓我們首先通過嘗試上傳隨機擴展來確定應用程序是在進行白名單驗證還是黑名單驗證，如果成功上傳，這意味著應用程序在執行黑名單，如果不是，則意味著應用程序對特定擴展程序進行白名單驗證

我試圖上傳 image.omar

文件已成功上傳，這意味著應用程序正在執行黑名單驗證

所以我嘗試使用 rce.pHp 繞過驗證

上傳成功了

當時，我預計幾天后我的銀行賬戶會收到 5000 美元的獎金

所以讓我們請求我們的 PHP 腳本來執行 phpinfo() 函數

rce.pHp 未執行

所以當時我想到的是，我們似乎能夠繞過黑名單驗證，但開發人員遵循的安全設計阻止了我獲得 RCE

這可以通過多種方式發生，其中之一是將此標志添加到 .htaccess 文件中，這將使服務器不執行圖像上傳目錄上的 PHP 文件

php_flag 引擎關閉

如果您不知道什么是 .htaccess 文件

.htaccess筆記：

.htaccess 文件是分布式配置文件，提供了一種基于每個目錄進行服務器配置更改的方法，我希望開發人員在圖像上傳目錄上使用它來防止 RCE

所以根據這個，我想到了2個場景

重寫配置 && 路徑遍歷：

第一個場景：

注意：假設我的圖像的url是：

https://target-domain.com/edu/sub-dir-1/sub-dir-2/sub-dir-3/our-image-here

1.1

也許開發人員將他們的“.htaccess”文件上傳到sub-dir-1 / 目錄，因此根據這個sub-dir-1 / 目錄和子目錄，包括我上傳我的 php 腳本的目錄不能運行 php 腳本，所以我們可以利用通過使用此配置在sub-dir-1 / sub-dir-2 / sub-dir-3 /.htaccess上上傳不同的“.htaccess”文件來進行此錯誤配置，這將允許我更改 sub-dir-3/ 上的配置允許我執行 php 腳本

允許運行 php 腳本的配置

php_flag 引擎開啟

1.2

好吧，也許開發人員沒有進行這種錯誤配置，并且已經在我的目錄sub-dir-1 / sub-dir-2 / sub-dir-3 /.htaccess 上上傳了 .htaccess 文件，在這種情況下，我將通過上傳文件名重寫 .htaccess 文件.htaccess 與以前的配置，這將允許我執行 php 腳本

但不幸的是，我記得文件名被重寫了，所以如果我們上傳 .htaccess 將被重寫為 /sub-dir-1/sub-dir-2/sub-dir-3/32-random-characters.htaccess 哪個對服務器配置沒有影響

第二種情況：

2.0 

在第二種情況下，我們將測試它以防第一種情況失敗，方法是對文件名參數進行路徑遍歷，以從包含 .htaccess 文件的目錄中退出，該文件阻止我的 php 腳本執行，因此我的文件將被上傳到另一個目錄，不在阻止執行 php 腳本的配置下https://target-domain.com/edu/edu/32-random-chars.pHp

開發人員從文件名中獲取擴展名并將其放入端點擴展名中，因此開發人員可能使用弱正則表達式，將點后面的任何內容放入端點擴展名中，這樣我們就可以通過添加點 (.)然后使用路徑遍歷payload將我們的腳本上傳到另一個目錄

沒用，因為如您所見，開發人員似乎以正確的方式實現正則表達式驗證（以防他們使用它而不使用像 php function pathinfo() 這樣的內置函數）

SQL注入：開發人員在上傳我們的圖片時需要將每張圖片與其用戶連接起來

那么他們怎么能做到呢？

正確，使用數據庫

如您所見，開發人員也將我們的文件名參數保存在某處

所以下一步測試 SQLI 的文件名參數，我為此使用了 BurpSuite來fuzz

但一無所獲

公共漏洞：

但也許上傳功能中的開發人員使用庫來處理可能存在漏洞的上傳圖像

所以我開始測試一些利用 ImageMagick 庫的常見庫的漏洞，比如 ImageTragic

CVE-2016-3714、CVE-2016-3718、CVE-2016-3715、CVE-2016-3716、CVE-2016-3717

你可以在這里找到漏洞利用https://imagetragick.com/

但也沒有工作所以如果我不能得到嚴重的漏洞所以讓我們試著得到高嚴重性的漏洞

存儲型 XSS：

第一個場景：開始通過上傳包含我們的 XSS payload的 SVG 圖像來測試存儲的 XSS

讓我們請求我們的 svg XSS payload

但不幸的是，應用程序響應強制 Content-Type: image/jpeg 所以我們無法以這種方式實現 XSS

第二種情況：在https://edu.target.com/teacher/profile-id

正如我之前告訴你的那樣，服務器端將擴展名放在圖像名稱中

所以似乎文件名參數中的擴展名是注入 XSS payload的最佳位置


XSS.omar" onmouseover=alert(1)

但似乎他們為我們的payload進行 HTML 實體編碼，所以我們無法逃避雙引號

應用級DOS攻擊：

該應用程序在客戶端驗證圖像大小并僅允許上傳小于 1 MB 的圖像

所以我試圖通過上傳一個大圖像來獲取 DOS，所以我只使用了一個大小超過 1 MB 的圖像來測試服務器端的大小是否有驗證，但是連接再次關閉并且服務器沒有響應這意味著對圖像大小進行驗證以防止此類攻擊

信息披露：

但我注意到我的payload沒有改變，這意味著如果我上傳一張圖片，圖片中的所有元數據都不會改變

好吧，是時候射出最后一顆子彈了

所以我上傳了包含 GPS 位置數據的圖像

你可以在這里找到它


https://github.com/ianare/exif-samples/blob/master/jpg/tests/67-0_length_string.jpg

將圖像上傳到 Web 應用程序后，我再次下載它以檢查地理位置數據是否被條帶化

我們可以使用 ExifTool 進行檢查以提取元數據


┌──(omar?kali)-[~/Downloads] └─$ exiftool /Downloads/exif-test.jpg

看起來網絡應用程序沒有從圖像中剝離地理位置數據

提交漏洞后，安全團隊接受其為P2，原因是教育平臺的大多數用戶都是未成年學生，這種信息泄露侵犯了他們的隱私

修復建議：

1-從 ImageMagick 下載最新版本

2-使用 stripImage() 方法從圖像中剝離此元數據

$imageFilePath = '上傳的圖片';
$img = new imagick();
$img->readImage($imageFilePath);
$img->stripImage();
$img->writeImage($imageFilePath);
$img->destroy();
?>
漏洞挖掘 文件上傳 文件目錄 payload 漏洞
撤稿糾錯
本作品采用《CC 協議》，轉載必須注明作者和本文鏈接