2015年11月数据安全漏洞分析报告

报告核心观点

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平台未进行数据备份，一旦遭到攻击，就会直接导致用户信 息泄露，平台关门倒闭。”在当今的环境下，支撑企业发展的不单是业务，安全同样是重要的一环。

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代码自身的逻辑强度和安全强度，对于厂商要特别加强自己在身份验证处的逻辑防守能力，特别是加强用户名的命名 强度、密码和常规信息的区分度。禁止用户设置弱口令，辅助用户设置更为复杂的密码。同时也希望广大用户在享受便捷的时候对自己的个人信息负责，确实使用足 够复杂的用户名和密码以保障自身的安全。

下载完整版：《2015年10月数据安全漏洞分析报告》