数千台MySQL数据库遭黑客比特币勒索,该怎么破? 运维派

by admin on 2020年4月22日

该文转自微信公众号“北京白帽汇科技有限公司”,作者为“安全实验室”,原文标题为《 威胁情报预警:Elasticsearch勒索事件 》,雷锋网已获授权。

目录:

据内部数据中心安全的行业领导者GuardiCore公司爆料,数千台MySQL数据库遭到勒索。这是近半年内,不断频发的数据库勒索事件的延续:

2017年1月12日,白帽汇监测到针对全球使用广泛的全文索引引擎Elasticsearch的勒索事件,经过多日的跟进分析,直至2017年1月17日,共有3波勒索者,根据白帽汇FOFA系统对删除之前数据与被删除数据进行对比分析,此次攻击被删除的数据至少500亿条,被删除数据至少450TB。在勒索事件发生后,有1%的Elasticsearch启用了验证插件,另外有2%则关闭了Elasticsearch。

国内Oracle数据库遭“恶作剧”比特币勒索;2017年1月11日报道3.3万台Mongo数据库实例被勒索,有些数据库直接被删除,国内受害者众多;2017年1月13日报道3.5万个ElasticSearch
CCluster被勒索,被删除数据大小至少450TB;2017年1月19日报道1万+台Hadoop和CouchDB被勒索;2017年2月24日报道数千台MySQL数据库被勒索。

澳门新葡亰平台官网 1

ES安全事件回顾

根据GuardiCore研究人员,针对MySQL的一系列攻击最早可以追溯到2月12日。所有的追踪都归因到一个IP地址,属于荷兰的网站托管公司Worldstream(109.236.88.20)。

【注:以上比特币价格按照事发当日比特币价格换算】


攻击者们通过一些黑客工具在网上搜索那些安全措施做得比较差的数据库服务器,暴力破解,然后删除数据、或者腾挪掉数据,并创建一个PLEASE_READ用户和WARNING表,在表里放上一小段信息。

事件回顾

2017年1月12日上午10时

白帽汇发现第一波勒索者,分析统计,发现共有10264台服务器已经遭受攻击,并且还一直持续增长。

攻击者会删除Elasticsearch所有索引信息,并创建一个名为warning的索引,勒索者写入需要支付0.2比特币才给受害者发送数据(目前按照比特币市场价格,约等于150美元),并留下邮箱地址p1l4t0s@sigaint.org。该邮箱域与Mongodb勒索的作者使用的是同一个域,id不同.据了解,此前Mongodb勒索攻击者其实并未备份数据,而是直接删除,而目前确认Elasticsearch也是一样,并未对数据进行备份,而是直接删除全部。

澳门新葡亰平台官网 2

2017年1月14日中午12时

白帽汇发现第二波勒索者,创建一个名为please_read名字的索引。攻击者留下类似的文字,该勒索信息显示需要支付0.5BTC(按照当天比特币市场价格,约等于400美元)。邮箱elasticsearch@mail2tor.com。

澳门新葡亰平台官网 3

2017年1月16日中午12时

白帽汇发现第三波勒索者,其创建的索引为pleasereadthis.使用的邮箱地址为4rc0s@sigaint.org。

