網站論壇被黑客攻擊解決方案(論壇被黑怎么解決)

時間回到半年前,當時好友反映,最近論壇怎么這么慢,是不是被攻擊了?在線人數也屢破新高,人氣卻沒有明顯增長。我打開網站看了下,的確,直觀感受是慢了些,但首頁、版面、帖子頁面的源碼都沒什么異常。先安撫朋友,阿里云有時是這樣拉,在一個物理機里擠的虛機多拉,店大欺客之類。

 但在線數據不是這樣說,說明這些訪問是實實在在的來了,一邊安撫朋友,一邊分析日志,發現了一些異常。原來攻擊源來自百度,怎么可能?但的確是這樣,把近幾日的日志統計出來,來自百度的采集請求近百萬/日,agent正常,不像是偽造的請求,這個量級的采集對朋友的小站來說,確實相當于拒絕服務攻擊了。具體看了一下采集的地址,卻發現了一些問題,隨便帖幾個,都是類似這樣的:

/thread-15063160275-1-1.html

/thread-29704948585-1-1.html

/forum-71459571159-1.html

/forum-94009706208-1.html

 對Discuz偽靜態熟悉的朋友一看就知道問題所在了,這種tid或fid的請求基本上是不會存在的。那我們自己訪問一下看看,百度為什么會對這樣的地址感興趣?用自己的瀏覽器訪問之后,論壇給出了正確的反饋:“抱歉,指定的主題不存在或已被刪除或正在被審核”,“抱歉,指定的版塊不存在”。恩,跟“不存在”的猜想一樣。可是百度為什么要這樣做?類似的地址是怎么進入百度采集庫的,總不會憑空出現的吧。這個問題困擾了幾天,一直想不明白,朋友的小站就在百度的“攻擊”下艱難的生存。

 后來想到,總是這樣也不行啊,先對百度限流吧,研究了一下robot.txt語法,發現百度才是店大欺客,通用的限制語法百度一概不遵守,只有去注冊百度的站長平臺,驗證好站長身份,然后提交限制采集頻率的申請。可是這個申請只管30天,即使掛馬問題最終被解決,朋友的小站也要每30天去限制一下采集頻率,這是對小站的長久影響,還不算這段時間之內,正常的內容沒被采集到的損失。限制采集上限之后,小站第二天就生龍活虎了,但這只是治標,沒有治本啊,問題到底出在哪兒?

 在百度的站長平臺閑逛,發現有模擬采集的功能,隨意測試了一下小站主頁,終于發現了這個秘密。

 模擬采集來的頁面源碼,有了明顯的篡改痕跡,里面加了十行類似“
