将安全事件进行到底-记redis未授权访问致远程植入挖矿脚本事件的应急响应

前言

本文为小编前同事写的日常工作总结，文中体现出了一位安全服务人员从乙方到甲方的视角转变，其中技术分析与安全工作的思想值得与大家分享。

当我们面对安全事件的时候，有时候不仅要将“安全事件进行到底！”，也应该将“安全事件的效果发挥到极致！”。不能老吐槽公司领导看似挺重视安全的，实则没有重点关注过安全部门，没有资源没有赋予足够的权利去推行安全工作，或者是安全leader缺乏魄力之类的外在原因。

安全事件应急处置工作， 如果是在乙方安全公司，应急响应的工作结束，剩下的就是交付给用户报告并帮助其修复漏洞。但到了甲方，对于非巨头或非大型互联网公司，特别是苦于在安全工作上难以推动的企业而言，那便是非常不错的契机。

记得刚到公司不久，便遇到安全事件发生。因为之前没有人处理过、没人会太在意，所以当我看到时、非常吃惊大家的不在意，内网几台服务器被远程植入挖矿脚本，情况别说有多么危急了。

就应急响应工作而言，当安全事件处置完后，足以应对并向领导交差。但是如果从挖洞的角度来考虑，不难会有以下思考：厂商是否真的修复了呀，会不会有遗漏？厂商是否指哪儿打哪儿，其资产内其他redis服务器应该会存在类似的安全问题？其中折射出不少常规甲方安全工作问题：

一个简单的漏洞涉及部门较多，很可能需要较长时间修复，有时相关技术人员对安全风险的理解不够到位，原本以为已经完美修复实则存有缺陷，这似乎也跟安全人员的综合能力以及安全部门的地位息息相关。如果是在甲方工作的同学，肯定深有体会，漏洞明明还存在，但是开发就是斩钉截铁的说按照修复意见完成修复。

又或许是处于安全人员自身素质与安全危机感不够全面的缘故，同一企业中的安全漏洞往往是相似的。如果在某几个应用中发现类似的安全缺陷，那么极有可能就是通病，所以针对redis未授权访问这一缺陷对相关网段扫描或许会有惊喜。

大家都知道攻易守难，攻击者随意找一处企业的漏洞就可能对企业造成巨大伤害。反观防守就需要面面俱到，涉及到的面非常广，需要做到的点远超安全人员手里的资产也是常见的事情。针对上面提及的两个思考，更加说明甲方的安全人员需要将“安全事件进行到底！”。

0x01redis被远程植入挖矿脚本事件分析

1 安全事件描述

1.1 开发服务器被勒索

按照提示访问该链接，

https://www.zerobin.net/?abe30023883da9e6#s3HY7/0chzaTWdEtKSw86/WKkprj7x3NEEf9usy6JRs=显示该主机已经感染RANSOMWARE比特币敲诈病毒，要想避免服务器上的文件信息泄露需要想向黑客支付2个比特币。

1.2 redis主机被植入挖矿脚本

经过文件排查，以下四台主机被人植入挖矿脚本。

2 重要日志备份

2.1 系统日志

包括message、secure、cron、mail等系统日志。

压缩打包整个/var/log目录至/tmp:

2.2 history备份

备份history至/tmp/history.txt，用于查看恶意攻击者执行了哪些操作。

3 系统状态查看

系统状态主要包括网络、服务、端口、进程等状态，是否存在异常。

3.1 查看在线用户（未见异常账户）

3.2 查看系统服务（待确定）

系统开启服务较多，难以排查。

通过该命令可以查看哪些服务可能存在安全漏洞。

3.3 查看当前进程（待确定）

3.4 查看开放端口（待确定）

3.5 查看用户信息（待确定）

由于涉及到的业务较多，不能确定用户的归属。

3.6 查看最近一个月更改的文件（后门文件）

4 异常行为分析

4.1 从执行命令记录分析(存在可疑操作)

查看备份文件history.txt，分析命令执行历史，可疑行为有以下两点（待确认是否为公司内部人员操作）

4.2 从近期更改文件分析

查看最近一个月的文件更改情况并查看文件内容找到以下几个恶意文件（挖矿脚本）

