【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014,关注中国数据库技术大会公众号）现场演讲嘉宾邓焕老师分享内容整理而成。录音整理及文字编辑IT168@田晓旭，@老鱼。

　　嘉宾介绍：

▲白帽汇联合创始人&安全负责人 邓焕

　　邓焕，前360安全研究员，现白帽汇联合创始人&安全负责人目前主要负责安全研究，威胁分析等。

　　正文：

　　今天我给大家分享的议题是大数据下的攻防，首先自我介绍一下，我之前就职于360，一直从事网站方面的安全研究，离开360后，成立一家新公司，叫白帽汇。白帽汇主要是从事威胁情报和大数据安全，给企业提供尖端的安全技术服务，确保企业不被入侵、不被脱库。

　　今天我主要是以一个攻击者的角度来分享网络攻防技术，讲述在这种环境下攻击者是如何利用数据库特性和环境进行网络渗透的。

　　首先我要讲的是NoSQL的安全问题，提到大数据大家就会自然而然的想到NoSQL，它已经成为大数据环境必不可以的一部分。下面我们来看一下有哪些主流的NoSQL数据库。首当其冲的就是列式数据库，它的代表有HBase和Cassandra，其次是文档数据库，主要有MongoDB和CouchDB，第三是键值型数据库，包括Riak和Redis，还有图数据库如Neo4j和DEX。

　　我们主要是针对这些比较常用的数据库，来看一下攻击者是如何利用数据库特性来进行攻防的。首先我们思考一下，作为运维人员，我们为什么需要去关注这样的安全问题。

　　上图是一个国外网站，它在安全圈是比较知名的一个网站，它是一个网络空间搜索引擎，可以根据特定的信息进行搜索。假设我们现在针对网络中的信息进行搜集，我们查一下有哪些服务器在开放着6379端口，根据搜索结果我们发现全球大概有三万多台服务器的这个端口是对外开放的。

　　我们看一下NoSQL数据库存在哪些威胁安全的因素。

　　1.安全性比较差，传统关系型数据库在默认的条件情况下的安全措施要比NoSQL数据库做的更加完善，比如说MongoDB在默认情况下可能是对全网进行监听，但是传统关系型数据库，像Oracle、MySQL，PostgreSQL这样的在默认情况下是不会对全网进行开放的，只监听本地端口，并且默认提供某种形式的授权。

　　2.NoSQL数据库默认的情况下缺失部分身份验证的信息，甚至有些根本不存在验证。

　　3.在传输层中可能会直接使用明文传输，可以通过中间人攻击得到数据。

　　4.传统关系型数据库有SQL注入，其实在NoSQL的数据环境下也存在同样的现象，我们称之为NoSQL 注入。

　　5.NoSQL数据库部署需要一个可信赖的环境，直接把安全属性丢给运维人员，由他们来解决相应的问题，不允许外部进行访问。

　　MongoDB

　　下面我们先从MongoDB来给大家介绍，MongoDB现在是最流行的数据库之一，默认的服务端口是27017，同时开放了28017作为Web接口。

　　下面列举了一些MongoDB的安全问题。

　　0day代表是指厂商未发布修复补丁的漏洞，而Nday指的是官方公开了这个漏洞并且发布了补丁，但是还没有来得及进行全网推送，各大厂商都还没有进行修复。这时就很容易被网上的黑客利用，利用网上公开的漏洞细节进行全网扫描，达到入侵的目的。MongoDB有几个比较知名的、比较高危的漏洞，利用这些漏洞能直接获取到服务器的权限，

　　其次因为MongoDB支持JavaScript脚本，所以在MongoDB中很重要的安全问题是来自JavaScript的注入，通过直接执行JavaScript能够达到黑客所要想实现的目的。

　　最后一个安全问题是MongoDB的公网开放，同时这也是现在MongoDB存在的最大的安全问题。在正常情况下，它的交互是允许客户端直接访问的。

　　攻击者是怎么样利用这个场景进行攻击的呢?一般他们会选择在传输层进行攻击，因为MongoDB的早期版本中是没有ssl加密的，一直是明文传输的，直到2.6以后的版本才支持ssl传输层加密。黑客会进行中间人攻击，去嗅探和获取数据库的一些定点信息，甚至可能会注入JavaScript代码去达到某种目的，比如执行拒绝服务操作来耗死服务进程。

　　这是去年网络搜索引擎Shodan公开的一份关于MongoDB全球对外开放未授权访问的报告，从图中我们可以看到，2.4.9版本MongoDB服务器将近有三千台是对外开放的。

