混跡在各大SRC平臺的白帽子手里都握著很多法寶，或私藏或公開。而給大家介紹下基于cms的漏洞掃描，如何挖漏洞
1 緒論
1.1 首先獲取補天廠商名單，這里保存在d:/butian.txt。你也可以放入各大src的域名
1.2 本cms是基于知道創宇的Pocsuite二次開發。漏洞掃描器主要是掃描平臺的整體框架設計，而真正需要耗時和長期維護的便是poc的編寫與擴充。這里，重點在于poc的編寫與擴充。
1.3 編寫poc并批量掃描網站，將存在漏洞網站提交漏洞給相應廠商
2 系統設計
2.1 系統體系結構設計
本系統是基于CMS的漏洞掃描工具，確切來說是使用python作為腳本語言，使用PoC 編寫的 SDK，自動化的調用測試，將payload按照一定格式寫成py文件，并注冊為類，為工具調用。支持驗證與利用兩種插件模式，你可以指定單個目標或者從文件導入多個目標，使用單個 PoC 或者 PoC 集合進行漏洞的驗證或利用。可以使用命令行模式進行調用，也支持類似 Metaspolit 的交互模式進行處理，除此之外，還包含了一些基本的如輸出結果報告等功能。本文采用pocsuite這一poc開發框架，主要使用烏云作為漏洞獲取平臺，在實際批量掃描的過程中用多線程、鎖、隊列來實現，掃描結果直接寫入doc文件，在采集漏洞信息編寫payload文件要選擇盡可能詳細的內容，包括漏洞名稱，漏洞編號，漏洞來源，漏洞發布時間，漏洞廠商，漏洞CMS類型，漏洞版本，漏洞編寫人，漏洞編寫時間，漏洞詳情，漏洞修復方案，漏洞類型，漏洞原理等等。這樣方便以后對此漏洞的查閱修改以及漏洞結果更為自動人性化輸出。本系統運行流程圖，如圖 2-1所示：
2.2 詳細功能模塊設計
2.2.1 基礎掃描框架功能設計
本系統采用pocsuite作為poc開發框架，在此基礎上修改代碼使更適合本系統設計目標，并編寫漏洞payload文件使增加豐富系統漏洞掃描，即可執行命令啟動程序運行。這邊對他進行改動如下：
(1)payload文件格式，增加漏洞修復、漏洞描述、漏洞等級等內容。
(2)漏洞結果生成。這邊改動為，生成隨機文件夾里面每個url每個payload文件生成一個doc文件，文件名格式[網站域名].doc,文件內容使用python的庫docx來生成doc格式的文件。
2.2.2 漏洞類型功能設計
CMS漏洞類型較多，常見的有：命令執行，SQL注入，XSS攻擊，邏輯漏洞，越權操作，文件上傳，文件讀取等等。這些漏洞類型又可以繼續往下細分。在實際編寫時，要根據具體情況，編寫payload文件，不是每種漏洞都可以編寫payload文件進行批量掃描。需要在CMS漏洞類型的確認上下功夫，接下來會拿SQL注入和XSS來做分析。
-
SQL注入漏洞 包括布爾型注入，報錯型注入，可聯合查詢注入，可多語句查詢注入，基于時間延遲注入五種，其中布爾型注入在編寫POC的時候是不能編寫到工具中的。我們判斷是否存在注入只能通過構造特殊語句發送請求，返回頁面是否正常。正常頁面和錯誤頁面的不同因網站源碼設計而不同，無法寫出通用規則。基于時間延遲注入編寫出的POC是基于兩個不同的請求判斷響應時間，如果第一個請求<=1秒，第二個請求>=5秒，算漏洞存在[10]。由于網絡原因請求時間會有延遲，導致恰好滿足漏洞存在條件批量掃描時候顯示漏洞存在，實則屬于誤報。這樣每次批量掃描之后還需要手工驗證漏洞是否存在，那么這種漏洞就沒必要加進來。所以，在選擇SQL注入的時候，避開這兩種類型。規范如圖 3-2 所示：
圖3-2 編寫SQL注入POC流程圖 -
XSS攻擊 如果網站僅僅能彈出框，并不能在頁面源碼上造成可識別的影響，我們在編寫利用腳本的時候無法準確判斷是否存在漏洞。除非對網頁造成影響，通過一些唯一特定，可以確定就是這種CMS類型。比如DEDECMS 5.7的/images/swfupload/swfupload.swf文件中的參數movieName沒有經過有效過濾，且影響的是swf文件，導致跨站腳本漏洞。我們在利用時候只能彈出框，尚不能編寫出具有唯一標識的payload。payload編寫為
/images/swfupload/swfupload.swf?movieName=%22]%29}catch%28e%29{if%28!window.x%29{window.x=1;alert%28%22xss%22%29}}//。頁面未造成影響不能繼續深入，只好作罷。
綜上，實際操作時候要像計劃靠攏，由于場景不同導致可能與計劃有一定偏差。
2.2.3 系統運行設計
CMS漏洞掃描工具是通過輸入不同的命令來控制不同的掃描方式。輸入命令將程序運行，然后輸出一些界面信息比如什么工具、什么版本、當前運行時間之類表示程序已經啟動，接著是，開啟線程調用注冊過的POC類，批量掃描，掃描過程界面上會實時顯示掃描的網站信息，最后掃描結束，生成報告日志。系統運行流程如圖 3-3 所示：
3 系統實現
3.1 系統整體模塊實現
工具需要最基本核心的是基本框架的實現，只需要把重心放在基本框架上對于多線程的寫入提高了系統運行效率，其他就是源源不斷的整合CMS漏洞，寫出的payload只需要按照一定格式寫進入就可以使整個工具跑起來，不需要把精力放在如何跑起來這種重復的工作上。程序運行起來的過程是：啟動入口文件pocbase.py,調用pocbase/pocbase_cli.py里main()，接著調用pcsInit()將程序啟動起來。目錄結構如表 3-1 所示：
其中pocbase文件夾里面是讓程序運行起來的文件函數以及第三方庫，目錄結構如下：
├── docs #說明文檔
├── POCAPI.md #POC編寫規范及相關API
├── pocsuite #pocsuite主程序
│ ├── data #基礎數據
│ ├── lib
│ │ ├──controller
│ │ ├──core #核心組件
│ │ ├──parse #參數處理封裝
│ │ ├──request #網絡請求封裝
│ │ └──utils #常用工具包
│ ├── modules
│ │ └──tmp #臨時目錄
│ ├── pcs-attack.py #攻擊程序
│ ├── pcs-console.py #控制臺程序
│ ├── pcs-verify.py #驗證程序
│ ├── pocsuite.py #pocsuite主入口程序
│ ├── tests #測試poc目錄
│ └── thirdparty #第三方庫
└── README.mdTest文件夾是編寫的CMS漏洞的payload文件。包含haha,time_sql_inj兩個子文件夾。haha文件夾里的payload文件是驗證成功率100%，完全不用人工參與，輸出數據完全正確可信。time-sql-inj是時間盲注，也就是由于網絡原因可能造成誤差的payload文件，我們無法消除，只能通過二次運行來確認漏洞是否存在。
haha文件夾內容根據漏洞類型化為為不同的文件夾存儲。由上而下分別是：代碼執行漏洞，設計漏洞，文件下載漏洞，文件讀取漏洞，文件上傳漏洞，信息泄露，OpenSSL，解析漏洞，SQL注入漏洞，URL重定向漏洞，XSS攻擊漏洞。
haha文件夾如圖 3-1-1 所示：
這些文件夾里面是關于所有相同漏洞類型可以是不同CMS的payload文件。拿SQL_Inject來說里面包含的CMS類型有：
AspCMS,DedeCMS,eYou,FangWei,OhHu,PHPCMS,QiboCMS,searun,ShopBuilder,Siteserver,V5shop,Vallery,YongYou,YuCheng,ZhengFang,ZuiTu等。如圖 3-1-2 所示：
3.2 基礎掃描框架模塊
掃描結束生成報告文件，我這邊設計的是生成doc文件，利用Python庫docx里面的Document來制定通用doc生成規則。Kb.results里面存放的是驗證結果的數據部分，對它進行循環取各部分值插入到doc文件相應位置。
3.3 Payload文件編寫模塊
3.3.1 編撰payload文件通用規則
本模塊實現了在批量的同時，有一些站為了防機器人，需要看你有沒有 HTTP 請求頭的，比如有一些 WAF 會檢測請求中是否有 User-Agent, 所以 PoC 中需要 Cookie 。
代碼整體結構：
最上面是引入一些類庫，中部是一個 PoC 的類，繼承自PoCBase 類，類中有兩個函數，_verify和_attack ,這兩個分別是 verify 和 attack模式的入口函數，然后還有一個用戶自己定義的函數parse_result , 用于統一輸出。類里的變量是對漏洞描述的詳細介紹，由上而下為：漏洞id，工具版本，漏洞編寫者，漏洞發布時間，漏洞寫入工具時間，漏洞文件最近更新時間，漏洞來源，漏洞名稱，CMS鏈接，CMS名稱，CMS版本，漏洞類型所屬文件，漏洞類型，漏洞原理，漏洞修復，漏洞危害級別，漏洞詳情描述。有了這些變量在漏洞掃描結束這些信息會選擇性的寫入漏洞結果的doc文件。
其中，pocbase/lib/poc_base.py文件是寫一些編寫payload文件常用到的函數。
3.3.2 編撰payload文件
由于編寫payload文件流程都一樣，這里拿asp來舉例。通常還會有jsp,php,java等不同腳本語言寫的cms。比如漏洞：KesionCMS最新版本可下載數據庫直接破密碼，kesioncms是asp寫的cms。漏洞原因可直接訪問/KS_Data/KesionCMS9.mdb路徑，下載數據庫文件到本地。把文件用Easy Access打開，表結構及KS_Admin中數據如圖 3-3-2-1 所示：
由圖知，用戶名為admin 密碼為469e80d32c0559f8。憑經驗看出密碼是經過MD5加密之后存到數據庫中，我們在網站http://pmd5.com/# 上MD5解密之后得到密碼為admin888，如圖 3-3-2-2 所示：
有了賬號用戶名密碼之后接下來就不用說了，我們可以通過御劍掃描或憑借滲透經驗找到后臺網址，登錄用戶名密碼，進入后臺，查看后臺是否有權限直接或間接上傳webshell，進而提權，控制服務器等等。目前都已經有網站的數據庫了，可以拿到網站所有數據。
接下來，嘗試編寫payload然后找環境來測試編寫的payload是否成功。先本地搭建asp運行環境，下載小旋風Asp Web服務器，安裝之后開啟軟件，嘗試下載KesionCMS漏洞相應版本到本地，經過測試是v9.5的版本，本地測試漏洞恰好存在。訪問鏈接/KS_Data/KesionCMS9.mdb如圖 3-3-2-3 所示：
這里點擊保存把文件下載下來，這邊用text文件下載下來會發現mdb文件里面都有Standard Jet DB，所以編寫payload時候可以模擬請求獲取下載文件讀取文件然后查找是否有關鍵字StandardJet DB。這就是漏洞編寫的原理。
編寫完之后進行運行是否成功。如圖 3-3-2-4 所示：
這樣證明我們的payload文件編寫正確了。還需要批量掃描50個網站，查看掃描結果，對驗證成功的網站人工驗證是否成功，修正并反復這一過程，來提高payload的準確率。
Payload文件編寫流程如圖所示：找到漏洞來源網站分析漏洞原因-本地搭建環境或網絡上找漏洞環境進行測試漏洞寫出payload，編寫payload文件，用工具驗證是否成功，用一千個網站跑這一payload文件驗證是否有誤差，如有誤差重新編寫繼續上述過程。
3.4 HTTP請求
Payload的原理是通過工具模擬發送HTTP請求，包括GET請求，POST請求，PUT請求來獲取網頁源代碼，匹配特定字符，來驗證漏洞。
HTTP是計算機與網絡通信的協議，會給服務器一種瀏覽器訪問的錯覺，也就是在請求時候，模擬瀏覽器請求機制，加上瀏覽器的請求頭[14]。如圖 3-4-1 所示：
當瀏覽器向Web服務器發出請求時，它向服務器傳遞了一個數據塊，也就是請求信息，HTTP請求信息由3部分組成：請求方法URI協議/版本，請求頭(Request Header)， 請求正文。以下程序為驗證漏洞是否存在，模擬請求：
3.5 多線程
多線程通過劃分時間來實現，即把時間分成一個個片，每片處理一個線程，所有的線程循環處理，而多處理器可以同時實現多線程[15]。多線程是為了把多項任務同步完成，來提高資源使用效率來提高系統的效率。線程是在同一時間需要完成多項任務的時候實現的。簡單來說，一個項目要在一天完成總共10個人同時進行，把一個項目細分為兩個過程，第一過程劃分為相似的10份小任務，都做完之后，又把第二過程分為相似的10份分配小任務作同時進行。如圖 3-5-1 所示：
下面是使用多線程的實例：
4 系統測試與運行
4.1 測試環境
環境要求：Python 2.7.8 Python依賴包： pocsuite==1.2.6 python-docx==0.7.4 python-memcached==1.57 redis==2.10.5 requests==2.8.1 chardet==2.3.0
如圖 4-1所示：
4.2 工具運行參數
sage: pocbase [options]
optional arguments:
-h,--help Show help message and exit
--version Show program'sversion number and exit
target:
-u URL,--url URL Target URL (e.g."http://www.targetsite.com/")
-f URLFILE,--file URLFILE Scan multiple targetsgiven in a textual file
-rPOCFILE Load POC from a file(e.g. "_0001_cms_sql_inj.py") or directory (e.g."modules/")
mode:
--verify Run poc withverify mode
--attack Run poc withattack mode
request:
--timeoutTIMEOUT Seconds to wait before timeoutconnection (default 30)
--delayDELAY Delay between two request ofone thread
params:
--extra-argumentsEXTRA_ARGUMENTS Extra arguments (e.g."{username: '***', password: '***'}")
optimization:
--threadsTHREADS Max number of concurrent HTTP(s)requests (default 1)4.3 功能測試
4.3.1 多CMS漏洞對應多網站掃描
啟動腳本，入口文件pocbase.py,參數r指向要掃描的文件夾路徑，參數f為本次掃描的url文件路徑，參數threads為本次掃描開啟的線程數。如圖 4-3-1-1所示：
本次掃描只掃描SQL注入 掃描url文本url1.txt 本次線程數100，掃描結果如圖 4-3-1-2所示：
本次掃描2419次 存在漏洞23個 黃色的是漏洞結果生成文件地址
掃描時間用時1分鐘 掃描網站數42個 sql注入CMS漏洞數60個 本次掃描準確率100%
驗證成功的SQL注入，如圖4-3-1-3所示：
其中，編寫的payload中，是ader_duo經過ascii碼轉換之后的字符，在獲取源代碼的匹配ader_duo關鍵字。匹配成功率為100%。因為payload里訪問連接中并不存在。
CHAR%2897%29%20%2b%20CHAR%28100%29%20%2b%20CHAR%28101%29%20%2b%20CHAR%28114%29%20%2b%20CHAR%2895%29%20%2b%20CHAR%28100%29%20%2b%20CHAR%28117%29%20%2b%20CHAR%28111%29%20%2b%20CHAR%2899%294.3.2 多CMS漏洞對應一網站掃描
啟動腳本如圖 4-3-2-1所示：
本次掃描只掃描sql注入 掃描url網站 http://www.xxx.cn 本次線程數150。如圖4-3-2-2所示：
本次掃描66次 存在漏洞1個 黃色的是漏洞結果生成文件地址
掃描時間用時6秒 網站數1個 SQL注入CMS漏洞數66個本次掃描準確率100%
本次驗證成功的，data構造時候需要經過base64加密，可直接顯示出authkey。如圖4-3-2-3所示：
4.3.3 一CMS漏洞對應多網站掃描
啟動腳本如圖4-3-3-1所示：
本次掃描只掃描IIS解析漏洞 掃描url文件11.txt 本次線程數150。如圖 4-3-3-2所示：
本次掃描5次 存在漏洞4個 黃色的是漏洞結果生成文件地址
掃描時間用時3秒 掃描網站數5個 檢測CMS漏洞數1個 本次掃描準確率100%
4.3.4 一CMS漏洞對應一網站掃描
啟動腳本如圖4-3-4-1 所示：
本次掃描只掃描IIS解析漏洞 掃描url網站 http://www.luohezx.xxx.cn 本次線程數未選擇默認為1如圖 4-3-4-2所示：
本次掃描1次 存在漏洞1個 黃色的是漏洞結果生成文件地址
掃描時間用時2秒 掃描網站數1個 檢測CMS漏洞數1個 本次掃描準確率100%
本次驗證成功的，訪問連接證明漏洞存在。如圖4-3-4-3所示：
4.3.5 漏洞生成日志
掃描結束生成日志，顯示日志文件地址在命令行里以黃色字體展示
日志內容如下（xxx.xxxxx.xxx.cn存在SQL注入漏洞為例）：
文件名為：[szb.zhengzhou.xxx.cn].doc
文件內容如圖 4-3-5-1所示：
5 測試總結
能夠實現工具掃描的完整流程，從掃描開啟，靈活的掃描方式到多線程加快掃描速度，最后顯示總掃描數量和存在漏洞的數量，將掃描結果寫入日志文件，并輸出日志文件地址結束整個掃描過程。該掃描工具能成功運行，并且延展性是比較強，編寫CMS漏洞payload文件有一定規則，整合新的漏洞進去對整個工具的運行不會造成影響。
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/492/
