看懂了revision和漏洞原因WordPress批量添加欄目,利用應(yīng)該很簡單:
對寫入文章的revision進行評論
編輯評論狀態(tài)為注入攻擊語句
WordPress批量上傳內(nèi)容將revision丟入垃圾箱
WordPress批量添加產(chǎn)品還原最開始的文章(revision的原版)
看似沒有什么問題,不知道各位還記不記得我們上文說的_wpnonce。對!就是這個坑!作者通篇沒有提到這個漏洞要怎么獲取_wpnonce!這最直接的導致我們第1、2、4步?jīng)]有辦法玩了o(╯□╰)o。
我猜測作者沒有提及這個問題,要么是他自己也沒找到,這篇文章其實只是個標題黨,要么是他藏了一手。從作者前后漏洞關(guān)聯(lián)的那么緊密來看WordPress批量添加欄目,我比較傾向于后一種原因,所以這里要幽怨的瞪他一眼~~
小結(jié)
作者利用讀取數(shù)據(jù)庫中存儲內(nèi)容沒有進行過濾的盲點進行二次注入的思路比較直接,但是利用revision編輯垃圾箱中文章這個點真心贊。
在分析過程中發(fā)現(xiàn)revision的編輯并非向作者所說的可以改成trash之外的任意類型,文章狀態(tài)大概有publish、future、private、inherit、auto-draft、attachment、draft、pedding、trash這幾種WordPress批量助手,而我們所能修改的文章類型只能是inherit、pedding和draft這三種。否則,如果我可以修改文章狀態(tài)為private,從前臺完成利用第1,2步操作.
斷斷續(xù)續(xù)的跟了這個漏洞一周的時間了,最大的感受就是作者真心是個坑o(╯□╰)o
0x03 總結(jié)
跟這個漏洞體會最深的就是Wordpress的token機制在防護csrf的同時,也協(xié)助防御了其他類型的攻擊,一個很好的機制。
GP操作的邏輯是Web代碼的一個問題,尤其是在做一些權(quán)限校驗時候,很容易出現(xiàn)Wordpress這樣的GP交叉導致的邏輯混亂問題。
二次注入應(yīng)該算是一個老生常談的問題了,過于信任已記錄的數(shù)據(jù),最終會導致忘記這條記錄其實是用戶寫入的。
文章地址:http://www.brucezhang.com/article/wordpress/ldlydzzssdyn.html