---

每一次重要通用漏洞的爆发总是会带来一片腥风血雨，任何微小的漏洞，基于 43 亿 IPv4 地址这个大基数，总是可以被放大！

从 MongoDB 开始到 MySQL，黑客瞄准了数据库服务，通过黑客手段获取数据库服务的权限，然后删除数据，在数据库中插入勒索信息，要求支付比特币以赎回数据（可见扩展阅读）。那么黑客是如何实现这整个过程？

MongoDB勒索事件

在 MongoDB 的勒索事件里，黑客攻击通过攻击存在未授权访问问题的 MongoDB 数据库，加密原数据内容，在数据库中插入勒索信息，要求支付比特币以赎回数据。（具体可见雷锋网的报道 http://www.leiphone.com/news/201701/KSgCEbXUCMHU6Tys.html）

大概是这样一个流程，通过探测互联网上符合的目标，然后使用对应的攻击脚本针对探测得到的目标实现自动化的攻击。

而细化到具体的探测目标和 Exp 的功能，以 MongoDB 数据勒索这个例子，探测目标主要是探测互联网上开放了 27017 端口的目标，然后进一步探测是否可以未授权直接连接目标：

就 MongoDB 这个例子，主要是利用了 MongoDB 未授权访问的这个问题； MongoDB 默认安装是没有密码的，并且没有绑定 IP，导致的问题就是外网可以访问这些 MongoDB，并且由于无需授权，就可以直接未授权访问。

其实，这是一个自动漏洞批量利用的过程，不仅限于数据勒索，也不仅限于开始列的几种数据服务的未授权访问或者弱口令等安全问题，同样其他漏洞也是可以的。

黑客如何利用漏洞

往往一些漏洞在爆发之后，没多久就马上会爆发出漏洞的PoC和Exp，比如最近的Struts2新漏洞S2-045（CVE- 2017-5638），漏洞在3月6日爆出，而在3月7日也就是第二天，PoC和Exp已经满天飞，就本次的漏洞来说，基本国内外大的互联网公司基本没有 不受影响的；该漏洞可以导致命令执行，可以获得系统权限，在PoC和Exp出现的第一时间，已经基本是地上地下都在利用和扫描了。

上面是这次S2-045的PoC，通过这些攻击脚本，黑客可以实现自动化的对漏洞进行利用

15 年 11 月也出现过一个安全事件，就是有黑客团体利用 Redis 设计缺陷成功入侵了至少 10000 家的 Redis 服务器（具体见 nosec 的报告

http://static.nosec.org/download/redis_crackit_v1.1.pdf）。在这个事件里，黑客基于 Redis 未授权访问问题，通过配合 SSH Key 的技巧批量的入侵了 Redis 服务器。

上面的视频是通过手动的方式演示了如何利用这个问题获取服务器的系统权限，而往往这个过程黑客是通过自动化的手段进行的，下面是的视频演示了如何通过工具自动化的获取攻击目标，利用 PoC 进行验证是否存在 Redis 未授权访问问题的。

其实每一次爆发的漏洞对于相关黑客来说，利用的过程不外乎如此；还有个例子，之前国外有个团队，捕获了一个使用 ElasticSearch 漏洞构建的僵尸网络，利用 ElasticSearch 的漏洞，对 ElasticSearch 服务器进行控制，整个僵尸网络最终可以用来进行DDOS攻击（分析报告https://www.recordedfuture.com/elasticzombie-botnet-analysis/）。

经过跟踪 ElasticSearch 公开的漏洞，他们发现，尤其在中国的相关论坛， CVE-2015-1427 被多次讨论和引用，这是一个 ElasticSearch Groovy 脚本引擎的漏洞导致攻击者可绕过沙箱检查执行 shell 命令的命令执行漏洞。

这是个影响 ElasticSearch 1.3.0-1.3.7 以及 1.4.0 到 1.4.2 的漏洞，相关的 PoC 也就是漏洞验证代码以及 Exp 都已经在网上公开，黑客可以利用这个漏洞，执行 Shell 命令，通过 perl 执行一个 perl 脚本，来进行反弹 shell，可以达到对服务器的控制。

什么是反弹shell呢？正常我们通过ssh连接linux等服务器，是主动的方式连接，而反弹shell，shell其实跟我们通过ssh连接的 shell没什么大的区别，而反弹的意思是，控制端通过一些软件，比如nc，也就是netcat在控制端监听某个端口，被控制端，比如说linux 服务器，发起请求到该端口，并将其命令行的输入输出转到控制端。

我们通过一个视频来看下如何利用这个漏洞进行反弹shell来控制服务器的：

而其实黑客如何利用这个漏洞组建僵尸网络，也只是将这个利用过程自动化，批量化。