澳门新葡亰平台官网 4

  • 下面是白帽汇监测到针对全球使用广泛的全文索引引擎Elasticsearch的勒索事件:
  • 2017年1月12日上午10时,白帽汇发现第一波勒索者,分析统计,发现共有10264台服务器已经遭受攻击,并且还一直持续增长,
    攻击者会删除Elasticsearch所有索引信息,并创建一个名为warning的索引,勒索者写入需要支付0.2比特币才给受害者发送数据(目前按照比特币市场价格,约等于150美元),并留下邮箱地址p1l4t0s@sigaint.org.
    该邮箱域与Mongodb勒索的作者使用的是同一个域,但id不同。据了解,此前Mongodb勒索攻击者其实并未备份数据,而是直接删除,而目前确认Elasticsearch也是一样,并未对数据进行备份,而是直接删除。不幸的是,我们ES测试集群的数据也被干掉了:(
  • 2017年1月14日中午12时,白帽汇发现第二波勒索者,创建一个名为please_read名字的索引。攻击者留下类似的文字,该勒索信息显示需要支付0.5比特币(按照当天比特币市场价格,约等于400美元)。邮箱elasticsearch@mail2tor.com
  • 2017年1月16日中午12时,白帽汇发现第三波勒索者,其创建的索引为pleasereadthis.使用的邮箱地址为4rc0s@sigaint.org
  • 影响范围:截止2017年1月17日,白帽汇通过FOFA系统中的68000余个Elasticsearch进行统计分析,发现目前全球共有9750台存在勒索信息。其中此次被删除的数据达到至少500亿条,被删除数据大小至少450TB。通过两次勒索情况的对比分析,发现有大概1%的Elasticsearch使用了验证插件,另外有2%则关闭Elasticsearch,现在已经无法访问。
  • 白帽汇FOFA系统中显示,互联网上公开可访问的Elasticsearch超过68000余台。其中,共有受害总数9750台,
    目前全球中受影响最多的为美国4380台,其次是中国第二944台。法国787台,爱尔兰462台,新加坡418台。
  • es集群会收到的攻击通常包含:1、通过es暴露的公网端口进行攻击 
    2、通过主机服务器进行攻击 
    3、与ES配合的其它产品,如Logstash,Kibana
  • 综上所述:2017.1.12号开始全球ES变攻击,巧合的是1.14号ES发布5.2.1,
    日…….
  • 澳门新葡亰平台官网 5

信息大概是这个样子,你可以检查下你的数据库或者日志中是否含有下面这样的信息。

影响范围

截止2017年1月17日,白帽汇通过FOFA系统中的68000余个Elasticsearch进行统计分析,发现目前全球共有9750台存在勒索信息。其中此次被删除的数据达到至少500亿条,被删除数据大小至少450TB。通过两次勒索情况的对比分析,发现有大概1%的Elasticsearch使用了验证插件,另外有2%则关闭Elasticsearch,现在已经无法访问。

澳门新葡亰平台官网 6

白帽汇FOFA系统中显示,互联网上公开可访问的Elasticsearch超过68000余台。其中,共有受害总数9750台。

目前全球中受影响最多的为美国4380台,其次是中国第二944台。法国787台,爱尔兰462台,新加坡418台。以下是Elasticsearch勒索全球分布范围:

澳门新葡亰平台官网 7

【Elasticsearch受勒索影响全球分布】

其中,中国受害的有944台。其中,浙江省受影响最严中,有498台,其次是北京,186台,上海52台,湖南43台,上海42台。

澳门新葡亰平台官网 8

ES集群安全建议

然后他们要数据库所有者支付0.2个比特币(价值200美元),这样数据库所有者就能访问数据了。上述所有勒索事件,虽然不是同一拨人发起,但基本都是这么个套路。

【Elasticsearch中国地区受害影响范围】


下面这个网站是接受付款的网站,竟然已经做到了如此高调。

安全建议

Elasticsearch方便,实用的同时,也引入了安全隐患和数据泄露的风险。

那么如何加强安全防范呢,这里给大家如下安全建议:

1、 增加验证,官方推荐并且经过认证的是shield插件,该项目为收费项目,可以试用30天。网络中也有免费的插件,可以使用elasticsearch-http-basic,searchguard插件。

Shield 可以通过bin/plugin install
[github-name]/[repo-name] 形式安装。

2、 使用Nginx搭建反向代理,通过配置Nginx实现对Elasticsearch的认证。

3、 如果是单台部署的Elasticsearch,9200端口不要对外开放。

4、 使用1.7.1以上的版本。在1.7.1以上版本目前还没有爆出过相关漏洞。

5、 另外elasticsearch的官方也有其他产品与Elasticsearch配合紧密的,这些产品也存在漏洞,企业如果有使用其他相关产品存在漏洞也要进行修复,如Logstash,Kibana。

6、 加强服务器安全,安装防病毒软件,使用防火墙,网站安装WAF.并对数据库,系统,后台,使用的服务设置复杂的密码,建议设置16位的大小写字母+特殊字符+数字组合。

  • network监听地址(network.host)改为内网IP
  • 修改默认访问端口 , 【http.port: 9200
    (设置对外服务的http端口,默认为9200),transport.tcp.port: 9300
    (设置节点间交互的tcp端口,默认是9300)】
  • 澳门新葡亰平台官网 9
  • es集群放到专有网络,限制外网访问
  • 禁用http (http.enabled : false),
    【http.enabled:是否使用http协议对外提供服务,默认为true,开启】,kibana通过rest访问es进行数据展示,禁用此配置相当于停止rest访问,因此根据实际情况进行处理
  • 增加访问验证,5.0以前版本官方推荐并且经过认证的是shield插件,该项目为收费项目,可以试用30天。网络中也有免费的插件,可以使用elasticsearch-http-basic,searchguard插件。5.0+版本对原本的watch,alert做了一个封装,形成了x-pack

安全研究人员Victor
Gevers呼吁,不要支付,千万不要支付,因为那些数据很可能黑客压根就没有给你备份。

相关链接

全球Elasticsearch分布:https://fofa.so

稿源:雷锋网

安全访问配置

为什么会遭遇比特币勒索?一方面被攻击者安全意识薄弱,没有做好必要的安全防范,有的甚至基本就是裸奔。不要笑,早些年,很多大医院的Oracle数据库,用system/oracle是可以直接登录的。另一方面,利用了产品的漏洞,大家所熟知的SQL注入就是其中一种。虽然目前比特币勒索案例的数据库,都是疏于安全意识给了黑客可乘之机,但接二连三连环得手,也从另一个侧面说明数据库安全教育任重而道远。


安利一下,邹德裕同学主导研发的DPM已经可以检测Oracle和MySQL的比特币漏洞了。当然,安全攻防永远在不断升级,牛掰的产品厉害也在于不断迭代升级。

  • x-pack是elasticsearch的一个扩展包,将安全,警告,监视,图形和报告功能捆绑在一个易于安装的软件包中,虽然x-pack被设计为一个无缝的工作,但是可轻松的启用或者关闭一些功能
  • 修改elasticsearch.yml 配置文件,设置:
    xpack.security.enabled:
    true
  • 修改kibana.yml配置文件,设置:
    xpack.security.enabled:
    true
  • 同时设置kibana访问ES集群的用户名和密码(x-pack安装之后有一个超级用户elastic ,其默认的密码是changeme,拥有对所有索引和数据的控制权,可以使用该用户创建和修改其他用户),如下:
  • 澳门新葡亰平台官网 10 
  • 重启ES、kibana服务,访问ES时会让你输入密码,如下图:
  • 澳门新葡亰平台官网 11
  • 同样,在登陆kibana时,也会提示用户和密码信息,如下图:
  • 澳门新葡亰平台官网 12
  • 可以通过kibana的web界面进行用户和用户组的管理,如下创建新用户等
  • 澳门新葡亰平台官网 13

针对MySQL这个问题,我们从密码策略设置方面入手,来总结下数据库安全的一些细则。

license更新

MySQL中的密码安全策略


1、
其实在我们日常工作中,如果使用了明文密码,MySQL也会给出提示,而且在早期版本是可以直接查mysql.user得到加密后的密码的。

  • 安装完成后,默认情况下,x-pack插件license有效期为一个月,通过如下命令:
    curl -XGET -u elastic:changeme
  • 澳门新葡亰平台官网 14
  • 注册用户获取基础license,有效期1年,
    注册地址:
  • 申请得到的json文件后,更新license命令:curl -XPUT -u elastic:password
    ” -d @license.json
  • @license.json
    申请得到的json文件,复制文件中的所有内容,粘贴在此
  • 如果提示需要acknowledge,则设置为true,如下:curl -XPUT -u elastic:password

    -d @license.json
  • 参考文档:
  • 其它license
    参见:
  • 澳门新葡亰平台官网 15

Warning: Using apassword on the command line interface can be insecure

如果在批量任务中,这个其实还是会有很多牵制,不能对每一台服务器都设定不同的密码,这个也不大现实,这就有几种策略可以选择:一种是只限定本地可以无密码登录,这个使用相对普遍一些,另外一种就是修改源码,腾讯这些大厂是在源码层将这个warning关闭。第三种就是对于应用的控制也尤其重要,那就是通过域名解析的方式,MySQL中的用户是由user@host两部分共同组成,如下图所示,这个和Oracle等数据库会有鲜明的差别,如果为了省事就设置host为%就是一个潜在的隐患。

2、在MySQL
5.7开始会在初始化后随即生成一个初始密码,可以在初始化日志中查找。内容类似下面的形式:

error.log:2017-02-15T15:47:15.132874+08:001 [Note] A temporary
password is generated for root@localhost: Y9srjpdn9lj p=

3、在mysql.user中默认值为mysql_native_password,不再支持mysql_old_password。

select distinct plugin from mysql.user;

++

|plugin |

++

|mysql_native_password |

++

4、如果查看MySQL密码相关的参数,就会发现存在一个参数

default_password_lifetime,默认参数值为0,可以设置这个参数来控制密码的过期时间。生产系统中可以根据实际情况来进行设定。

5、还有一点对于很多DBA来说需要习惯,那就是MySQL
5.7中只会创建一个root账号,就自动生成临时密码的用户,不再创建其他的账号,之前的版本中会默认生成的test库也不会自动生成了,这个改进虽然很细微,但却能够杜绝心怀侥幸的一些人。

6、而在此基础上如果需要更高一级的安全策略,MySQL
5.7版本提供了更为简单SSL安全访问配置,并且默认连接就采用SSL的加密方式。如果用户的数据传输不是通过SSL的方式,那么其在网络中就是以明文的方式进行传输,这在一定程度上会给别有用心的人带来可乘之机。

MySQL中的无密码登陆

而如果使用无密码的模式来登录,也通过mysql_config_editor来配置,在MySQL
5.6已经发布该特性。

mysql_config_editor的命令提示如下,可以看出可使用的选项还是相对比较简单的。

我们直接可以通过一个命令来完成配置,制定这个无密码登录的别名为fastlogin

[mysql@oel1 ~]$ mysql_config_editor setlogin-path=fastlogin
user=root host=localhost passwordsocket=/u02/mysql/mysqld_mst.sockEnter
password:

配置完成之后,会在当前路径下生成一个隐藏文件.mylogin.cnf

数据库安全的基本法则

而在密码问题之外,还有哪些方面需要注意呢,这也就是我们数据库安全的一些基本法则。

借用Oracle数据库安全面面观文章里的一个图,总结相对全面很多了。

我在这个基础上简单做一些说明和补充。

检查数据库中的默认用户,哪些是近期额外多出来的,做到心中有数。网络层面,系统层面做一些基本的限制,比如防火墙权限控制,这个基本能够杜绝哪些裸奔下的潜在问题。控制用户的权限,不管是哪类数据库,哪怕操作规范多细致,滴水不漏,权限上做不到管控,问题的源头就是问题的无底洞。日志信息的管理和监控。日志可以理解是系统的第三只眼睛,如果存在疑问,日志是相对客观的。敏感信息要加密,例如:姓名、电话、身份证号码、银行账号、用户密码等,包括:敏感数据的屏蔽、数据脱敏、数据加密三个方面。漏洞处理,系统,网络,数据库的漏洞总是会有,这个就需要补充完善了。

而纵观我们常见的一些黑客事件,其实很多都不是软件本身支持得不够好,而是某些方面用户太放得开或者监管不力。

比如从去年的PLSQL
Dev的黑客赎金事件,导致一些用户的Oracle数据库会莫名抛出错误,提示支付比特币来修复,潜伏期有多长,1200多天,一个数据库能够经历3年以上已然是一个相对成熟的系统了。而事情的原因则和有些同学使用了盗版的PLSQL
Dev(即绿色版)有关,你说这个锅是否由Allround Automations公司来背?

其他数据库暂时还没有现成的一套工具防范,我们逐个把必要的建议罗列一下。

对于MongoDB的比特币安全防范,没有工具,云栖社区给出了安全Checklist:

开启鉴权功能:基于用户名和密码完成。基于角色的访问控制:除root角色之外,还有很多预先定义的内建角色,如只读数据库角色等。内部鉴权:内部鉴权的用户名是__system,鉴权数据库是local数据库。Sharding集群的鉴权:Sharding集群的鉴权和副本集鉴权有一定的区别:副本集在Mongod上鉴权,Sharding集群在Mongos上进行鉴权。

当然,开启鉴权势必会带来性能的开销,这是因为鉴权通常需要客户端和服务端进行一些网络交互以及CPU计算。但是与安全相比,这点开销还是应该消耗的。

对于Hadoop,相对而言要简单得多,一个是启用Kerberos,一个是关闭不必要的端口。

HDFSNameNode默认端口:50070SecondNameNode默认端口:50090DataNode默认端口:50075Backup/Checkpoint
Node默认端口:50105YARNResourceManager默认端口:8088JobTracker默认端口:50030TaskTracker默认端口:50060HueHue默认端口:8080

对于ElasticSearch的安全防范,白帽汇给出了这样一些建议:

增加验证,官方推荐并且经过认证的是shield插件。网络中也有免费的插件,可以使用elasticsearch-http-basic,searchguard插件。使用Nginx搭建反向代理,通过配置Nginx实现对Elasticsearch的认证。如果是单台部署的Elasticsearch,9200端口不要对外开放。使用1.7.1以上的版本。在1.7.1以上版本目前还没有爆出过相关漏洞。另外Elasticsearch的官方也有其他产品与Elasticsearch配合紧密的,这些产品也存在漏洞,企业如果有使用其他相关产品存在漏洞也要进行修复,如Logstash,Kibana。加强服务器安全,安装防病毒软件,使用防火墙,网站安装WAF.并对数据库、系统、后台使用的服务设置复杂的密码,建议设置16位的大小写字母+特殊字符+数字组合。

对于CouchDB的安全防范,白帽汇的建议是:

为CouchDB设置复杂密码(字符串,数字,特殊字符),并且长度超过16位。修改默认的用户名,CouchDB默认用户名为admin,请对其进行修改。做好网络隔离。不开启外网访问。

当然还有Redis,在最新一期的DBAplus
Newsletter中,张冬洪老师提供了如下的Redis资讯:

在2015年12月份的时候,
Redis暴出了一个可以利用漏洞获取Redis服务器的root权限,大体情况是:

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

临时解决办法是:

1)配置bind选项,限定可以连接Redis服务器的IP,并修改Redis的默认端口6379。

2)配置AUTH,设置密码,密码会以明文方式保存在redis配置文件中。

3)配置rename-commandCONFIG
“RENAME_CONFIG”,这样即使存在未授权访问,也能够给攻击者使用config指令加大难度。

此漏洞暴出来后,Redis作者Antirez表示将会开发“real
user”,区分普通用户和admin用户权限,普通用户将会被禁止运行某些命令,如config。事隔一年之后,近期又有网友暴漏了Redis的CSRF漏洞,不过这次好在Redis作者在最新发布的3.2.7已经进行了修复,解决方案是对于POST和Host:的关键字进行特殊处理记录日志并断开该链接避免后续Redis合法请求的执行。

漏洞总是不可避免,但是从Redis的使用和管理的角度是不是应当规避一些不必要的风险,尽可能的让Redis运行在一个安全的生产环境中呢?答案不言而喻,下面简单列举几点供参考:

内网访问,避免公网访问;设置访问权限,禁用危险命令;限制Redis服务器登录权限,修改Redis配置的一些默认参数;定期扫描漏洞,关注Redis动态,及时更新版本。

参考链接:

_pages/65

原文作者:杨建荣、杨志洪原文出处:-11-1092-1.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图