當前位置:
首頁 > 新聞 > 無需 sendmail:巧用 LD_PRELOAD 突破 disable_functions

無需 sendmail:巧用 LD_PRELOAD 突破 disable_functions

*本文原創作者:yangyangwithgnu,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載


摘要:千辛萬苦拿到的 webshell 居然無法執行系統命令,懷疑服務端 disable_functions 禁用了命令執行函數,通過環境變數 LD_PRELOAD 劫持系統函數,卻又發現目標根本沒安裝 sendmail,無法執行命令的 webshell 是無意義的,看我如何突破!


半月前逛「已黑網站列表」時複審一小電商網站,「列表」中並未告知漏洞詳情,簡單瀏覽了下功能,只有註冊、登錄、下單、支付等幾個而已。登錄介面中,找到個 RCE(遠程代碼執行,非遠程命令執行)漏洞:

順勢寫入菜刀馬後連接:


習慣上,getshell 後我會先了解下該系統配置,虛擬終端中執行 cat /proc/meminfo 但執行報錯:


懷疑有 WAF 攔劫了待執行的命令,嘗試了空字元串、路徑擴展、自定義變數平時常用的幾種繞命令執行限制的手法,結果都失敗:


無命令執行功能的 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);

然後,基於

getuidshadow.c 編寫劫持函數的代碼 bypassdisablefunc.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(),必須找個更普適的方法。回到 LDPRELOAD 本身,系統通過它預先載入共享對象,如果能找到一個方式,在載入時就執行代碼,而不用考慮劫持某一系統函數,那我就完全可以不依賴 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,自取。


*本文原創作者:yangyangwithgnu,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 FreeBuf 的精彩文章:

2019年五大網路威脅走勢預測

TAG:FreeBuf |