今天做靶場時遇到了一個情形：拿到了webshell，卻不能執行任何命令，如圖

后來百度知道了disable_functions功能，這類服務器針對命令執行函式做了防范措施

一般繞過思路是利用漏掉的函式，今天這里介紹的是LD_PRELOAD

0X01 LD_PRELOAD認識

LD_PRELOAD是Linux系統的一個環境變數，可以影響程式的運行時的鏈接，它允許你定義在程式運行前優先加載的元件，通過這個環境變數，我們可以在主程式和其元件的中間加載別的元件，甚至覆寫正常的函式庫，這里在網上找了兩張形象的圖片來理解

LD_PRELOAD這個環境變數指定路徑的檔案，會在其他檔案被呼叫前，最先被呼叫

替換前運作流程：

替換后運作流程：

0X02 繞過條件

了解了LD_PRELOAD，就有了繞過思路，通過加載我們寫的元件，執行相關操作

前提條件：

能夠上傳自己的.so檔案    

能夠控制環境變數的值（設定LD_PRELOAD變數），比如putenv，mail函式  

存在可以控制PHP啟動外部程式的函式并能執行（因為新行程啟動將加載LD_PRELOAD中的.so檔案），比如mail()、imap_mail()、mb_send_mail()和error_log()等

0X03  在這里我拷貝了一份文章，僅供學習使用，是工具開發者寫的，真的思路太清晰太新奇了，文章鏈接：https://www.freebuf.com/articles/web/192052.html

無命令執行功能的 webshell 是無意義的，得突破！

通常來說，導致 webshell 不能執行命令的原因大概有三類：一是 php.ini 中用 disable_functions 指示器禁用了 system()、exec() 等等這類命令執行的相關函式；二是 web 行程運行在 rbash 這類受限 shell 環境中；三是 WAF 攔劫，若是一則無法執行任何命令，若是二、三則可以執行少量命令，從當前現象來看，很可能由 disable_functions 所致，為驗證，我利用前面的 RCE 漏洞執行 phpinfo()，確認的確如此：

有四種繞過 disable_functions 的手法：第一種，攻擊后端組件，尋找存在命令注入的、web 應用常用的后端組件，如，ImageMagick 的魔圖漏洞、bash 的破殼漏洞；第二種，尋找未禁用的漏網函式，常見的執行命令的函式有 system()、exec()、shell_exec()、passthru()，偏僻的 popen()、proc_open()、pcntl_exec()，逐一嘗試，或許有漏網之魚；第三種，mod_cgi 模式，嘗試修改 .htaccess，調整請求訪問路由，繞過 php.ini 中的任何限制；第四種，利用環境變數 LD_PRELOAD 劫持系統函式，讓外部程式加載惡意 *.so，達到執行系統命令的效果，

嘗試第一種時，我用 phpinfo() 查看 ImageMagick 版本為 v6.9.4-10：

用 searchsploit（exploit-db.com 的本地版）搜索存在命令注入的版本為 v6.9.3-9 或 v7.0.1-0：

顯然，當前 ImageMagick 無法利用；嘗試第二種時，常見的、不常見的、罕見的（如 dl()），所有可啟動行程的函式均被禁用；嘗試第三種時，發現并未啟用 mod_cgi 模式，所有希望，寄托在 LD_PRELOAD，

設想這樣一種思路：利用漏洞控制 web 啟動新行程 a.bin（即便行程名無法讓我隨意指定），a.bin 內部呼叫系統函式 b()，b() 位于系統共享物件 c.so 中，所以系統為該行程加載共 c.so，我想法在 c.so 前優先加載可控的 c_evil.so，c_evil.so 內含與 b() 同名的惡意函式，由于 c_evil.so 優先級較高，所以，a.bin 將呼叫到 c_evil.so 內 b() 而非系統的 c.so 內 b()，同時，c_evil.so 可控，達到執行惡意代碼的目的，基于這一思路，將突破 disable_functions 限制執行作業系統命令這一目標，大致分解成幾步在本地推演：查看行程呼叫系統函式明細、作業系統環境下劫持系統函式注入代碼、找尋內部啟動新行程的 PHP 函式、PHP 環境下劫持系統函式注入代碼，

查看行程呼叫系統函式明細，linux 創建新行程的程序較為復雜，我關心行程加載了哪些共享物件、可能呼叫哪些 API、實際呼叫了哪些 API，比如，運行 /usr/bin/id，通過 ldd 可查看系統為其加載的共享物件：

