【应急响应】redis未授权访问致远程植入挖矿脚本（完结篇）
1 前面两篇尚未完结续，本篇继续
在上上篇【应急响应】redis未授权访问致远程植入挖矿脚本（防御篇）中，从防御的角度详细描述了常规应急响应以及流程。
在上一篇【应急响应】redis未授权访问致远程植入挖矿脚本（攻击篇）中，从日志等入侵痕迹中分析，寻求突破，以一个攻击者的角度还原redis攻击，从未授权访问到写入ssh公钥直至控制整台服务器，进一步确定此次勒索事件的根本原因。
如果是在乙方安全公司，应急响应的工作已经基本结束，剩下的就是交付给用户报告并帮助其修复漏洞。但到了甲方，可以说安全相关工作刚开始不久，对于非巨头或非大型互联网公司，特别是苦于在安全工作上难以推动的企业而言，那便是非常不错的契机。
本篇继续“纵向”和“横向”对此次应急响应事件进行展开，不仅要完成“救火”，更要想到主动去发现火种苗头。
2 牵一发而动全身，纵向深入业务
经过综合的分析与评估，就几台开发环境中的redis服务器被植入挖矿脚本，再也没有找到其他被入侵的痕迹。相关人员也及时处理了恶意脚本、按照安全配置规范对redis进行了加固。
就应急响应工作而言，可能该做的已经做好了，足以应对并向领导交差。但是如果从挖洞的角度来考虑，不难会有以下思考：
1）厂商是否真的修复了呀，会不会有遗漏？
2）厂商是否指哪儿打哪儿，其资产内其他redis服务器应该会存在类似的安全问题？
其中折射出不少常规甲方安全工作问题：
1）一个简单的漏洞涉及部门较多，很可能需要较长时间修复，有时相关技术人员对安全风险的理解不够到位，原本以为已经完美修复实则存有缺陷，这似乎也跟安全人员的综合能力以及安全部门的地位息息相关。如果是在甲方工作的同学，肯定深有体会，漏洞明明还存在，但是开发就是斩钉截铁的说按照修复意见完成修复。
2）又或许是处于安全人员自身素质与安全危机感不够全面的缘故，同一企业中的安全漏洞往往是相似的。如果在某几个应用中发现类似的安全缺陷，那么极有可能就是通病，所以针对redis未授权访问这一缺陷对相关网段扫描或许会有惊喜。
大家都知道攻易守难，攻击者随意找一处企业的漏洞就可能对企业造成巨大伤害。反观防守就需要面面俱到，涉及到的面非常广，需要做到的点远超安全人员手里的资产也是常见的事情。
针对上面提及的两个思考，更加说明甲方的安全人员需要将“安全事件进行到底！”。
2.1 资产搜集
最高效的方法便是从运维童鞋处，获取公司所有对外网段：如果是要求提供所有系统的地址以及服务，对他们而言难度和工作量可能会比较大，但若想要网段的时候还是比较easy。
2.2 服务识别
为了更高效和快速对漏洞（redis未授权访问）进行全网排查，需要对搜集的资产进行服务识别，专门验证redis服务相关的IP地址。自然而然想到的便是端口扫描：nmap、、IP Scanner、Advanced Port Scanner、masscan等利器，若要想有一个不错的展示平台还是推荐巡风（内嵌masscan），然而将上面的资产格式似乎不是巡风能接受的样子：
需要将ip/mask转化为ip地址段，使用IPy中的IP模块即可实现。
#!/usr/bin/env python# -*- coding:utf-8 -*-# Author : aerfa# Function：根据IP与掩码计算输出网段，比如：192.168.0.1/24 ==》 192.168.0.1-192.168.0.255，适用于巡风资产发现时导入 from IPy import IP f = open("IPs.txt", "r") #运维同学提供的IP与掩码lines = f.readlines()#print linesf.close() with open("NewIps.txt", "w") as fp: #转换生成适合巡风的网段 for line in lines: NewIp = IP(line).strNormal(3) fp.write(NewIp + '\n')print "OK!" |
|---|
将网段粘贴进资产网络探测列表中更新，进行筛选后即可获取开放redis服务的主机，比如使用banner:redis进行筛选：
2.3 漏洞扫描
同样地，可以通过以添加插件的形式进行快速批量漏洞扫描，目前巡风作者已经写出相关插件（参考
https://github.com/ysrc/xunfeng/blob/master/vulscan/vuldb/crack_redis.py）。
def check(ip, port, timeout): try: socket.setdefaulttimeout(timeout) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((ip, int(port))) s.send("INFO\r\n") result = s.recv(1024) if "redis_version" in result: return u"未授权访问" elif "Authentication" in result: for pass_ in PASSWORD_DIC: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((ip, int(port))) s.send("AUTH %s\r\n" % (pass_)) result = s.recv(1024) if '+OK' in result: return u"存在弱口令，密码：%s" % (pass_) except Exception, e:pass |
|---|
3 借势而为之，横向开展安全工作
当我们面对安全事件的时候，有时候不仅要将“安全事件进行到底！”，也应该将“安全事件的效果发挥到极致！”。不能老想着吐槽公司领导看似挺重视安全的，实则没有重点关注过安全部门，没有资源没有赋予足够的权利去推行安全工作，或者是安全leader缺乏魄力之类的外在原因。
3.1 工作思路
与其不满，不如改变。对于甲方安全人员而言，个人认为：（仅跟作者所处的公司安全环境相关，每个人的肯定会不太一样）可以承受且没有对公司造成重大损失的安全事件，未必是一件坏事儿。能及时、合理、充分的对待-处置安全事件，不仅有技术能力方面的要求，更需要安全智慧。
首先，我们能想到的：
- 深入分析入侵痕迹，不留残留；
- 积极主动防御，早日跳出“救火”的坑；
其次，我们更应该有意识的往“安全事件推动安全工作开展”方向靠拢。因为在现实工作环境中，安全人员常常遇到：
- 开发对安全漏洞不服气但怕担责任；
- 说入侵不懂，说安全事件造成的危害和损失秒懂；
- 谈防御措施，有可能嫌麻烦不愿意或不积极支持。
3.2 实践方向
为了有效利用此次“redis未授权访问致远程植入挖矿脚本”安全事件，可以组织相关开发、运维等人员参加事件的全程剖析与分享，让大家知道安全的重要性以及忽略安全的危害性。
其次将其展开至正在推动的项目、尚未进行的项目以及类似redis配置不规范导致的安全漏洞，这里不由得引出之前的【漏洞赏析】安全运维那些洞，结合自家的应用情况开展批量已知漏洞检测，稍微更加全面的提升该方面的安全水平。
腾讯云开发者