thread-15063160275-1-1.html”這樣的連接,數字都是隨機生成的,每次刷新都不一樣。而通過模擬采集這個隨機連接,內容更是完全驢唇不對馬嘴了,根本就不是朋友小站的內容,甚至根本不是Discuz的內容。這下問題搞清楚了,朋友小站遭到了搜索引擎劫持,被掛上了面向搜索引擎的隱蔽式SEO木馬,其目的是讓百度采集朋友小站,而采集內容是偽原創訂制過的,最終為了智能跳轉到攻擊者的“bo采”類網站。

 做一個簡單的驗證,把自己的火狐瀏覽器 agent 改成 Baiduspider,再次打開上述不可能存在的URL,Discuz沒有正確反饋了,被木馬接管的頁面出現了,如下圖所示:

 這時,問題就好解決了,找到掛載點,清除掉木馬代碼。具體代碼就不貼了。這段代碼大致作用就是,通過判斷agent,如果是普通瀏覽者,就什么都不做。如果是幾大搜索引擎,就在正常頁面中加入隨機生成的10條“新URL”(專指正常論壇不可能出現的,偽造的URL,下同),這些id,是有固定范圍的。而搜索引擎采集這些固定范圍的ID時,就會通過模版生成偽造的頁面,頁面內容來自幾個txt文件(是幾本網絡小說),再對其亂序和隨機組合,人眼閱讀是不通順的,但特別符合搜索引擎的胃口,這些大量的“新”內容,極大的勾起了搜索引擎的采集興趣,通過短時間的采集,搜索引擎就可能在待采集數據庫中積累大量的“新url”,有可能這些“新url"短時間不會開始正式采集,但這只是時間問題,一旦開始了,采集數據就會指數式爆發,每個“新URL”會又推薦十多個“新URL”,漸漸的,就對朋友小站形成準拒絕服務式攻擊。當然,拒絕服務不是掛馬者的目的,掛馬者是想通過百度的采集,實現對自己違規站點的推廣。而拒絕服務式的影響,可能攻擊者自己也沒想到吧。

 半年前的事情就這樣處理了,通過日志分析了下黑客的掛馬手法,初步感覺是管理員密碼泄露,沒有深究,覺得這是個偶然案例,只是建議讓朋友定期更換復雜的密碼。然后對目錄權限進行梳理,部分目錄文件甚至只給400個權限。但心中隱隱有些不安,是不是Discuz有漏洞啊?再觀察觀察吧,即使有漏洞,在400權限下也沒什么施展空間吧。這半年來,百度蜘蛛在采集頻率限制線以下,每天還進行著大量“新URL”的采集,雖然木馬早就清除掉了,這個影響卻一直存在。這里有個悖論,限制的頻率越低,采集影響時間越長,限制高了,對正常訪問有影響。于是春節期間,想著小站沒什么人,放開限制讓百度蜘蛛撒了一次歡,恩,又是近百萬。可是百度似乎一直沒意識到自己采集到的“新URL”的問題,還在不懈地堅持著。

 2023年3月爆出了百度網址劫持黑產的報道,我隱約覺得,跟朋友小站被掛馬有點相似,應該是同一個團伙干的。

---分割線---

 時間回到現在(不是指發文時間,指的是筆記時間:2023年3月,下同),這次掛馬不太一樣,被管理員撞個正著,密碼不太可能泄露了,朋友已經很頻繁地修改復雜的密碼了。從Discuz本身多找找原因吧。這套Discuz是X3.2的,隨著開發團隊的解體,官方論壇沒落了,基本上是解決不了問題,朋友的這個版本不是最新,心中一直隱隱不安,但也沒太好辦法。因為源碼經過了小作坊式深度二次開發,全面升級的成本太高,一直沒敢弄,為了驗證是Discuz漏洞,我打算把對手的攻擊手段完全模擬出來,只有這樣,才能讓朋友下定決心,再大困難也要徹底升級。

 于是我把最近幾天的日志切割出來,很快定位到掛載點,注釋掉惡意代碼,把惡意txt、php和模版改名,置權限為0000。為什么不刪除,留著樣本做研究啊。文末附錄中有按時間線整理的關鍵日志記錄,后面有整理過程中寫的小小心得,供參考。

 下面我要分析日志內容,模擬出攻擊手段來,不一定按時間線,就按思路來,有些環節有跳躍,有些細節就不帖了,免得被人利用做壞事。

 我把事發前后日志再次分割,得到一份50萬行左右的日志,根據經驗先做初步排查。

 首先暴露的是bh大馬,cat到“base64_decode”就知道了,這個目標太明顯,即使50萬行的日志,也很快定位到了它,簡單解個密,得到登錄密碼,再殺馬。日志時間點16:17:37。

 大馬放在data/sysdata下,這是個644權限目錄,看了下內容,給400應該也可以,還是疏忽被人家把馬給放上來了。data目錄不太敢把權限限制得太死,比如data/log就因為半年前控制了權限,直到這次入侵發現沒有后臺日志時才知道權限過小了。

 繼續向前找,找找這個大馬怎么放上來的。這只編碼后的大馬,占地80K,基本排除Get方式,向前追查可疑的POST操作。在追查過程中,每找到一個可疑IP,就要把它記錄下來,然后grep “IP” clip_log.txt,把所有該IP的操作復制出來,過濾出可疑操作。這時,排查分兩條線,一條邏輯線,一條IP線,然后通過時間線把整個入侵流程串起來。通過邏輯線,可以找到對手更換的IP(分析過程中也經歷了思想變化,以為對方是團隊合作),通過IP又可以找到該IP所有操作,再按時間整理出來。這樣得到的入侵細節就越來越多。真相漸漸就會浮出水面。

 向上找到最近的可疑POST來自 