由于可執行檔案 /usr/bin/id 內含符號表，所以，運行 nm -D /usr/bin/id 2>&1 或 readelf -Ws /usr/bin/id 可查看該程式可能呼叫的系統 API 明細：

由于程式運行時會根據命令列選項、運行環境作出不同反應，導致真正運行時呼叫的 API 可能只是 readefl 查看的子集，你可以運行 strace -f /usr/bin/id 2>&1 跟蹤實際 API 呼叫情況，比如，實際呼叫 open() 的入參、回傳值一目了然：

作業系統環境下劫持系統函式注入代碼，linux 的環境變數 LD_PRELOAD 是一種類似 win32 API hook 的更優雅的實作，適用于打熱補丁、讀取行程空間資料、禁止程式呼叫指定 API、除錯程式等等場景，甚至可以在不更改原始可執行檔案前提下植入后門（管理員常用的 /bin/ps），由于被劫持的系統函式得由我們重新實作一次，函式原型必須一致，為減少復雜性，我會選擇劫持那些無引數且常用的系統函式，getuid() 就適合，以此為例，完整劫持程序步驟大致如下：首先，用 man 2 getuid 查看函式原型：

然后，撰寫同原型的 getuid() 函式，保存至 getuid_shadow.c，原始碼為：

執行 gcc -shared -fPIC getuid_shadow.c -o getuid_shadow.so 將其編譯為共享物件：

最后，借助環境變數 LD_PRELOAD 劫持系統函式 getuid()，獲取控制權，執行 LD_PRELOAD=/root/getuid_shadow.so /usr/bin/id，注入代碼成功執行：

注意，LD_PRELOAD 是行程獨占環境變數，類似于命令配接器，它與待執行命令間必須為空白字符，而非命令分隔符（;、&&、||），

找尋內部啟動新行程的 PHP 函式，雖然 LD_PRELOAD 為我提供了劫持系統函式的能力，但前提是我得控制 php 啟動外部程式才行（只要有行程啟動行為即可，無所謂是誰），常見的 system() 啟動程式方式顯然不行，否則就不存在突破 disable_functions 一事了，PHP 腳本中除了呼叫 system()、exec()、shell_exec() 等等一堆 php 函式外，還有哪種可能啟動外部程式呢？php 解釋器自身！比如，php 函式 goForward() 實作“前進”的功能，php 函式 goForward() 又由組成 php 解釋器的 C 語言模塊之一的 move.c 實作，C 模塊 move.c 內部又通過呼叫外部程式 go.bin 實作，那么，我的 php 腳本中呼叫了函式 goForward()，勢必啟動外部程式 go.bin，現在，我需要找到類似 goForward() 的真實存在的 PHP 函式，印象中，處理圖片、請求網頁、發送郵件等三類場景中可能存在我想要的函式，我得逐一驗證，處理圖片，通常呼叫 PHP 封裝的 ImageMagick 庫，新建 image.php，呼叫 Imagick()：

運行 strace -f php image.php 2>&1 | grep -A2 -B2 execve 查看 Imagick() 是否啟動新行程：

第一個 execve 是啟動 PHP 解釋器而已，必須找到第二個 execve，沒有則說明并未啟動新行程；請求網頁，新建 http.php，呼叫 curl_init()：

運行 strace -f php http.php 2>&1 | grep -A2 -B2 execve 查看 curl_init() 是否啟動新行程：

仍然不是我要的；發送郵件，新建 mail.php，呼叫 mail()：

運行 strace -f php mail.php 2>&1 | grep -A2 -B2 execve 查看 mail() 是否啟動新行程：

bingo！mail() 內部啟動了 /usr/sbin/sendmail、/usr/sbin/postdrop 兩個新行程，它就是我一直苦尋的函式（用相同的測驗方式，還找到一個 imap_mail()），

PHP 環境下劫持系統函式注入代碼，mail.php 內增加設定 LD_PRELOAD 的代碼：

然后將 mail.php 以及內含 mail() 函式的共享物件 getuid_shadow.so 放入 web 目錄 /var/www/：

執行 mail.php 之后，找到 getuid_shadow.so 中 mail() 創建的檔案 /tmp/evil，成功在 PHP 環境下不借助任何 PHP 命令執行函式執行命令：

有了前面的分析，看我如何在目標站點繞過 disable_functions 執行系統命令，

