一次腳本注入廣告漏洞分析

若是網站忽然彈出一個廣告（不是本身主動添加的聯盟廣告），第一直覺是DNS劫持，在此以前也是惟一直覺。以前遇到過幾回DNS劫持，WAP站彈出廣告，路由器被劫持彈出廣告。未經歷其它安全事件以前，我也只是偶爾關注一下安全事件，上一次重大修復仍是去年，這一次問題也比較嚴重，能夠說是很嚴重。

尋找漏洞

年前快放假了，有同事反饋展現庫彈出廣告，分析沒有發現劫持現象。抓包調試發現所有js文件被篡改了，篡改仍是以編碼的形式，執行時解碼。看來此次遇到比較厲害的角兒了。可是它是如何篡改js文件的呢？

1. 服務器異常
   服務器安全軟件所有是異常的，難道是服務器被黑了，直接拿到權限到服務器去執行了腳本程序，檢查了login日誌也沒有發現異常，看來仍是要另尋問題分析。一系列安全查殺開始運行一圈。
   
2. http服務器日誌異常
   日誌對於問題分析很關鍵，但有一種狀況就是未出問題以前沒有服務器日誌，也或者說攻擊者刪除了服務器日誌，要怎麼辦呢？若是真的是這樣，我也就只能呵呵了，事實也就是這樣，呵呵噠！
   對於發現的網站，手動修改了被篡改的js文件，表面上解決問題了，但事實是轉眼又被篡改了。
   明天就放假了，今天還在這裏查找漏洞，情何以堪。一時不能分析日誌，能作的就是從新設置開啓服務器日誌，關閉上傳功能，目錄權限只讀。先暫時處理問題，過完年再回來徹查問題。其實問題根本沒有解決，若是木馬腳本已經上傳到服務器了呢？問題也依然沒能解決，若是關鍵詞查詢一下就能夠找到相關腳本文件了。
   
3. 年後問題依舊存在
   網站js文件所有被篡改了，包括未使用的文件也被篡改了。一邊寫腳本批量替換掉被修改的文件，一邊關鍵詞查詢木馬文件。nodejs寫了一個簡單的批量替換腳本，木馬腳本文件也找到了，經過上傳漏洞上傳了一個生成一句話木馬的文件，一句話木馬文件就想幹嗎幹嗎了，其中還生成了一個大馬，一個服務器文件管理後臺，看到這個大馬腳本，一下以爲本身接觸的內容太寒摻了。
   能找到文件可是還找不到上傳漏洞，問題依舊是問題，同時線上客戶網站也發現了一樣的問題，線上服務器日誌存在。向IDC索要了服務器日誌文件，分析時發現了一個1.php，aboutus.php文件，以及上傳漏洞位置。

分析漏洞

程序使用的是phpcms深度二次開發獲得的，天然而然phpcms的問題依舊是咱們的問題，對於phpcms的版本不斷升級，發現的安全問題也在不斷完善修復，咱們的程序沒有及時關注漏洞更新也就致使了這起問題的發生（漏洞修復期間依舊後期，我嘗試了一些其餘線上網站，原來沒有就是安裝補丁的不止少數）。

頭像上傳漏洞

經過api接口查看到key，拿到key之後再按照本地生成data的方法，手動生成data數據，拼接url避開驗證獲取上傳路徑，經過上傳漏洞直接上傳腳本文件至頭像目錄（上傳是用的swfObject，flash生成大小不一的尺寸，而後壓縮上傳，後臺程序解包至指定文件夾就完事了，沒有過濾非法文件以及文件夾），使用burp抓取請求，替換請求數據（數據中包含腳本）。
get authkey

/api.php?op=get_menu&act=ajax_getlist&callback=aaaaa&parentid=0&key=authkey&cachefile=../../../phpsso_server/caches/caches_admin/caches_data/applist&path=admin

upload url

/phpcms/phpsso_server/index.php?m=phpsso&c=index&a=uploadavatar&auth_data=v=1&appid=1&data=6550BQMJAVJRCAMFBlNUVFIHC1JVCAIMVgAOB1FFCFILBkRFQGZQFxVQbF5TGAsBQQgKUQRId1YVClBTJ15YYQFwUnpjalYXI11DZHkGAQ

burp攔截修改http請求

修改請求主體內容爲本身須要提交的腳本內容

腳本執行
這裏能夠直接上傳腳本，也能夠上傳一個生成一句話腳本的文件（想怎麼作你本身看着辦，不作違法的事情）

更多隱藏漏洞

一個開源編輯器，沒有使用，沒有修改默認配置，因而乎也是一個潛在危害，對於程序中不斷引入愈來愈多的模塊，安全性真的值得考慮。

分析末尾

沒有深刻總結問題，主要細節包含批量替換腳本的製做。本地展現庫使用nodejs處理zip包相關node-archiver，php腳本相關的是類ZipArchive，但最後仍是使用c#弄了個exe。暫時告一段落，也只想呵呵了。

參考資料

node-archiver
ZipArchive
wooyun