　　在搜索引擎上搜索一下，我们会发现国内也有很多企业存在未授权访问的现象。

　　我们直接在Shodan上对27017端口进行搜索，上图是我们上周搜索得到的结果，到现在为止全球还有四万多台MongoDB是在对外进行开放的，右边的每个数据库都包含着1GB以上的数据，它们都可以直接连接来获取数据。

　　报告显示，全球未受权访问MongoDB的数据量已经达到了五百多TB的级别。

　　既然MongoDB未授权访问在互联网中出现的安全问题这么普遍，那为什么还有这么多服务器在对外直接开放或者没设置验证权限呢?

　　其实MongoDB直到2.6版本以后才有了对默认配置进行修改的功能，不再是默认监听0.0.0.0，而是直接去监听本地ip地址。这也是为什么之前版本的安全性不高，而2.6版本之后安全性提高了很多。

　　这是针对MongoDB服务厂商进行的一个统计，我们发现阿里云也在前十。如果在这种情况下部署云出现问题的概率更大，因为云环境本来就是对公网进行开放。

　　MongoDB默认的Web接口是28017，它能直接通过Web接口去执行一些命令的，通过该路径去传输JavaScript代码，最终传输到MongoDB的服务端进行执行。

　　攻击者一般也可能会利用这个接口去做欺骗，把代码嵌入到页面里面去，当你访问这个页面的时候，同时被执行了另外一个操作。比如说攻击者可能会把代码加到第三方或者公共的页面，当运维人访问这个页面的时候，也可能去执行了他想要达到的某种目的，这个有一个专业的名词叫CSRF，客户端请求伪造。这样的话可以绕过网络边界，首先他没有接触到你的MongoDB，但是他嵌入页面里的代码可能会欺骗你去访问内网。

　　MongoDB的NoSQL注入问题也是比较常见的问题，MongoDB和很多网站都在进行交互。假设这里有一个直接登陆的页面，可以通过注入SQL语句，让它在闭合前能够暴露出一些我想要得到的数据。另外，我们还可以执行一些循环语句，把服务器资源耗尽。攻击者的一般思路是用一台服务器结合前面的CSRF，借用一个第三方页面，当你访问的时候去请求你的内网地址，导致你的MongoDB被服务耗死。

　　CouchDB

　　CouchDB和MongoDB不同的地方是它的操作更依赖于HTTP服务，它默认的开放端口是5984，但是它在安全性方面做的比较好的是绑定了本地IP，外网是不允许访问的，但是它在公网还是未进行安全验证。

　　正常情况下CouchDB的运行是如图所示的，管理者能直接通过的漏洞管理界面去进行一个数据管理，然后通过REST API对用户端进行支持。

　　作为一个攻击者，他会对传输层进行一个中间入侵，因为CouchDB传输的时候会和HTTP服务进行交互，而且默认情况下它是支持RESTful 的，所以说，利用这一点进行中间攻击是可以抓到关键信息的。

　　这些是CouchDB现在面临的比较主流安全问题。

　　CouchDB的1.5以下的版本存在拒绝服务功能。我们通过Shodan网站对5984端口进行了搜索，发现他的这个服务是开放的，可以直接连接。

　　SSRF(服务端请求伪造)实际上是CouchDB的正常功能，它在部属数据库的时候，可以指向远端数据库，同时进行一个远程复制的动作。攻击者他能够利用这一条进行攻击，比如把地址指向内网的IP地址或者是任何想要探测的一个网段，输入进去后我们会发现它会主动的请求这个例子。上图是我对10.10.10.63进行的一个测试，我们看到它确实访问了这个IP，并且进行了请求。

　　我们利用curl发一个包出去，首先指向的是一个内网存在的地址，我们可以看到，它只是一个WEb服务，能够访问但是不存在数据库。后面我们又定义了一个例子，去请求内网不存在的IP地址，它直接就抛出timeout。利用这个特性，攻击者可以去探测内网中Web服务的开放情况，而且可以再去进行更深入的渗透测试。

　　Redis

　　Redis是一个键值存储系统，现在有很多网站在使用它做存储，支持的数据格式也比较多样，Redis 2.8之后的版本增加了对LUA脚本的支持，默认端口是6379。

　　攻击者一般会采取下列几种方式进行数据入侵。