经过全盘排查，涉及到的目录有：

4.2.1 分析root根目录（存在后门文件）

首先直接查看根目录，存在可执行文件

4.2.2 分析tmp文件夹（存在后门文件）

查看/tmp文件夹，存在大量后门文件

挖矿脚本等恶意脚本存放在/tmp目录下

分析root文件：

执行root文件，远程下载 i.sh，http://218.38.3.16:9999/i.sh?6379

分析i.sh文件

该文件设置定时任务，下载挖矿脚本至tmp文件夹

4.2.3 分析计划任务文件夹（存在后门文件）

查看计划任务文件夹，存在后门文件

查看文件夹 /var/spool/cron/crontabs，同样发现恶意脚本

分析/tmp/.f53ee86432aa62ba4f37a00893d1acd2文件

执行.d41d8cd98f00b204e9800998ecf8427e文件，

分析.d41d8cd98f00b204e9800998ecf8427e文件：

使用base64解密.d41d8cd98f00b204e9800998ecf8427e内容：

对system函数里的内容进行十六进制转换字符，可初步获知：

从65.254.63.2远程服务器上下载a脚本，先执行并删除。

4.2.4 分析etc计划任务文件（源后门文件）

查看计划任务文件夹，存在后门文件anacron。该文件主要是控制远程下载、主机计划任务设置等黑客行为。

4.3 评估影响范围

经过对各个后门文件的分析，在/tmp目录中存在H文件，其内容包含内网相关主机，疑似是恶意攻击者的攻击目标：

分别登录主机x.x.x.x、x.x.x.a、x.x.x.b、x.x.x.c的ssh failed日志进行分析，发现以下登录失败记录（标红主机也需要关注）：

5 恶意脚本排查

5.1 webshell查杀

使用webshell查杀脚本进行扫扫描

查看web应用路径为：/httx/run/

上传并执行scanWebshell.py

扫描完成，未扫到webshell文件。

5.2 rootkit恶意程序检测

rkhunter是Linux系统平台下的一款开源入侵检测工具，具有非常全面的扫描范围，除了能够检测各种已知的rootkit特征码以外，还支持端口扫描、常用程序文件的变动情况检查。

结合目前的检查情况和未经允许安装rkhunter来看，该操作尚未进行。

6 回溯攻击源头

6.1 挖矿脚本提供站点

访问http://218.38.3.16:9999/，这是攻击者一个提供恶意脚本下载的网站

查看该IP地址来源于韩国

6.2 恶意文件提供站点

访问http://65.254.63.2/a，浏览器提示欺诈网站

查看该IP地址来源于美国

7 安全加固防范

7.1 控制影响范围

首先应对x.x.x.x进行下线（断绝外网）处理，阻断与外界恶意攻击者之间的通信，但是由于很多业务都在上面运行实施起来有一定难度。

其次，应该对以下疑似被攻击的主机进行安全排查，查找是否存在webshell、后门下载文件及挖矿文件。

7.2 删除后门文件

为了避免继续被控制以及更多内网主机沦陷，需要及时清理掉已经发现的后门文件及计划任务（暂时发现上面提到的四个路径）。

7.3 安全漏洞扫描

由于被入侵的可能性存在多种可能性，比如：

（1） 由于之前的钓鱼邮件引发的apt攻击

（2） 可能与最开始发现的redis挖矿安全事件相关

（3） 有可能由于该服务器上业务太多且开放端口全部映射到外网导致恶意攻击者攻击，即打开内网大门的钥匙……

0x02redis被远程植入挖矿脚本攻击分析

从日志等入侵痕迹中分析，寻求突破，以一个攻击者的角度还原redis攻击，从未授权访问到写入ssh公钥直至控制整台服务器。

1 入侵痕迹

查看近期文件更改情况，查看最近一个月更改的文件

服务器上查看可疑文件，使用root账号登录x.x.x.x，在根目录下查看ssh相关的可疑文件。

进入ssh文件夹，查看ssh文件内容：

2 漏洞排查

bash漏洞扫描：从执行命令记录分析，可疑操作：测试bash远程解析命令执行漏洞的poc语句。

