一把万能钥匙引发的惨案

“风险提示：检测到服务器在马来西亚异地登录，请前往主机安全查看详情。” 某个周日晚上22:00，A公司的安全运维工程师马工收到一条异地IP登录的告警。

马工顿感不妙，冲进书房打开电脑登录系统后台，快速浏览告警详情，发现服务器的安全组新增了入方向0.0.0.0:22端口权限。

没有运维人员在马来西亚，也没有服务器的ssh端口直接对外，公司正常的访问都是要通过内网或堡垒机连接服务器。"肯定又是哪个Accesskey丢了。"马工十分笃定。在这半年内，公司已经第三次发生这类事件了。

“我们在几台机器上发现了异常登录和来源不明的命令，应该是Accesskey丢了，不知道影响面有多大，麻烦你们今天来排查一下吧。”第二天早上9:00，马工立马联系了腾讯安全的周工。

周末晚上，马工和他的同事们已经把排查出所有被修改的安全组，并删除了新增的异常配置。然而，这仅仅是一个暂时的止损措施，因为他们目前仍然不清楚究竟是哪个密钥丢失，以及有多少台服务器被黑客登录或者执行恶意命令，攻击者还有哪些异常操作。这意味着攻击者仍然有可能在任何时间再次发起攻击。

“可能又是一把‘万能钥匙’吧。”周工心想。这样的场景他见得太多了。

所谓accesskey，就是访问密钥，是用户访问公有云API进行身份验证时需要用到的安全凭证，由SecretId和SecretKey一起组成。 

一把钥匙对应一把锁，越是保管贵重物品的钥匙要越少人接触到，这似乎是常识。但是，很多企业缺乏安全风险意识，密钥管理较为松散，常常为了方便业务的API调用，一个密钥同时给许多个业务使用，甚至是把最紧要的ROOT账号密钥给到普通员工，让普通账号拥有高级读写操作权限，包括对COS存储和CVM下发命令等。‍

这就存在极大的安全隐患，如果是黑客获取了访问密钥，就等于拿到了一把“万能钥匙”。攻击者获取密钥后就等于拿到了服务器和数据库的权限，可以窃取数据或者加密勒索等等，任何一种攻击都可能对企业造成无法挽回的损失。

值得一提的是，密钥丢失事件屡见不鲜。密钥是一段未加密的明文字符串，很多运维人员会把密钥存放在Github或者业务代码里，导致密钥轻松被攻击者窃取。在这两年的攻防演练中，很多企业都因为密钥丢失吃了大亏。

马工很快整理出了一份安全简报，上面记载了告警时间、信息，异地登录的机器IP和它下发过指令的机器列表。除此之外没有更多可用信息。

做安全策略，很容易想到的一个方式是建立“用户行为基线”：一个正常的用户通常会在相对固定的设备、固定的IP地址登录，在固定的时间段使用密钥调用API，安全部门可以据此建立一个正常用户的行为画像，一旦用户超出这个基线，例如在海外登录或者在高危服务接口首次调用，就推送给人工去做二次确认。

但由于上一节说到的，一个密钥给多个业务同时用并且权限没有收敛的原因，涉事密钥的行为没有“基线”可言，就好比一个视频网站的会员账号被人在某宝上卖给20个人使用，登录设备和地址五花八门，浏览记录里就同时有动画片、谍战剧、古偶、言情、曲艺杂谈，丰富之程度，在这种情况下，很难准确判断哪些是正常用户，哪些场景是被盗号了。这种混乱的情况增加了安全事件的复杂性。

“因为是马来西亚登录，不太可能是正常访问，所以我们麻着胆子把它更改的安全组删了。如果是国内IP的话，我们还真的不敢动，别一不小心哪个业务说API调用不了系统瘫了来找我们麻烦，那今年一年的班都白加了。”马工说道。

“看来你们还是没有整改呀。”周工叹了一口气。

“改？这都多少年的历史遗留问题了，改起来哪有那么容易。”马工。

发生这样的对话，是因为前面也提到，A公司这样的密钥泄露事件光是今年就发生过3起了。

周日之后，主机没有再发出关联的告警，由于安全组被删掉了，黑客应该知道它已经暴露，为了不被连根拔起，他们也采取了偃旗息鼓的战术：苟起来，等待下一个时机。

