報告核心觀點

1.千帆過盡，SQL注入仍“不改”

2.本月金融業漏洞增長尤為突出

3.11月常見數據泄露原因分析

4.解決弱口令安全建議

報告正文

2015年11月，安華每日安全資訊總結發布了126個數據泄密高危漏洞，這些漏洞分別來自烏云、補天、漏洞盒子等平臺，涉及8個行業，公司機構、互聯網、交通運輸、教育、金融、能源、運營商、政府。漏洞類型涉及，SQL注入、系統漏洞、弱口令等7類，其中SQL注入仍然是漏洞類型的重災區。

千帆過盡，SQL注入仍“不改”

數據安全問題多數是從Web端開始，SQL注入成為Web端的一個頑疾。根據統計的11月份數據安全漏洞其中56個是與SQL注入相關的漏洞，數量占總量的44%，依舊是最多被發現的漏洞類型。這些漏洞遍及公司機構、互聯網、政府等7個行業。

 

11月平臺SQL注入漏洞占主要比重

安華金和數據庫攻防實驗室統計了8月到11月，4個月間最具代表性的三種漏洞類型的變化趨勢(系統漏洞、SQL注入、弱口令)。可以看到SQL注入漏洞數量長期占據高位。

 

2015年8-11月漏洞變化趨勢

9月份系統漏洞的異軍突起是因為struts2等框架軟件被爆出一些漏洞的利用方式。至使一些未來得及更新版本的框架軟件紛紛“中槍”。其中趨勢中最耐人尋味的是弱口令的數量不減反增。弱口令應該是最容易規避，最易被修復的漏洞。但是值得注意的一點是現在的弱口令破解技術已經不是單純的密碼破解，很多以前的防護手段已經不再有效。

11月金融業漏洞增長尤為突出

從11月126個受到數據泄露漏洞威脅的行業來看，政府、互聯網、公司機構依舊是重災區，但從安華每日安全資訊統計的數量來看比例都成減少趨勢。金融業同比10月在比例上出現了大幅的增長(從10月份的7%增長到11月份的18%)11月僅安華每日安全資訊統計出的126個高危漏洞中就有23個金融業的漏洞(包含了銀行、互聯網金融、證券、保險等幾個子類)占11月漏洞總數的18%。 

 

11月數據安全漏洞行業分布情況

11月金融業被集中爆出漏洞與自身網站代碼質量有密切關系。金融行業漏洞中有13個漏洞是繞過WAF的SQL注入漏洞還存在四個弱口令漏洞和一個getshell漏洞。

由于一些SQL注入攻擊手段可以繞過waf，所以單純依靠waf防護不能達到一個理想的防護效果。例如本月的某互聯網金融主站存在的SQL注入、某銀行官網SQL注入、某市人社局網站注入等都是SQL注入繞過Waf的造成的漏洞。要想達到理想的防護效果被入侵單位或廠商就要對網站的源碼進行完善修改，從根源上杜絕SQL注入。如果無法對源碼進行修改，那就不能只單獨依靠WAF來防止SQL注入，需要通過其他軟件，例如數據庫防火墻等數據庫防護產品與WAF協同防護。

23個金融業漏洞主要問題都出在和互聯網交互的地方。其中互聯網金融的漏洞數量尤為突出，這與互聯網金融行業重業務發展輕安全有很大關系，強大的業務能力和脆弱的安全性對比顯得尤為突出。雙乾支付的COO從利波曾直言：“當下很火的P2P平臺是黑客的常駐地，因許多中小平臺網站“裸奔”，缺乏專業運維技術人員，黑客僅靠簡單的攻擊手段就可以導致其癱瘓。更有甚者，一些中小P2P平臺未進行數據備份，一旦遭到攻擊，就會直接導致用戶信息泄露，平臺關門倒閉。”在當今的環境下，支撐企業發展的不單是業務，安全同樣是重要的一環。#p#

11月常見數據泄露原因分析 

 

11月份數據泄漏威脅主要原因

本月值得關注的是弱口令漏洞占比提高。弱口令這種漏洞缺乏嚴格和準確的定義，通常被認為是很容易被別人猜到的密碼或破解工具能夠很容易破解的口令均為弱口令。本文下面提到的弱口令不只是單純的暴力破解口令和默認口令，更偏向身份驗證漏洞。總結8月到11月4個月弱口令的分布可以看到政府和金融業是弱口令的多發行業。 

 

2015年8月-11月弱口令漏洞行業分布圖

11月漏洞中金融行業弱口令有4個，占11月弱口令總數的1/3。弱口令問題在互聯網金融身上有明顯的體現，這同樣和互聯網金融忽視安全只求業務的野蠻生長有密切關系。

(1)不暴力密碼，暴力用戶

說到弱口令第一個讓人能想到的就是暴力破解密碼。這方面的工具也有很多，無論是手動還是用工具都是根據字典對某一用戶名進行密碼遍歷。目前防護這種破解方法的主要手段是采取同一個用戶名輸入多次錯誤密碼，直接對賬號進行鎖定處理。 

 

