1.環境：
php5.5.38+apache+seacms v6.45
seacms目錄結構：
│─admin //后台管理目錄 │ │─coplugins //已停用目錄 │ │─ebak //帝國備份王數據備份 │ │─editor //編輯器 │ │─img //后台靜態文件 │ │─js //后台js文件 │ │─templets //后台模板文件 │─article //文章內容頁 │─articlelist //文章列表頁 │─comment //評論 │ │─api //評論接口文件 │ │─images //評論靜態文件 │ │─js //評論js文件 │─data //配置數據及緩存文件 │ │─admin //后台配置保存 │ │─cache //緩存 │ │─mark //水印 │ │─sessions //sessions文件 │─detail //視頻內容頁 │─include //核心文件 │ │─crons //定時任務配置 │ │─data //靜態文件 │ │─inc //擴展文件 │ │─webscan //360安全監測模塊 │─install //安裝模塊 │ │─images //安裝模塊靜態文件 │ │─templates //安裝模塊模板 │─js //js文件 │ │─ads //默認廣告目錄 │ │─player //播放器目錄 │─list //視頻列表頁 │─news //文章首頁 │─pic //靜態文件 │ │─faces //表情圖像 │ │─member //會員模塊界面 │ │─slide //舊版Flash幻燈片 │ │─zt //專題靜態文件 │─templets //模板目錄 │─topic //專題內容頁 │─topiclist //專題列表頁 │─uploads //上傳文件目錄 │─video //視頻播放頁 │─weixin //微信接口目錄 └─index.php //首頁文件
2.利用代碼
poc1
http://seacms.test/search.php
POST:
searchtype=5&order=}{end if} {if:1)phpinfo();if(1}{end if}
poc2：
POST: searchtype=5&order=}{end if}{if:1)$_POST[func]($_POST[cmd]);//}{end if}&func=system&cmd=whoami
searchtype=5&order=}{end if}{if:1)$_POST[func]($_POST[cmd]);if(1}{end if}&func=system&cmd=whoami
3.執行效果
4.漏洞分析
漏洞產生鏈如上圖所示，在search.php的212行下斷點，因為在此處產生了parseIf()函數的調用，並且最終的命令執行是發生在此函數中，用payload打一次，將停在此處，進入此函數進行分析
如上圖所示，其中buildregx函數是構建php的原生正則表達式
接下來使用$labelRule規則進行preg_match_all匹配出了所有滿足的結果，並放在$iar中，我猜測這里class頂一個兩個css樣式，通過if條件來調整按鈕樣式的
通過這4行代碼將$iar中的每條記錄分為條件，以及條件體
接着判斷正則$labelRule2所表示的字符串是否包含於條件體中，默認是不包含的，並且$labelRule3中包含的{else}字符串是出現在條件體中的，所以進入循環，此時將條件體又分為兩塊，
分別代表兩種不同的css樣式，接着就是觸發漏洞的核心，在這里也發現了eval函數的調用，用於代碼執行的經典函數
如上圖所示，將$strif變量與if條件進行了拼接，那么此處是否存在代碼注入的情況？的確如此，此時可以看看$strif的值
其中第95條就包含有我們的payload，那么此時將payload和if條件進行拼接可以得到：
if(1)phpinfo();if(1)
此時成功閉合了php語句，並且跟后面的$ifFlag條件體也成功閉合了，所以能夠成功進行代碼執行！！！代碼注入真刺激~，到此已經實現RCE，那么想想為啥會造成這樣的漏洞，我向上看看變量是如何傳遞過來的，
parse函數就是在main.class.php這個類文件中定義的處理if代碼塊的函數，其入口參數為$content,那么回到調用parseIf函數的地方，也就是search.php，因為我們漏洞文件也在該文件，那么我們POST傳遞過來的payload最終會傳遞到content然后再進入到parseIf函數進行處理，而該處調用又是存在於echoPageSearch()函數中，那么回到該函數入口處，在其上方發現了對其的調用，現在在此文件全局搜索以下POST字符串
如上圖所示，沒有搜索到POST，那么有可能包含在common.php中，進去看看
正與我們所猜測的一樣，此時可以在注釋中發現，其通過一段循環將POST中的值注冊為變量了，並且我們提交的標量里不能包含cfg_和GLOVALS字符串，並且在COOKIE中不能夠設置，這里是為了防止變量覆蓋
接下來還調用了_RunMagicQuotes()函數對變量值進行過濾，實際上進行了一個addslashes()函數的操作，並不影響我們實際所用的payload
可以從上圖看到傳遞進來的變量直接注冊為內部的變量了，並且變量內容沒有發生變化，那么說明都是我們可以控制的，因為最后parse處理的變量是$content，那么我們需要弄清$order是如何賦值到$content中的，
再次文件中搜索$order的使用
可以找到4處調用，第一處是在函數內部global來引用，第二處又將$order賦值給$orderStr,但是這樣賦值沒有影響到$content變量，因此看最后一處調用
如上圖所示，將$content中的{searchpage:ordername}部分替換為了$order變量的值，為了更清楚的看看$content的內容是如何變化的，我們可以在158行和160行處下斷點，重新執行一次payload，此時可以在此斷點處查看$content的值，並將替換前后的$content值進行對比，可以看到str_replace()函數將進行3處替換
即在此處完成了payload對$content變量的注入，之后在最終調用parseIf()函數處理$content變量之前，又對$content的內容進行了多次替換，但是並沒有影響到我們的payload，接下來看看程序是如何解析出來我們的paylaod的
上面已經說過程序是利用
{if:(.*?)}(.*?){end if}
這一串正則來對$content變量進行匹配的，那么此時對於我們注入payload的部分，最終是eval()中包含$strIf變量，那么由於是貪婪匹配，所以首先將會匹配到第一部分{if:"}{end if} 將“匹配出來作為一部分，然后下一次匹配再匹配到1)phpinfo();if(1作為另一次匹配的部分
可以從$iar變量的值中驗證我們的推理是正確的，這里存在3處相同的匹配是因為之前$order對$content進行了3次payload注入，這樣的構造的確很巧妙，首先1)phpinfo();if(1這一部分要閉合后面eval部分，然后再要滿足前面正則匹配的邏輯能夠把payload完整匹配出來，
這可能也是開發人員沒有想到的，之后拼接的方法上面已經講了，漏洞的整個分析流程到此結束。
5.修復方法：
在64行添加
$order = ($order == "commend" || $order == "time" || $order == "hit") ? $order : "";
