前言

當(dāng)任務(wù)目標(biāo)是一個(gè)wordpress站點(diǎn)的時(shí)候，是否讓你感到過頭大?wpscan掃了半天，卻沒有任何有利用價(jià)值的bug，這時(shí)候就拍拍屁股走人了?

[[251259]]

遇WordPress頭大?讓我們從插件入手!

流行框架一般不會(huì)有什么太大的漏洞，頂多根據(jù)少有的特性接口找到一些可以利用的數(shù)據(jù)，比如用戶的基礎(chǔ)信息：ID、名稱、郵箱等，為潛在的爆破登陸做輕微的貢獻(xiàn)。

NO，這時(shí)候更應(yīng)該深入，越是掃不出的地方，越有可能發(fā)現(xiàn)有趣的點(diǎn)。而最容易出現(xiàn)非官方，有bug的地方就是插件、自定義插件、第三方功能了。

因此，在面對(duì)大型框架時(shí)，我們的入手目標(biāo)就是“一般工具掃不出、普遍站點(diǎn)不一定有，根據(jù)管理員目的后來添加的，但混入站點(diǎn)擁有一定權(quán)限和功能的”漏洞點(diǎn)。

也就是去尋找筆者所戲稱的“后入式BUG”。

尋找plugins的蛛絲馬跡

總有人說，拿到一個(gè)目標(biāo)是標(biāo)準(zhǔn)化框架，讓人看著就覺得沒什么容易下手測(cè)試的地方。其實(shí)測(cè)試的地方是有的，大佬和小白們的方式卻略有不同。

1. 工具掃描

使用工具掃描總是最輕松的，基礎(chǔ)信息刺探、簡(jiǎn)單的資產(chǎn)挖掘，甚至某些心大未修復(fù)的撿漏、備份文件暴露，特殊路徑挖掘等，都能靠掃描器就直接掃出來。但輕松是一方面，另一方面你應(yīng)該也意識(shí)到了，使用工具拼的只是帶寬和時(shí)間，你的任務(wù)入手時(shí)間，掃描持續(xù)時(shí)間，掃描完成程度，規(guī)則廣泛程度，報(bào)告書寫速度，都會(huì)影響“你與別人誰能拿到獎(jiǎng)金”的結(jié)果。而初入安全行業(yè)，偷懶不進(jìn)去不學(xué)習(xí)的人，都停步在了這里。

2. 手工審計(jì)

掃描撿漏之余，一般才是大牛們開始發(fā)力的真正比武場(chǎng)。SRC排名靠前的師傅，據(jù)我認(rèn)識(shí)的就有幾個(gè)已經(jīng)自己寫出自動(dòng)化開始做項(xiàng)目了。你用“開源掃描器+手工復(fù)測(cè)+瘋狂寫報(bào)告”跟他們拼?還是歇歇吧哈哈，他們?cè)缰苯佑肧RC的API提交了，從SCAN->TEST->POC->GETSHELL->REPORT一條龍服務(wù)。

從前我不相信這個(gè)世界有龍，直到我看到了大佬們自己寫的“日站一條龍”框架……而大佬們?cè)趽屪吡说谝徊埐说臅r(shí)候，順手也拿起勺子開始喝湯了。

事實(shí)說話，舉例說明

大型開源框架很多，能使用插件的也挺多的。比如WordPress的站點(diǎn)這網(wǎng)上一搜一大把，那我們就拿WordPress舉例說明吧。

首先隨便找個(gè)WordPress的網(wǎng)站，我們就到網(wǎng)上搜一個(gè)隨便看看吧。

按f12掛個(gè)黑頁，哦不，按f12看看站點(diǎn)目前引入的文件，和現(xiàn)在的流量情況，找找API交互的endpoint以及現(xiàn)在直接能體現(xiàn)出來的error有沒有可以利用的地方。

可以看見，這個(gè)站點(diǎn)使用了諸多的插件，某些插接因?yàn)樘”?，并沒被WPScan掃出來，即便掃出來了，或許規(guī)則庫里也沒有統(tǒng)計(jì)到有可利用的漏洞，這時(shí)候我們就可以找找這幾個(gè)插件的源碼著手審計(jì)。而審計(jì)之前，我們也可以在權(quán)限允許的頁面，順手測(cè)試一下這些插件的功能，說不定就有直觀的能黑盒測(cè)試出來的bug呢?

可以看到，這個(gè)站點(diǎn)的PM功能(私信功能)出現(xiàn)了許多奇怪的error，看類型是xhr，流量中跟隨輸入拼寫一直在遞增。貌似是查詢用戶的?不如直接找到這個(gè)API，嘗試手工測(cè)試。

可以看到，單單是黑盒測(cè)試，就發(fā)現(xiàn)此處API存在一個(gè)SQL注入點(diǎn)。

手工復(fù)測(cè)找到完美閉合方式后，調(diào)整速率再使用sqlmap確定一下，可喜可賀，確實(shí)找到一個(gè)注入點(diǎn)，類型Boolean & Time based。留好截圖，組織一下語言，把前后發(fā)現(xiàn)、復(fù)測(cè)條件、payload全附上，一篇價(jià)值2k的高危漏洞報(bào)告就出爐啦!

這里在form里調(diào)用了javascript:autosuggest()來自動(dòng)補(bǔ)全用戶信息。

再看看補(bǔ)全用戶信息怎么實(shí)現(xiàn)的，我們看看源碼，果不其然，在這段代碼中就存在一個(gè)教科書般的SQLinjection漏洞。

站點(diǎn)的開發(fā)在上線時(shí)使用了插件，卻沒經(jīng)過嚴(yán)格審計(jì)，而選擇了信任插件，實(shí)屬失誤。。

在剛剛的error信息中，隱約記得還看到了innerHtml()的調(diào)用，這可是容易出現(xiàn)xss的地方啊!當(dāng)然，修復(fù)方式建議直接了，也就不用考慮這個(gè)XSS了。。

年久失修遇見雙管齊下

就在寫文章的時(shí)候，看到上傳圖片都是直接傳到CDN的圖床了，直覺告訴我這里可能出現(xiàn)問題，那是不是圖床的第三方SDK也會(huì)有洞呢?我們來找找看。

站點(diǎn)使用的是upyun-editor的上傳代碼，其中有個(gè)類似于demo的文件引起了我的注意。

這里看到代碼，說不定可以造成反射XSS，那么我們直接POST到站點(diǎn)看看。

恩。?？磥硎钦＝馕隽恕５荂hrome下測(cè)試，會(huì)被xss defense的內(nèi)部檢查器攔截下來。。這可咋整。。

檢查發(fā)現(xiàn)站點(diǎn)的返回還與源碼本地測(cè)試的略有不同，并且既然有兩個(gè)輸入框，可不可以用組合方式繞過Chrome自帶的XSS防護(hù)呢?

我們?cè)诘谝粋€(gè)輸入框填