云服务器大全记一起阿里云服务器集体中毒事件的分析

腾讯云服务器备份

关于我们

江苏立维互联科技有限公司（简称江苏立维），成立于2015年9月，是一家专注于客户业务安全和稳定的运维服务公司，提供包含咨询、资产管理、软件部署实施、安全防护、监控告警、故障应急响应、活动保障、压力测试、数据库性能优化、融灾、持续集成、运维系统开发等服务。致力于通过专业的服务，帮助企业提升运维能力、降低信息化成本、保障企业的业务稳定和安全，减少企业后顾之忧。

关键词：

阿里云 挖矿 集体中毒 云安全中心 基线检查 Accesskey

事件简述：

2019年12月22日，我们服务的一个客户服务器大面积提示被用于挖矿，随即我们便进行了病毒的清理，但病毒的来源通过我们原有实施的监控和安全检测中并未能发现。事前我们在服务器的远程登录上限制了只允许+堡垒机登录，对服务器的各方面性能、所有人员的风险操作以及可能通过web渗透的异常登录和执行行为均有监控和告警，但这次在服务器监控和安全监控中我们却未找到任何端倪。

发生这次事件之后，我们增加了系统安全审计，网络访问日志等相关的监控和告警。之后几天中，一切暂时归于平静，但在12月26日的时候，客户的服务器集体访问恶意下载源的情况又再次发生了。我们通过网络流量分析、增加操作文件的监控，系统操作审计，分析出访问恶意下载源均来自于名为aliyun-service的程序，但事实真的如此么？

下面我们对此次事件的分析进行还原：

一、环境简介

云平台：阿里云 华北区操作系统：Centos 7.x云安全中心：免费版（基线检查未启用）

二、故障描述

2019年12月22日，阿里云监控提醒通知大部分服务器用于挖矿，检查主机安全问题后，我们手动清理了位于/tmp目录和/home目录下的挖矿病毒。前期我们在客户服务接入的期间，已经对每个客户的服务器都进行了主机、操作记录的审计，但这样的日志并没有帮助我们排查出具体病毒攻击根源（当时怀疑可能是阿里云底层平台触发了此类的事件）。

2019年12月26日13点39分，阿里云再次提醒服务器批量访问恶意下载源（未执行挖矿程序），安全事件再次暴露，表示很头大，但我们坚信一定可以找到蛛丝马迹，为了定位到这个根本原因，我们增加了文件目录的变更监控，同时增加了网络的请求和监控，也就是通过文件的监控和网络请求的监控，帮我们分析出问题的原因。下面将整个安全事件分析的过程在此进行复盘。

三、处理过程

（1）增加操作审计

利用audit开启Linux操作审计功能，生成日志路径/var/log/audit.log

auditctl -a always,exit-F arch=b64 -Sopen-F auid=0

启用我操作系统目录监控（前期发现这两个目录存在挖矿病毒下载的情况）

auditctl-w /tmp -p rwxaauditctl-w /home -p rwxa

（2）配置网络连接监控

oracle云数据库服务器

使用linux 自带防火墙开启日志记录

iptables -I INPUT -j LOG --log-leve 5 --log-prefix"IPTABLES"

查看网络请求日志/var/log/messages可以看到详细的网络连接请求记录。

为了能第一时间发现病毒，我们将操作系统审计日志接入立维日志平台。并对关键字进行实时的监控和报警，提取审计日志文件中存在trace.tgz关键字，出现异常第一时间通知到负责人。

通过对/tmp目录的审计，发现/tmp/目录下的t-bj-5s2hkk2ajnk.sh脚本文件是由auid为4294967295的aliyun-service这个服务进行创建。

根据auid的日志分析，我们进入/usr/local/share/aliyun-assist/1.0.1.402/ 目录发现存在log文件目录，检查aliyun_assist_main.log 日志，可以判断当前commandContent 字段中的内容base64编码。

阿里云服务器 中文

转码后内容如下：

（5）分析脚本文件

我们再去查看/tmp目录下文件，发现存在两个脚本文件。

查看文件内容发现和我们刚才base64转码后内容一致

我们登陆阿里云后台安全中心，看到系统有大量进程异常下载安全报警，我们点击其中一个安全事件，发现系统执行恶意shell代码。

通过这些分析对比，我们在心中难免出现疑问，客户主机的集体中毒，难道和阿里云有关？

为了进一步确认此事，我们又进行如下验证。

验证一：其他主机是否也是同样的执行方式

(1)我们登陆到mysql-test主机，在/tmp目录下看到 t-bj05top2t31reo.sh脚本文件

(2)利用同样的分析方式分析了audit系统操作审计日志：

从日志中我们可以看到/usr/local/share/aliyun-assist/1.0.1.402/aliyun-service 进程创建t-bj05top2t31reo.sh脚本且执行该脚本。查看系统应用日志可以明显看到整个脚本执行过程，

结论：到目前为止我们基本确认该病毒的下载事件源是aliyun-service 这个进程发起，能对云平台底层进行操作的，是可以获取云平台底层权限的，所以我们又进行了另外两种方式的验证。

验证二：是否是通过基线检查提交恶意代码进行批量执行

结论：从刚开始的阿里云安全事件告警截图中我们也可以看出，客户的基线检查并未开通企业版，属于免费版本，不存在自定义配置的可能性，所以该可能性排除。

验证三：客户的管理员级别accesskey被泄漏

我们查看云平台API接口文档，发现和之前查看的日志格式基本一致,也进一步确认有这样的API可以进行服务器批量操作和执行。我们进行了github的检索确认，的确有研发人员将Accesskey的信息暴露在了公网，紧急联系客户删除对应的代码，至此，阿里云集体中毒的安全事件处理告一段落。

最终结论：综上分析，本次阿里云集体中毒事件的根本原因是由于客户程序员安全意识不够，将accesskey泄漏在公网被利用所致。

四、总结

虽然经过了一些辛苦而曲折的排查，问题的根源总算找到，但同时也暴露出我们的一些问题

1、我们在监控体系的建设和落地方面还需要进一步加强细化，我们要做好云平台之外的监控体系，帮助客户更早的发现问题。

2、再次看到日志的重要性，全面的日志收集、保留、分析、告警是我们快速发现和定位问题的重要依据。

3、加强对云平台体系的研究学习，如果我们对云平台API功能有更多了解，可以更早的定位到问题的原因。

最后，感谢阿里云开放平台团队的支持，帮我们弥补了对云平台API知识的欠缺，为以后快速定位、分析问题奠定了良好的基础，我们也会不断加强自身在云平台知识体系的学习，更好的为客户做好服务。

云管理服务器