0x00
先自動審計，找到有eval函數的地方，根據結果可以看到eval函數集中在/inc/coomon/template.php
根據經驗，這個文件應該是用於模板渲染的。Eval函數集中出現在ifex和runphp兩個函數當中：
之後應該要找到觸發這兩個函數的方法，可以全局搜索ifex函數（runphp觸發失敗），查看有哪些地方調用：
這裏主要是用到index.php當中的調用。
0x01 關於模板調用的過程分析：
要挖掘到這個漏洞首先要了解一下整個模板的調用過程：
程序首先拆分m參數，然後根據不同類型加載不同模板：
當我們進行一次搜索時，請求是這個亞子的：
然後參數被分爲vod和search兩部分，之後加載/inc/module/vod.php文件
根據method參數爲search找到如下代碼：
我們可以看到我們查詢的參數傳遞到$tpl對象的P屬性中，之後繼續跟蹤代碼，其實就是利用正則表達式對模板文件進行替換：可以看到在第181行加載模板文件 
我們先來看一下模板文件啥樣：
其中的page:key會被替換成我們輸入的關鍵字。而且繼續跟蹤代碼，發現它調用了mark方法進行一些正則替換：
因爲這個方法當中可以調用了runphp函數，所以嘗試在這個地方嘗試觸發RCE，結果失敗了。先跳出這個函數，之後又調用pageshow函數進行處理
除了經過上面兩個方法，之後還要進過一部分的正則替換整個模板纔算處理完成
這個時候我們可以看一下模板文件被處理後的樣子：
可以發現這個時候雖然模板文件內容被替換了一部分，但是還不是前臺顯示的樣子，所以其實解析內容還沒有完全結束。而且根據之前的調試我們也發現還沒有進行過eval處理，將變量填充到模板文件中，所以之後肯定還有一步處理過程。
根據index.php內容，在加載了模板文件之後，要調用ifex方法，這個方法纔是進行變量解釋的部分：
到這整個模板加載的流程已經全部瞭解了。
在這裏我們可以發現整個模板解析過程分爲兩部分，ifex之前的部分本質就是解析模板本身的內容，將模板內要填充變量的地方填充成變量解析的格式，然後第二部分調用ifex進行變量解析。在第一部分進行替換的過程其實替換的是模板本身的內容，只要模板本身沒有出錯就不會產生漏洞。所以我們要想利用ifex解析變量過程執行惡意代碼，就必須破壞第一部分解析，在第一步解析完成之後模板內容當中必須包含我們自定義的惡意代碼，這樣在ifex解析時就會把我們的惡意代碼一起渲染解釋。那麼我們首要便是找到可交互位置，只有我們輸入的內容，前臺也進行輸出，才說明我們的輸入被添加進入模板文件了。
0x02
這裏選擇搜索框當作漏洞觸發點。
根據之前的跟蹤我們發現ifex解析之前，模板的內容是有自己的固定格式的，而且通過分析ifex函數也可以看出來：
可以看到ifex通過一個正則表達式來識別這種固定格式，然後將識別內容全部存入數組$iar當中。關於這個正則表達式，我們來具體看一下：
他會匹配如上的一個格式，然後keyword位置的內容會被存入$iar[2]數組，之後賦值給$strif，因爲這個變量會拼接到eval當中，所以要特別關注。
接下來我們通過debug方式來看一下之前的分析是否正確：在搜索框輸入上面的字符串
經過第一部分替換之後：
進入ifex進行解析時：
可以看到我們之前的分析沒有錯，而且可以看出我們輸入的惡意已經確實已經改變了模板的結構，之後繼續debug看如何觸發eval執行自定義代碼：
可以看到在第904行輸入的keyword被傳遞到eval函數當中：通過echo輸出eval執行的字符串：
可以嘗試自己拼接php代碼執行任意代碼。不過要注意的是存在危險字符過濾，所以構造php代碼時要注意：放出最後寫shell的payload：
利用base64編碼繞過單雙引號限制，利用file_put_contents寫入文件。
成功寫入一句話木馬：
在下載的另外一個版本中發現了修復方案：