　　文件枚举，Redis是支持跨脚本的，所以一般攻击者会先是扫描你的服务器然后利用这个服务去进行一个文件探测。因为它支持lua脚本，我们输入dofile命令，就能探测你的服务器是否存在这样的功能或者文件，比如我在这里输入一个命令去探测www目录，我们看到反馈的信息是目录存在，但是文件不能打开的，这也就是意味着这个目录是存在的。我们再采用同样的方式探测一个不存在的目录，然后我们看到它会反馈不存在该目录。利用这个特性，攻击者可以了解网站的文件处理以及文件目录的大体的情况。

　　其次是Redis拒绝服务的操作，因为Redis支持lua脚本，所以为了防止某个脚本执行时间过长导致Redis无法提供服务(比如陷入死循环)，Redis提供了lua-time-limit参数限制脚本的最长运行时间，默认为5秒钟。

　　另一个比较严重的问题就是Redis任意文件写入。

　　去年我们公司在互联网上发现了一起对Redis全网攻击的事件。去年十一月，我们发现了所有互联网公开的Redis服务器上都被植入了一个特定的key，也就是说如果当时你的服务器是默认权限设置并且对外开放，那么你的Redis数据很可能就会丢失。

　　我们对这次入侵事件进行了还原。

　　首先可能是利用ssh登陆认证的证书信息，在登陆集群上会生成证书，然后把信息重新下到文本里，利用Redis客户端进行远程连接，连接好后攻击者会清空所有数据。之后他会set key，登陆到Redis服务器，设定一个指定的目录，利用Root用户指向一个特定的文件名，保存数据，生成文件。这样，攻击者就成功的绕过了Redis登陆机制，可以利用本地私钥直接进行远程登陆。

　　我们后续对抽样的15万台对公网开放的Redis服务器进行了全网扫描，结果发现有10%的服务器是可以直接连接入侵，67%的服务器已有入侵痕迹，它们都被植入了一个特定的key。我们对这些厂商进行了统计，发现其中还有很多业内知名的厂商，例如味多美、魅族、蚂蚁花呗等等，才具体的更多细节大家可以去我们的官网下载报告。

　　ElasticSearch

　　下面介绍一下ElasticSearch，很多企业在建立搜索引擎或建立大数据检索的时候都会用到它。

　　ElasticSearch的开发语言是Java，默认也是直接对全网进行开放，所以只要你部署在官网上，大家都可以访问到你。默认开放的Web端口是9200-9300端口。

　　未授权访问是ElasticSearch目前存在的比较大的问题，最近两年ElasticSearch被报出了很多漏洞，而且都还是重量级的漏洞，能直接远程执行命令，获取系统权限。

　　我们同样使用Shodan对ElasticSearch的默认Web端口进行搜索，查看ElasticSearch的对外开放情况。根据搜索结果，我们可以看到目前中国还有一千多台服务器是直接对外开放的。我们随机挑选几个进行连接，发现不仅能够成功连接，同时还可以对数据进行相应操作。

　　下面来介绍一下ElasticSearch近一两年内被爆出来的一些致命的漏洞。首先是当时最严重的未授权访问，能直接秉承命令执行，攻击者只要输入一些特定的字符，就可以定制服务，更有甚者，还可以控制服务器的所有权限。

　　ElasticSearch被爆出的漏洞中另一个比较著名的就是任意文件读取。当程序启用site插件时，远程攻击者可利用该漏洞读取任意文件。一般来说，黑客都会读取比较敏感的文件，例如配置文件，然后利用这个信息去进行更深一步的渗透测试。

　　大数据的环境下有很多新型的应用被开发出来，但是国内关注新应用安全的人并不是很多，而有很多技术在国外已经公开了，很多攻击者也在利用这些技术。另外，我们还要实时关注新型数据库，国内更多的是偏向于关系型数据库的攻击，但是随着大数据的发展，新的数据库安全必将被提上日程。在这里也呼吁大家要关注大数据环境下的数据安全。

　　我们还应该注意哪些问题呢?利用0day去攻击企业的成本是很高的，因为该漏洞会被公开，攻击者利用该漏洞去攻击，很有可能会吃官司，所以这类攻击在APP中更常见。现实生活中攻击者更多的是利用Nday进行全网扫描或者是利用这些信息进行破坏，所以我们呼吁更多的运维人及时修复报出的漏洞;其次是安全存储的问题;第三是强大的认证，归根结底很多NoSQL都是对全网开放，如果没有很强大的认证信息，那么任何人都可以访问它;最后，更好是把NoSQL数据库隔离在内网，建立一个可信赖的连接，而不是把它丢在公网上，允许任何人去访问。