那么換個思路考慮，如果暴力破解是針對一個固定的密碼，切換不同的用戶，來遍歷適合這個密碼的用戶，無論試多少次也不會發生賬號鎖定情況。這就說明換一個思路就可以突破前臺對用戶名密碼進行暴力破解的防護機制。

這是方法是前臺邏輯無法解決的問題，原因在于賬號一直在變化，前臺邏輯無法判斷鎖哪個用戶，如果把全部用戶都鎖定雖然可以解決這個問題。但實際上會引出兩個新問題：

1.造成短時間內的DDOS攻擊(所有用戶都無法訪問服務器)。

2.對合法用戶的正常權利造成影響，用戶體驗變低。

還有一種方式是針對多次登陸失敗的ip進行鎖ip處理。但鎖ip很容易造成同一網段中的合法用戶業無法正常訪問，給合法用戶使用帶來不便，使正在運行的業務造成中斷。

針對這種暴力破解用戶名的方式，只能通過對用戶名的長度和組成元素的復雜度來加大破解難度。

(2)前臺防守邏輯過于簡單

據統計發現弱口令多發的兩個行業一個是金融行業一個是政府機關。這兩個行業往往從業人員和客戶群體普遍年紀偏大，這類人群往往喜歡用好記的密碼。還有一種情況往往在設定密碼的時候用戶名會起到提示作用，甚至有的直接就是用戶名和密碼同名。網站在防范機制上前臺應該給出相應提示禁止這種賬號的注冊并添加邏輯驗證保障用戶名或無需登陸就可查詢的信息和密碼無明顯關系，如果出現相關信息則提示用戶密碼設置不成功，建議設置更為復雜的密碼。這種明顯關系包括賬號和密碼只是互相反轉、密碼只是用戶名+某種單調符號、密碼疑似電話號碼、密碼疑似生日等易被猜測出的信息。

(3)重置密碼缺乏驗證手段

目前大多數網站都可以通過一些注冊信息重置密碼，但是其中有一些網站在重置密碼的過程中缺乏足夠的驗證手段，這就給攻擊者留下了入侵手段。

目前重置密碼主要通過兩種方式驗證，一種是需要郵箱的特殊鏈接，一種是短信驗證。下面是一個修改包中郵箱名重置任意賬號密碼的案例：

首先在目標網站上注冊一個用戶，然后進行密碼重置，郵箱收到一封郵件，郵件中有一個特殊鏈接，打開這個特殊鏈接提示輸入新密碼，輸入新密碼后，點擊提交，這時如果攔截下提交的數據包，然后把圖中的郵箱改成你想重置密碼的賬號對應的郵箱，這時重置目標郵箱的密碼成功。

加強一些邏輯防守就可以杜絕這種通過本地代理改包的入侵方式。一般有兩種方式：

1.在客戶端提出重置密碼后，把該用戶密碼所存的表中加入一個狀態，該狀態表示這個賬號提出重置密碼請求。修改密碼的請求傳入到服務器，在確認重置密碼前，判斷是否與提交重置密碼的賬戶一致，如果不一致則不重置密碼，一致則信任該操作重置密碼。

2.給核心字符串加唯一標識例如

把email=xxxxx.com&newpassword=xxx&repassword=xxx

改成email=xxxxx.com&newpassword=xxx&repassword=xxx&key=xxxx

只要保證key的安全、唯一、機密性，則可以保障不被這種方式入侵。

同樣手機驗證碼也有類似的情況，但需要手機驗證碼和重置密碼之間是異步。這種情況一般在成熟的網站中并不常見。

解決弱口令建議

解決弱口令的關鍵之道在于用戶名和密碼的復雜度和程序邏輯沒有安全缺陷。用戶名和密碼的復雜程度需要用戶愿意為了自己的個人的信息安全做更多的努力和付出，這其中系統的開發者也需要在驗證過程中設定更加嚴格的用戶名和密碼輸入驗證，使簡單的用戶名和密碼無法注冊成功，例如輸入相同的用戶名和密碼，提示密碼太簡單要求客戶重新輸入等措施。

針對安全邏輯缺陷，開發者應該加強所有和密碼賬號相關功能的邏輯安全。例如例子中的密碼重置功能，需要加入更復雜完善的安全校驗來保障確實是目標用戶在對該功能進行操作，防止不法分子利用代碼邏輯缺陷對系統展開入侵。這種由于代碼邏輯錯誤、缺失造成的安全問題，很難通過第三方軟件來輔助規避。

弱口令雖然是一種技術含量不太高的入侵方式，但弱口令一般涉及用戶或者系統的核心數據和安全。一旦用戶口令被攻破，則一切防護手段都形同虛設。要加強針對弱口令的防護首要是加強WEB代碼自身的邏輯強度和安全強度，對于廠商要特別加強自己在身份驗證處的邏輯防守能力，特別是加強用戶名的命名強度、密碼和常規信息的區分度。禁止用戶設置弱口令，輔助用戶設置更為復雜的密碼。同時也希望廣大用戶在享受便捷的時候對自己的個人信息負責，確實使用足夠復雜的用戶名和密碼以保障自身的安全。

完整報告下載：http://www.dbsec.cn/service/pdf/20151215.pdf