因此对该主机进行漏洞扫描，未发现存在bash漏洞。

redis未授权访问漏洞验证：使用redis客户端尝试连接x.x.x.x成功，且发现ssh公钥

执行服务器操作指令，获取redis以及服务器基本信息：

获取cat:

设置redis备份路径（以此说明redis权限过大，具有root权限）

攻击过程分析：

通过结合服务器被入侵痕迹与漏洞情况进行分析，判定：主机x.x.x.x由于Redis未授权访问漏洞，造成SSH免密码登录。

为了更好地理解该主机如何被入侵至沦陷，现将模拟黑客手法还原整个攻击过程。

1）kali下本地生成公私钥

2）公钥写入文件

3） 连接redis写入文件

4） redis客户端确认写入情况

sectest20170410写入成功

5） linux任务计划设置权限

有时候在利用redis写公钥后依然不能空密码登录，可能是由于authorized_keys的权限问题，可通过linux任务计划来设置权限为600

6） ssh公钥成功空密远程登录

4 全面排查

为了更高效和快速对漏洞（redis未授权访问）进行全网排查，需要对搜集的资产进行服务识别，专门验证redis服务相关的IP地址。自然而然想到的便是端口扫描：nmap、、IP Scanner、Advanced Port Scanner、masscan等利器，若要想有一个不错的展示平台还是推荐巡风（内嵌masscan），然而将上面的资产格式似乎不是巡风能接受的样子：

需要将ip/mask转化为ip地址段，使用IPy中的IP模块即可实现。

将网段粘贴进资产网络探测列表中更新，进行筛选后即可获取开放redis服务的主机，比如使用banner:redis进行筛选：

同样地，可以通过以添加插件的形式进行快速批量漏洞扫描，目前巡风作者已经写出相关插件（参考

https://github.com/ysrc/xunfeng/blob/master/vulscan/vuldb/crack_redis.py）。

5 修复建议

权限设置

将redis权限设置为最小化权限，禁止使用root权限运行。区分普通用户和admin权限，普通用户将会被禁止运行某些命令，如config。

端口设置

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

强口令设置

对redis设置强口令，禁止未授权访问。

0x03redis被远程植入挖矿脚本事件总结

经过综合的分析与评估，就几台开发环境中的redis服务器被植入挖矿脚本，再也没有找到其他被入侵的痕迹。相关人员也及时处理了恶意脚本、按照安全配置规范对redis进行了加固。

当我们面对安全事件的时候，有时候不仅要将“安全事件进行到底！”，也应该将“安全事件的效果发挥到极致！”。不能老想着吐槽公司领导看似挺重视安全的，实则没有重点关注过安全部门，没有资源没有赋予足够的权利去推行安全工作，或者是安全leader缺乏魄力之类的外在原因。

与其不满，不如改变。对于甲方安全人员而言，个人认为：（仅跟作者所处的公司安全环境相关，每个人的肯定会不太一样）可以承受且没有对公司造成重大损失的安全事件，未必是一件坏事儿。能及时、合理、充分的对待-处置安全事件，不仅有技术能力方面的要求，更需要安全智慧。

首先，我们能想到的：

深入分析入侵痕迹，不留残留；

积极主动防御，早日跳出“救火”的坑；

其次，我们更应该有意识的往“安全事件推动安全工作开展”方向靠拢。因为在现实工作环境中，安全人员常常遇到：

开发对安全漏洞不服气但怕担责任；

说入侵不懂，说安全事件造成的危害和损失秒懂；

谈防御措施，有可能嫌麻烦不愿意或不积极支持。

为了有效利用此次“redis未授权访问致远程植入挖矿脚本”安全事件，可以组织相关开发、运维等人员参加事件的全程剖析与分享，让大家知道安全的重要性以及忽略安全的危害性。将其展开至正在推动的项目、尚未进行的项目以及类似redis配置不规范导致的安全漏洞。

这里不由得引出之前的【漏洞赏析】安全运维那些洞，结合自家的应用情况开展批量已知漏洞检测，稍微更加全面的提升该方面的安全水平。

图文来源：公众号“我的安全视界观”，经作者授权转载。