ZZCMS v8.3二階注入之一次小心的試探
*本文原創作者:丶樓蘭,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載
萌新入坑PHP程式碼審計中╭(°A°`)╮選了這個易上手CMS,費盡心思審計出了一個有趣的二階注入,滿意的睡了,第二天打算寫文件的時候,竟然發現……
0×00 漏洞程式碼
使用者在釋出資訊時,儘管對POST資料使用了addslashes函式,但是由於editor引數可控仍舊可以插入構造好的Payload
/user/zxsave.php 第51行:
在檢視使用者釋出的資訊時,會查詢文章id所對應的相關資訊。
/zx/show.php 第36行:
會根據該資訊id,需要具備的檢視資訊的使用者組級別(groupid)來進行判斷,如果groupid不為0,並且檢視資訊時需要花費積分時,那麼便會呼叫Payif函式。
/zx/show.php 第155行:
如果使用者積分多餘檢視資訊的積分時,那麼便會:
- 減去檢視者對應的積分(根據cookie裡面的Username引數);
- 增加發布者對應的積分(根據檢視文章對應資訊裡面的editor欄位);
/zx/show.php 第92行:
例如:
1.正常模式下:editor=admin,$jifen=10時,那麼第二條查詢語句便是:
update zzcms_user set totleRMB=totleRMB+10 where username = 'admin'
如果 editor=’ and groupid=(select sleep(3)) — – 時,那麼第二條查詢語句便是:
update zzcms_user set totleRMB=totleRMB+10 where username = '' and groupid = (select sleep(3)) -- -'
此時我們便可根據頁面所響應的時間,來判斷查詢語句是否成功了。
0×01 利用漏洞
可以看到普通使用者的groupid是1。
在釋出資訊是可以選擇vip使用者才能檢視或者高階會員檢視,或者直接在BurpSuite中修改groupid為2,並設定檢視積分為大於0的值:
在檢視該資訊時可以看到,添加了限制:
此時將editor設定為咱們的Payload:
此時在檢視資訊時便可以看到響應時間的異常:
我們最後傳入資料庫的SQL語句如下,可以看到,這樣的話我們每執行一次查詢語句便加不了10積分,而檢視資訊卻需要10積分,這樣說來,執行一次Payload需要十積分,經過測試,最少也是1分,這…也太豪了。
update zzcms_user set totleRMB=totleRMB+10 where username = TEag1e” and groupid = (select sleep(3)) — -’
經過我思考後,我將and邏輯運算子替換為了or邏輯運算子,醬紫的話,便可以減10,加10了,一分錢不花了
然後說一下我遇到的坑/新GET到的細節:
MySQL中在使用or邏輯運算子時,如果前面的條件已經將資料庫中的結果全部篩選出來了,那麼or後面的條件便不會在進行執行了。
例如:此時資料庫中全是groupid為1的使用者
如果SQL語句是:
update zzcms_user set totleRMB=totleRMB+10 where groupid = 1 or username = (select sleep(3))
那麼username後面的自查詢便不會執行,而如果使用的是and邏輯運算子的話,如果and前面的條件一條資料也查詢不出來時,那麼and後面的子查詢語句便也不會執行了。
0×02 第二天醒來
第二天,我正要寫文件的時候,發現咋就失敗了呢,等我回到資料庫中時,發現editor欄位竟然設定了50個字元的限制,好慘…
儘管有些失落,但是我並不氣餒,畢竟漏洞被忽略的多了已經習慣了。。
0×03 一些小東西
上文筆者已經說過了,看積分文章時:
1.減去檢視者對應的積分(根據cookie裡面的Username引數);
2.增加發布者對應的積分(根據檢視文章對應資訊裡面的editor欄位)。
經過測試發現此處存在邏輯漏洞,未校驗cookie裡面Username引數,那麼釋出資訊時,將editor設定為咱們自己的使用者名稱,在檢視咱們構造的需要花費積分的資訊時,將cookie裡面的Username設定為其他使用者的使用者名稱。
那麼:每看一次,受害者便減掉10積分,而我們則加10積分。
看一下初始時兩個使用者的積分:
此時我們設定好前置條件後,在檢視該資訊時,將Username為test: