记一次云安全的安全事件应急响应

　　传统的安全应急响应相信你们都见过，在以前的博文中也有过介绍。上周末咱们的一个客户发生的虚拟货币丢失事件，咱们安全组介入排查，当时好久都没有头绪，通过某同事的灵光一闪，咱们发现了起色。一句话而言，云计算安全咱们要考虑云计算和虚拟化的一些特性，避免被咱们常见的应急响应思路所限制住。下面来讲说详情，因为部分信息敏感，请原谅马赛克处理：

• 缘由：

　　核心支付代码逻辑被插入了一个陌生的区块链交易地址，每调用这个函数就转走特定的虚拟货币到特定地址。

　　这块涉及一个小的应急知识点，感谢sfish分享，在~/.ssh下存在vim的编辑历史，咱们能够经过这个小黑科技去分析一下对方篡改的文件。

cat ~/.viminfo

• 最百思不得其解也最显而易见的事儿

　　最费解的来自于这段日志。系统发生了一次down机（New seat seat0），说明系统重启过。而后黑客就登陆到了root权限，由于事先的机器sshd文件都只容许公钥登陆，且全部帐户都是强口令。一些都很匪夷所思，为啥重启了一次系统的配置文件都改变了很是的奇怪，难道黑客手里有什么大狠狠的0day咱们不知情？

　　此次应急卡在了这里至关久时间，大约有3个小时，咱们始终难以理解。直到咱们同事说了句不经意的话，我通常攻击阿里云都经过ak接口还原镜像！

　　对关键就在这里，镜像！！平时咱们用虚拟机的时候以为没事作个快照是很顺手的事儿，然而面临生产环境的时候，咱们还以传统的IDC思惟去思考问题，形成了卡壳。由于还原镜像必定会形成一次down机，因此在考虑云计算安全事件的时候镜像自己也是一个不能忽略的点，咱们只考虑到了溢出，弱口令等传统攻击方式，却没有想到黑客能够经过还原镜像进行相应的攻击。最后咱们在客户非本身打包的镜像中，发现了黑客的history记录。

　　剩下的事儿，你们看看也就明白了。

• 总结：

　　这篇文章很是短，但咱们踩过的坑倒是无数的。主要是云计算条件下，镜像是一个很是重要的黑客攻击点。基于ak接口的攻击思路，我会在下片博文中详细赘述。因为事件敏感，本文打了大量的马赛克，但愿你们再云安全应急响应的过程当中可以多学习到一种思路。