/data/dzapp_haodai_config.php 日志時間點16:04:17。 這是論壇中沒裝的插件,這個文件已經不在了,大馬得手之后,毀尸滅跡。了解了一下這個插件,它可能被一句話注入,這個長達80K的內容,應該是一句話+菜刀POST進來的。這也解釋了朋友小號登錄時,在導航看到“貸款”字樣的來源,是對手安裝完插件,傳播大馬過程中,被小號無意撞見了。這個環節不需要模擬,我相信這個漏洞的存在,但讓我更關心的是,對手如何進入的后臺,畢竟插件是要管理員才能裝的。

 防守就是有天然優勢的,不需要知道攻擊者的每一個攻擊細節,在關鍵點上設置一點點障礙,對手的攻擊成本就會成百上千倍的增加。暫時不糾結細節,通過雙線排查把對手的所有操作都過濾出來,這樣關鍵入侵點自然就暴露在字里行間了。然后得到了文末附錄中的干貨。

 這不到100行的干貨日志就很容易發現問題了:

1. 時間點 15:58:43 有文件上傳,這個需要警惕,因為早期的入侵事件,論壇已經把附件上傳、頭像上傳控制的很嚴了,目錄權限也在操作系統層面做了限制,這個要好好研究,模擬出來。

2. 時間點 15:58:48 好貸插件是為了傳大馬,那這個插件(應用)是做什么的?

3. 時間點 15:56:47 這是一個很隱蔽的發現,甚至困擾了我好幾天,沒有POST,是如何登錄的?在這20多秒里,正常日志記錄了幾百行數據,每一行細細篩過,確定不是自己遺漏了什么。幸好最終將它模擬出來,不然即使升級到X3.4,仍然有被攻擊的可能,一點被破,功虧一簣。

本地復現一:繞過圖片上傳限制,上傳含有木馬的圖片

 漏洞名字就不提了,這是利用出生地檢驗漏洞,可任意刪除文件,經過本地模擬,的確成功刪除了目標文件,但刪除文件不是這個漏洞的目的(如果有install.lock在的就要小心了),對手借這個漏洞繞過了上傳限制,成功的上傳了圖片。時間點在15:58:43,到此我還是想不出這個漏洞能做什么,因為只能刪除文件還不夠,不能掛廣告的嘛。要能寫入文件才行。暫時放下。這個傳上來的圖片后面會用到。模擬后的效果如圖:

本地復現二:先不去想好貸的事,就日志而言,對手裝這個插件是為了什么,很可能是為了觸發上一步傳上來的圖片馬運行。

 通過搜索發現這是一個本地文件包含漏洞,構造巧妙的接口路徑,觸發圖片馬運行,整理心得中寫道:為所欲為,淪陷了。感覺這應該是個終點了,對方還要做什么呢?想像中的一頓POST的猛操作沒有出現,是在練兵,還是新手?也許本地windows權限沒做限制,可以當做終點,服務器上的環境更苛刻,對方沒有運行成功?也不打算到服務器上去試,想不通不想了。本地模擬效果如圖:

 思緒到這里,就有一個很明顯的問題,這兩個漏洞的組合利用,需要先決條件的。第一個條件,上傳圖片,需要一個合法帳號。這個比較容易,可以自己注冊,也可以掃一個用了弱口令的老帳號,可能有些網站注冊麻煩,他們選擇掃描。我們這位ID19的帳號,用的密碼已經反向解析出來的,是Aa123456,比較弱的密碼了,就被人家利用了。第二個條件就比較難搞,需要創始人密碼或admin密碼,要能進入后臺。我在本機模擬,是知道admin密碼,可是入侵者是如何知道,還要繼續研究一下。利用收集到的資料進行猜測,創始人密碼被盜可能性比較大。首先發現discuz的驗證碼是有漏洞的,可以輕易繞過,這樣就為窮舉破解提供了可能。模擬了一下,在構造的環境下,驗證碼可以指定為CCCC。然后出生年(1910-2010)是密碼字典的必備字段,****必然會被猜中,域名拆解也是密碼字典必備字段,xxx、yyy類似組合也會被嘗試,而疊字母、疊數字的組合也是最基本的字典,三段碰撞,總會碰出我們的創始人密碼來,換句話說,創始人密碼太弱了,經不住窮舉的折騰,而且這個密碼很可能已經泄露很多年了,因為在近一年的日志中,沒有找到對方窮舉創始人密碼的痕跡。