首先，基于前面的 mail.php 寫了個小馬 bypass_disablefunc.php：

bypass_disablefunc.php 提供三個 GET 引數，一是 cmd 引數，待執行的系統命令（如 pwd）；二是 outpath 引數，保存命令執行輸出結果的檔案路徑（如 /tmp/xx），便于在頁面上顯示，另外關于該引數，你應注意 web 是否有讀寫權限、web 是否可跨目錄訪問、檔案將被覆寫和洗掉等幾點；三是 sopath 引數，指定劫持系統函式的共享物件的絕對路徑（如 /var/www/bypass_disablefunc_x64.so），另外關于該引數，你應注意 web 是否可跨目錄訪問到它，此外，bypass_disablefunc.php 拼接命令和輸出路徑成為完整的命令列，所以你不用在 cmd 引數中重定向了：

$evil_cmdline = $cmd . " > " . $out_path . " 2>&1";

同時，通過環境變數 EVIL_CMDLINE 向 bypass_disablefunc_x64.so 傳遞具體執行的命令列資訊：
putenv("EVIL_CMDLINE=" . $evil_cmdline);

然后，基于 getuid_shadow.c 撰寫劫持函式的代碼 bypass_disablefunc.c，回想下，先前我之所以劫持 getuid()，是因為 sendmail 程式會呼叫該函式，在真實環境中，存在兩方面問題：一是，某些環境中，web 禁止啟用 senmail、甚至系統上根本未安裝 sendmail，也就談不上劫持 getuid()，通常的 www-data 權限又不可能去更改 php.ini 配置、去安裝 sendmail 軟體；二是，即便目標可以啟用 sendmail，由于未將主機名（hostname 輸出）添加進 hosts 中，導致每次運行 sendmail 都要耗時半分鐘等待域名決議超時回傳，www-data 也無法將主機名加入 hosts（如，127.0.0.1    lamp、lamp.、lamp.com），基于這兩個原因，我不得不放棄劫持函式 getuid()，必須找個更普適的方法，回到 LD_PRELOAD 本身，系統通過它預先加載共享物件，如果能找到一個方式，在加載時就執行代碼，而不用考慮劫持某一系統函式，那我就完全可以不依賴 sendmail 了，這種場景與 C++ 的建構式簡直神似！幾經搜索后了解到，GCC 有個 C 語言擴展修飾符 __attribute__((constructor))，可以讓由它修飾的函式在 main() 之前執行，若它出現在共享物件中時，那么一旦共享物件被系統加載，立即將執行 __attribute__((constructor)) 修飾的函式，強調下，這一細節非常重要，很多朋友用 LD_PRELOAD 手法突破 disable_functions 無法做到百分百成功，正因為這個原因，我們不要局限于僅劫持某一函式，而應考慮劫持共享物件，bypass_disablefunc.c 原始碼如下

從環境變數 EVIL_CMDLINE 中接收 bypass_disablefunc.php 傳遞過來的待執行的命令列，

接著，用命令 gcc -shared -fPIC bypass_disablefunc.c -o bypass_disablefunc_x64.so 將 bypass_disablefunc.c 編譯為共享物件 bypass_disablefunc_x64.so：

你要根據目標架構編譯成不同版本，在 x64 的環境中編譯，若不帶編譯選項則默認為 x64，若要編譯成 x86 架構需要加上 -m32 選項，

最后，用菜刀將 bypass_disablefunc.php 和 bypass_disablefunc_x64.so 傳到目標：

指定好命令輸出路徑、共享物件路徑后，在 bypass_disablefunc.php 上再次執行先前失敗的命令 cat /proc/meminfo

：

啊哈！很酷對不對，

好了，巧用 LD_PRELOAD 突破 disable_functions 的手法就是這樣子，唯一條件，PHP 支持putenv()、mail() 即可，甚至無需安裝 sendmail，那么，現在的情況是，我知道你很忙，沒時間看前面的技術細節，要的只是開箱即用的工具，行，bypass_disablefunc.php、bypass_disablefunc.c、bypass_disablefunc_x64.so 托管在 https://github.com/yangyangwithgnu/bypass_disablefunc_via_LD_PRELOAD，自取，

標籤：其他

上一篇：簡單模擬三層內網滲透

下一篇：leetcode菜雞斗智斗勇系列（1）---把一個鏈表中的二進制數字轉換為一個整型數（int）