看到这我不知道大家是否可以发现，例子中黑客使用的漏洞都不是 0DAY 或者1 DAY ，应该算是 NDAY （这里的数字指距离漏洞爆发已过去的时间）； 其实，正如你所见，可能大家平时更多的觉得是0DAY的危害很大，但实际的情况是，0DAY更多的时候是作为一种最后的手段，并不是随手就能有 0DAY， 大部分的这种批量的攻击场景基本是 NDAY，每次漏洞爆发，都有一大堆目标受影响，但这些受影响的目标，最终又有多少修复了漏洞，这就得另说了；实际的情况就是即使漏洞爆发过去很长时间，甚至一两年的时间也仍有众多的目标受影响，比如14年爆发出来的心脏出血漏洞，15 年仍有众多目标受影响（https://zhuanlan.zhihu.com/p/19722474），甚至包括一些安全厂商的设备和知名互联网公司的服务器，甚至于现在去做检测，也仍有存在漏洞的目标。

漏洞的利用与修复一直都是安全对抗中一个主要的工作内容！

如何获取攻击目标

在上面的内容我们介绍了很多黑客攻击流程和黑客对漏洞的利用，但是似乎唯独漏了黑客是哪里得到这些攻击目标的。其实在一开始的 MongoDB 的说明中已经大概提到了。

每一次重要通用漏洞的爆发总是会带来一片腥风血雨，任何微小的漏洞，基于 43 亿 IPv4 地址这个大基数，总是可以被放大！

不知道大家有没有注意到引言的这段话，黑客的攻击其实都是基于 43 亿的 IPv4 而进行的，一个再小的漏洞，基于这个基数，那么得到的可攻击目标就不是一个小数。

最简单粗暴的方式，就是拿着攻击脚本通过分布式、自动化的方式全部攻击一遍，当然这个量就有点大，所以更合理的方式是探测符合的目标，比如 MongoDB 那个事件，需要探测存在 MongoDB 的服务器，也就是探测端口 27017 开放的服务器（MongoDB 服务默认端口为 27017 ，一般情况 28017 等情况也有可能，所以黑客在尝试的时候可能不止探测 27017 这个端口），然后进一步的探测是否符合漏洞利用条件，就 MongoDB 的例子也就是需要是存在未授权访问的情况，即不需要密码并且可远程连接。

类似 MongoDB 的端口 27017 其实就是指纹，黑客通过这些指纹去探测存在漏洞影响组件的服务器，不同的组件和服务都有不同的指纹，比如同样是通过端口的方式，那么 Redis 也就是 6379，M 有 SQL 是 3306，还有比如说" WWW-Authenticate: Basic realm="TD-8817 "这个存在于HTTP头部的指纹可以探测 TP-Link TD-8817 路由器；当然，不排除自定义的情况，但出于成本等方面的，一般黑客在攻击的时候选择忽略特殊的情况。通过探测出符合漏洞影响组件的目标后，这些目标就成为攻击脚本执行的目标。

除了指纹探测服务或者组件的存在与否，也可以进一步探测安装的组件的版本是否在漏洞影响的版本范围内，以此来缩小最终要使用攻击脚本进行攻击的目标范围。精确的指纹和版本信息，可以缩小需要攻击的目标范围，从而减少攻击成本。

其实，通过指纹的方式对于相关目标进行服务和组件的探测，国内外已经有一些安全平台，比如 ZoomEye（https://www.zoomeye.org）、撒旦（https://www.shodan.io/ ，如下图搜索 MySQL 服务的目标）等，大家如果想尝试，可以直接访问去搜索相关组件的目标，比如"app:wordpress" 在 ZoomEye 上搜索 Wordpress 搭建的站点；在Redis那个未授权访问问题的自动化演示的视频中，其实就是调用了 ZoomEye 的 API 来获取存在 Redis 服务的目标。

当然，看到这些平台，你可能第一时间想到的是帮助了攻击者，这个具体怎么看待把，因为这些平台的初衷肯定不是如此，就像早期的电脑到底是好是坏的讨论一样；在相关黑客的手里其实也存在这样的平台，或者就是通过脚本直接根据不同的漏洞对 43 亿 IPv4 或者其他已知目标列表进行探测，然后自动化的攻击。

讲到最后，其实大家可以发现，不仅仅是数据勒索，这其实更多的是一种通用的漏洞自动化攻击利用的流程，唯一的区别在不同的漏洞能够获取的权限不同，对应的在获取到权限后能做的事也不同，所以就存在对应的利用，比如数据勒索，比如组件僵尸网络用于 DDoS，比如用来挖矿，还比如批量黑了路由器进行 DNS 劫持等。

在企业的安全风险的不同维度里，通用漏洞一直是个棘手的问题，因为你没法事先知道问题，只能在漏洞爆发的时候第一时间去修复漏洞，所以，尽可能的选择一些靠谱的组件，多关注安全，加强漏洞和安全的应急响应，避免由此导致的安全风险！