本地復現三:現在再回想到沒有POST就登錄后臺的怪事,漸漸的,又一個思路浮現出來。

 Ucenter、跨站、key泄露有沒有可能?這樣一想,覺得比創始人密碼被窮舉的可能性更大,因為朋友總有這樣那樣的小需求,習慣在某寶找個人給解決掉,升級也找人幫忙過,太多的雜人經手過這個系統,ukey泄漏是大概率的,而且建站后就沒改過,脫過褲也不是不可能,即使沒人從中惡意泄露ukey,歷史版本中也暴出過泄露ukey的漏洞來,只要有ukey,再在本地建個論壇。。。。果然,模擬出朋友遇到的效果了,我在不知道管理員密碼,只知道ukey的情況下,把朋友的管理員密碼改了,而且在朋友服務器上沒有登錄的POST痕跡,因為我是在本地登錄的。

 關鍵環節都弄清楚了,我用直白的語言給朋友總結了一下:

 某日15:56:23,攻擊者通過已知的ukey,改掉了管理員a密碼,并以管理員a身份登錄,此時,兩位正在管理版務,于是a被彈出。(疑似對a、b密碼做了備份,以便入侵后改回)稍后,攻擊者讀取了id小于23的人的頭像,判斷其是否存在,過程中選中了id為19的用戶,可能他的密碼是弱口令,在攻擊者的數據庫中早有記錄,也可能通過ukey,遠程修改了19的密碼,然后以19的身份登錄。15:58:27利用出生地檢測漏洞上傳了含有木馬的圖片,接著又以管理員身份添加插件激活木馬。在本機模擬過程中,15:59:12應該就是終點了,因為這時已經可以為所欲為,可是攻擊者試圖刪除些什么,離開了。很有可能是半年前的權限收縮起到了效果,這個圖片馬沒有執行權,攻擊者試圖刪除剛剛上傳的圖片馬,宣告失敗,因為沒有刪除權。16:01:31 換了IP,再次登錄,這次身份還是管理員a,通過sid可以判斷到。再次讀出頭像,定位到b,以管理員b登錄。于是b被彈出。16:02:36 這里是有post的,攻擊者是在服務器上直接登錄的。直接安裝好貸插件,在conifg中加入一句話腳本,菜刀post進來大馬。此時,小號登錄,在菜單欄看到“貸款”字樣。16:15:09 大馬進來,這次真的為所欲為了,為下次攻擊方便留好后門,就開始掛廣告,想在config_ucenter.php掛,失敗了,沒有權限。最終大馬放在了這data/sysdata/,還緊張的輸錯了三次密碼。修改function_core.php文件,加入注入點。建立cache目錄,上傳一個壓縮包。通過大馬解壓,再修改function_core.php。掛馬完畢。打掃痕跡去除插件改回管理員a密碼(怎么做的沒發現,很可能利用大馬)。2小時后回來巡視效果。

網站論壇被黑客攻擊解決方案(論壇被黑怎么解決)發稿,營銷,推廣  排名, 引流等請聯系丁不二軟文軟文推廣www.2023ruanwen.com(微信rwyx520)