網站常見安全風險 — 暴露的CMS

語言: CN / TW / HK

網站內容管理系統(CMS) 自誕生之日起,便是網站建設的一個重要領域。CMS 以其豐富多樣的功能和簡單易用的操作,有效地解決了使用者網站建設與資訊釋出中常見的問題和需求,一直深受眾多使用者的青睞。

正因如此,利用 CMS 對網站進行攻擊,也就成為黑客的常用手段之一。無需太多複雜的技術手段,只需登入網站 CMS,黑客便可方便快捷地植入暗鏈和上傳 WebShell。然而,大部分網站的安全防護策略會將 CMS 的各項功能列入白名單,或者說,來自 CMS 的操作其惡意與否通常難以辨別。

同時,部分網站的管理者貪圖方便,經常將 CMS 入口直接暴露於網站首頁。

明目張膽型的:

▲後臺入口常見位置

▲後臺入口常見位置 ▲後臺入口常見位置

也有下面這種此地無銀三百兩型的:

 User-agent: *

 Disallow: /d/
 Disallow: /e/class/
 Disallow: /e/config/
 Disallow: /e/data/
 Disallow: /e/enews/
 Disallow: /e/update/

▲某CMS系統預設的robots.txt檔案

當然,也少不了這種欲蓋彌彰型的:

▲換個名字我就不知道你是後臺了嗎? ▲換個名字我就不知道你是後臺了嗎?

對於黑客來說,暴露的後臺入口如同黑夜中的燈塔,為入侵指明瞭方向。只需一組管理員(或僅為高許可權編輯者)的賬號密碼,入侵網站伺服器便輕而易舉。若 CMS 同時存在 SQL 注入漏洞,使用者使用弱口令甚至明文儲存使用者名稱密碼,抑或驗證方式過於簡易等諸如此類的問題,只能讓黑客仰天長嘯:


天吶 !

簡直瞬間擁有武林兩大絕學

一陽指 + 獅吼功

即視感 !


不要以為這只是坊間笑談的故事,來看一個真實的事故——

案例網站的首頁醒目標明“後臺入口在此,速來”,甚至還有註冊功能(嘗試後發現並未開放註冊)。黑客的嘗試方向已相對明確——尋獲可登入的賬號密碼一組。

圖4

隨即點開一篇新聞內頁,釋出者看起來長得很像使用者名稱。

圖5

嘗試登入後,檢視錯誤提示:這個使用者使用的是弱口令,直接登入成功了!

圖6

從 CMS 來看,管理成員的許可權劃分也十分粗糙,其他高許可權使用者的資訊釋出情況一覽無餘。更可怕的是,高許可權使用者也使用了同一弱口令。

圖7

圖8

以此案例可見,暴露的 CMS 入口、顯而易見的使用者賬號、弱口令,帶來的後果不堪設想,簡直是為心懷惡意者敞開了自家大門。

然而,災難遠未就此終結……

我們可以從網站的 whois 資訊、首頁的版權資訊、友情連結以及搜尋引擎裡順藤摸瓜,找出使用相同 CMS 的網站。相同的 CMS 往往意味著相似的安全隱患,比如下面這個:

圖9

從新聞內頁來看,管理者使用了暱稱欄位,看似避免了後臺使用者名稱的洩漏,可是網站偏偏畫蛇添足,多出了個使用者資訊展示的功能,後臺使用者名稱還是暴露在外。

圖10

利用這個不知為何存在的功能,可以遍歷出後臺所有的使用者名稱。再加上 CMS 簡單的登入驗證,後臺爆破變得異常容易,剩下的只是時間問題。

圖11

從使用者[aaaaaa]是一位超級管理員這一點,就足以令人相信,這個 CMS 後臺還存在更多更嚴重的問題,網站伺服器恐怕早已千瘡百孔。

圖12

一個暴露的 CMS 不僅要抵禦各種注入,還要抗住各種暴力破解,更有社會工程學防不勝防。在現今的網際網路環境下,很難判定網站的訪問者是否懷有惡意。作為網站的管理平臺,CMS 使用者主要是網站的管理人員,如果僅為了方便,便將其暴露於網際網路之中,將會極大地增加網站的資訊保安風險,實非明智之舉。在 國務院辦公廳關於印發政府網站發展指引的通知(國發辦〔2017〕47號) 中,就明確要求“前臺釋出頁面和後臺管理系統應分別部署在不同的主機環境中,並設定嚴格的訪問控制策略,防止後臺管理系統暴露在網際網路中”。

倘若我們的網站已如文中案例,由於各種原因很難再分離 CMS 了,還有解決辦法嗎?答案是肯定的。不過,我得先去向老師們彙報網站安全問題了。

欲知後續,且聽下回再敘。(張旭 | 天存資訊)