这显然是一个极其有耐心的APT（高级持续威胁）组织，他们做事不带个人感情色彩，不会选择和企业的安全部门中门对狙——他们只要钱。A公司所在的行业对于数据失窃、业务中断的风险容忍能力极低，所以这个组织专门对该行业客户下手。周工在其他客户应急响应中也曾与他们交锋过。“用的工具、攻击手法、命名方式和外联IP段都很相似。他们曾经在一家公司的系统里潜伏了半年以上，在几台服务器上装了rookit后门，从后门进进出出，如入无人之境。”

不过，既然这次攻击者留下了“脚印”，那就跟进脚印看看他都去过哪些地方。

“主机入侵路径是：攻击者通过窃取的访问密钥——通过云API对安装了自动化助手的服务器下发命令——写入SSH Key——更改安全组，再通过SSH公钥访问服务器。”周工说，知己知彼，方能百战不殆。

周工像个老刑警一样，开始了“侦查”：

• 第一步，梳理所有的云审计日志，敏感写操作快速定位到丢失的密钥（来源IP在国外），根据丢失的密钥，查询相关日志，并通过时间线分析其活动。这包括检查是否修改了安全组、新增了子账号，或者下发了命令等。把它走的路全部再重新走一遍，还原‘案’发经过。”

• 第二步，在主机安全端，根据事件调查日志，调取原始进程链信息，重点分析腾讯云的自动化助手命令下发日志（tat_agent），看对哪些机器进行下发过命令，二次确认异常的服务器列表。

“先查一周内的日志，再倒查过去一个月的。如果还没有找到最开始的源头，还要倒查过去半年的。”周工说，“处理这种入侵事件，必须要对密钥的利用方式、特征比较熟悉，并且要有完整的数据来佐证，很依赖于专家的经验。”

从早上九点多到下午七八点，周工花了一整天时间，终于把丢失的密钥和它的痕迹都复现出现，该删掉的安全组、子账号删掉，该更改的密钥更改，算是扑灭了这一次的危机。

但是他不敢保证这样的事情下次不会再发生。

周工一年要处理几十起这样的密钥丢失的事件。对于他来说，最困扰他的事情有两点：

一、密钥管理不善、权限没有做最小化处理是这些客户共同的病因。“如果‘一事一钥，一钥一人’，那么密钥丢失后，马上就知道是哪里出了问题，直接封禁就可以，现在是知道泄露了也不敢随便封禁，因为有太多正常的开发运维人员也在用这个密钥。”周工说，“在分配密钥的时候COS对象存储、CVM命令下发这两个权限需要特别注意，这是当前攻击者获取密钥后的主要利用路径。”

但是即便知道问题的原因和对策，真正做起来也很难，一个企业的IT系统是无数个系统的叠加，牵一发而动全身，谁也不敢贸贸然地发起大的整改。所幸很多企业都意识到了密钥问题带来的隐患，而且IT系统都有它的生命周期，随着新系统上线、老系统的更新迭代，这些问题也会缓慢地得到改善。只不过，在未来可预期的时间内，周工仍然要去处理很多这样的密钥丢失事件。

二、排查丢失的密钥和它的行为路径，没有称手的“兵器”。“最多的时间是在花在日志审计上，而目前绝大多数厂商的日志审计功能不完善，需要花费大量的精力‘人肉’处理。”周工说，腾讯云安全中心即将上线相应的功能，来帮助客户提高密钥管控、梳理密钥权限、自动化发现异常行为并告警。主机安全端也对各云厂商的自动化助手进程进行了重点监控和异常告警。

云安全中心aksk异常检测产品设计图

此外，腾讯安全还计划在云上布上更多的“红外监控”，攻击者想要进入用户的机器或者业务系统，需要绕开这些“监控”，难度会成倍提升（嘘，此处详情就不方便多说了）。

周工说，他无法改变密钥的现状，唯一能做的就是精进技艺，和团队一起打磨更好的“武器”，在下一次客户有需要的时候，他能比上一次更快速地帮助客户扑灭火苗，找到起火点。

- END -

原文始发于微信公众号（腾讯安全）：一把“万能钥匙”引发的惨案