應急響應之某公司的粗心導致網站被惡意篡改
一、事件說明
一日,某公司接到來自監管單位的通報,表示該公司的網站存在S情違規內容......于是乎我又得出發了,先是向客戶要到了網站的地址先看看哪里存在違規的內容,一頓亂翻網站上的子頁面都顯示正常,回到首頁按下F12果然網站的關鍵字標簽那被修改了。

二、現場處置
擰著我的小電驢到達現場后,開始跟負責網站的管理員進行談話了解當前的網絡情況,當前網站呢是部署在四川西部數碼服務商上的,租用的是虛擬空間并沒有登錄服務器的權限,平時維護更新文件是也都是通過FTP進行上傳更新的,而且也未購買什么安全防護。
因為網站首頁文件已經被修改了,所以我們看到index.html的修改日期為6月28號19:08分也就是在此時發生了篡改,值得注意的是當我們需要將FTP上的文件進行下載到本地電腦查看時,需要將虛擬空間上的源文件都打包成一個壓縮包在下載下來,不然使用FTP一個個下載下來時文件的修改時間將是下載的當前時間,這樣會對后面結合日志分析的溯源工作帶來一定的困難。

三、事件分析
當頁面被惡意篡改,那說明網站的控制權已經被獲取了,而修改的內容為首頁的源代碼文件說明獲取的權限比后臺管理員擁有的權限更大可以隨意的更改源代碼,但也不排除有些網站的后臺管理功能也是具備編輯網頁的源代碼的,所以說那網站上肯定是被黑客上傳了后門文件。
下面咱們就使用D盾webshell專殺工具選擇網站的wwwroot根目錄進行一個全面的查殺看看黑客一共上傳了多少個后門文件,可以看到共檢測了5731個文件其中6個文件:radminpass.php為dedecms的管理員重置腳本,config.php、buak.php、lower.php、pig.php、need.php均為大馬后門文件。

細心的朋友這時就發現了radminpass.php這個密碼重置腳本與其他后門的修改時間相隔了兩年反而與網站內搭建時生成的文件時間不相上下,當時我也疑惑為什么會不一樣呢?還是先來看看radminpass.php有何作用吧。
radminpass.php是織夢官方發布的管理員密碼重設工具,只需要將對應編碼的radminpass.php文件用ftp上傳到到網站根目錄,并訪問該文件(例如:http://www.xxx.com/radminpass.php)把域名更換為自己網站的域名進入密碼重置界面。



啊這......直接訪問腳本修改了admin的管理員賬號密碼并不需要輸入舊密碼即可修改,隨后詢問網站的負責人才得知,早期的時候忘記過密碼并使用了這個重置密碼的腳本修改了密碼,至于當時自己修改后有沒有刪除腳本早也沒了印象。
到這里思路就比較明朗了,前面知道了首頁發生篡改的時間為6月28號19:08分最早上傳的config.php后門文件為6月27號16:24份,根據這個時間點篩選6月24號至6月30網絡日志進行分析,搜索radminpass.php的流量發現早在24號時就有人訪問了,但在27號8:21分開始時只有一個1.206.x.x的IP訪問GET請求后又三步POST數據提交的操作,很像前面的改密三步曲,所以此IP為攻擊者的嫌疑最大且與網頁被修改的時間最相近。

根據分析到嫌疑IP1.206.x.x在進一步的篩選日志,可看到改IP的所有操作行為,先是利用密碼重置腳本修改了密碼,隨后馬上訪問了/tmcmspc56/login.php后臺界面進行登錄下一條的/tmcmspc56/index.php說明已經登錄成功。

四、后門分析
前面知道了網站上存在最早的后門文件為config.php,一樣的對流量日志進行篩選config.php瞧瞧它是如何被上傳的,可見攻擊者先是訪問file_manage_view.php文件后往下接著一條POST數據從而產生了config.php文件。

回到網站文件目錄查看file_manage_view.php文件,好家伙這是一個管理后臺的文件管理編輯器,攻擊者是直接在后臺添加生成了個大馬的后門文件啊這是。


下面看看其他的后門文件是如何被上傳的,依據時間順序搜索buak.php后門文件看得出是通過config.php上傳的。

繼續搜索lower.php后門文件,是由app.php文件上傳的,但D盾并未掃出該文件到流量日志記錄的路徑下查看也并未發現有該文件存在,應該是已經被刪除了。


那app.php又是如何上傳又是哪個IP上傳的呢,篩選app.php可見是有buak.php上傳而來的。

只剩下pig.php和need.php兩個后門文件了,在經過一輪的篩選need.php是app.php文件上傳的,而pig.php后門文件并未篩查出,只有一種可能是攻擊者上傳后將原來的后門文件重命名成了pig.php。


五、總結
IP為1.206.x.x的攻擊者首先是在27號8:21分首先發現了radminpass.php密碼重置腳本,并在8:22分修改了管理員admin賬號的密碼并且登錄了后臺,在8:24分時訪問了后臺file_manage_view.php文件管理編輯器上傳了config.php的大馬后門文件,隨后通過config.php后門文件上傳了buak.php后門,再由buak.php上傳了app.php(目前已經刪除),再再由app.php生成的need.php的后門文件(iis日志需加8個時間段即可對應正確發生時間),細心的小伙伴就發現了,每生成一個新的后門所連接的IP就會發生變化,其實原因很簡單可以大膽的猜測這是一起webshell的買賣行為,一個賣另一個的。
綜合以上的分析,此次事件的關鍵點在于運維管理人員的粗心大意導致了攻擊者的有機可乘。
