RSAC议题解读｜真实云安全事件复盘与思考

2022年RSAC会议上，云安全厂商Mitiga的CTO Ofer Maor带来了题为It’s Getting Real & Hitting the Fan! Real World Cloud Attacks的主题演讲。该演讲回顾了五个真实的云安全事件，并提出了针对性的防护策略。本文将对该演讲进行解读。

一

前言

2022年RSAC会议上，云安全初创公司Mitiga[1]的CTO Ofer Maor带来了题为It’s Getting Real & Hitting the Fan! Real World Cloud Attacks[2]的主题演讲。

该演讲回顾了五个真实的云安全事件：GitHub市场应用的SaaS服务被黑事件、公有云挖矿事件、损失达1500万美元的电子邮箱欺诈事件、MongoDB勒索事件和从本地蔓延到云端的勒索事件。

Ofer Maor指出，时至今日，全世界都在将业务向云上迁移，而攻击和破坏是无法避免的，因此必须承认云上攻击是存在的，应该做的是了解这些攻击、并借助正确的响应措施减少损失。最后，他提出了“了解、准备和响应”三步走的防护策略。

的确，在云上风险事件频发的今天，云计算安全性是迁移上云的企业必须考虑的问题。对此，本文将为带来对这个议题的详细解读，希望您能够有所收获。

注：下文中如未特殊说明，图片均来自该议题的PPT。

二

Mitiga公司简介

Mitiga是一家提供云上事件响应解决方案的初创公司，于2019年在以色列特拉维夫创立。联合创始人有三位，其中首席运营官（COO）Ariel Parnes来自著名的以色列国防军（IDF）8200部队。

作为一家初创公司，Mitiga提供名为IR2（Incident Readiness & Response，事件就绪与响应）的事件响应解决方案，通过收集、分析云上取证数据，将主要取证流程自动化，为专业响应团队提供工具以便快速展开事件调查，减少数据收集时间。

事件一

GitHub市场应用的SaaS服务被黑

2020年6月23日到7月1日间，数字银行应用Dave.com约750万用户数据被黑客窃取并在地下黑客论坛公布[3]（见图1）。追根溯源，整个事件的前因后果如下：

1. Dave.com使用了Waydev在GitHub和GitLab的APP商店中提供的服务，该服务需要用户提供OAuth token，以便访问用户在GitHub和GitLab上的项目。Waydev将这些OAuth token保存在内部数据库中。
2. 黑客利用SQL盲注手法入侵了数据分析公司Waydev的内部数据库，从数据库中窃取了保存的GitHub和GitLab OAuth token [4]。
3. 黑客利用窃取到的OAuth token访问了Dave.com在GitHub上的仓库，从项目代码中获得了明文密码，进而非法访问了Dave.com的系统，成功窃取数据。

图1 - Dave.com数据在地下黑客论坛出售（图片来自ZDNet [3]）

我们从以下三个角度来讨论这次事件：

1. SaaS（Software as a Service，软件即服务）与供应链安全：作为一家SaaS服务提供商，Waydev可能服务许多客户。一旦Waydev被攻破，波及面大小等同于其客户规模。从“责任共担模型”的角度来看，固然Waydev需要承担主要责任，但是如果企业能够对依赖的供应链安全风险建立有效控制机制，则能将自己可能受到的损失降到最小，甚至达到预防效果。
2. DevOps安全：对于Dave.com来说，将敏感信息明文存储在代码仓库中是一种危险行为。一旦代码以某种方式泄露，不法分子就能利用这些敏感信息发起更多攻击。企业应有意识地确保DevOps流程中敏感数据的安全性，以安全的方式存储和使用敏感信息。
3. 攻防技术：可以看到，虽然整个事件和云计算SaaS服务有关，但是全流程涉及到的攻击技术依然是SQL注入、利用明文密码等常见技术。因此，业务上云之后企业依然要注意对传统攻击的防护。

此外，Ofer Maor在议题中还介绍了另一起GitHub APP相关的攻击事件：自动化代码审计工具提供商DeepSource的员工遭受钓鱼邮件攻击，其GitHub账户失陷，最终导致攻击者获取了DeepSource GitHub APP的敏感凭证。这起事件暴露出来的一个值得注意的问题是响应时间过长：2020年5月31日攻击者成功窃取凭证，7月11日GitHub通知DeepSource失陷事件，而DeepSource的客户直到7月21日才从GitHub收到通知。

在本文开头对Mitiga公司的介绍中，我们注意到他们的主推方案的亮点就是“将主要取证流程自动化，为专业响应团队提供工具以便快速展开事件调查，减少数据收集时间”。因此，Ofer Maor在这里点出响应时间过长的问题，既是指出现实问题，也是推广他们的方案。

事件二

公有云挖矿

第二起事件和挖矿有关。在一次事件响应中，团队在18台AWS EC2服务器上都发现了恶意文件root和zzh，其中zzh会下载挖矿程序。TTP说明这起事件与TeamTNT/Watchdog团伙有关。

看起来是一次简单的响应，但是分析发现恶意文件的创建时间与服务器创建时间相同。经过深入分析，调查人员发现该服务器使用的虚拟机镜像（AMI）在创建期间运行了存在错误配置的Redis。攻击者是在镜像创建期间利用脆弱的Redis投放了恶意文件。

很明显，污染虚拟机镜像的软件供应链环节攻击方式要比单独在一台服务器上投放恶意文件的危害要大得多，前者就像污染了水源一样，将直接造成恶意软件利用软件“自来水管道”进行分发，其后果具有规模性。

与此同时，由于镜像的制作方法是公开的，任何人都可以制作镜像，也可以使用任何人公开的镜像。因此，安全意识薄弱的用户很可能直接使用不法分子创建的恶意镜像，在业务环境中引入恶意文件。

事件三

损失惨重的电子邮箱欺诈

2020年4月到9月，黑客通过定向的电子邮箱欺诈盗取了约1500万美元。事件的背景是一次收藏品购买活动。

攻击者首先设法访问了买家的Office 365邮箱，在其中设置了邮件转发规则和过滤规则。转发规则使得卖家发送的邮件都会被转发给攻击者；过滤规则确保买家看不到这封邮件。接着，攻击者注册了虚假的网站用来仿冒卖家，基于虚假网站制作了虚假邮箱，从而与买家通信，最终成功盗取了资金。

由于金额过大，Mitiga联系了FBI对事件进行进一步调查。这是一起利用Office 365的非常巧妙的中间人攻击事件。如今，新冠疫情使得线上办公越来越普遍，电子邮件的使用频率和重要程度也前所未有地提高。企业应该对这类事件保持警惕，一旦发生，后果将十分严重。

事件四

MongoDB勒索攻击

最后两起事件都和勒索病毒有关，但是类型不同。

首先是针对数据库的勒索。在这起事件当中，黑客首先导出了受害者的MongoDB数据库，然后将其数据库内容全部删除，留下一个勒索文档。由于该MongoDB的日志配置不当，能够用来调查的信息十分有限。好消息是，客户对数据库做了全量备份，而且调查发现并没有实际的数据泄露发生，因此客户没有支付勒索赎金，整个事件并未造成严重后果。

从技术角度来讲，这起事件也许过于简单。然而，它体现了客户侧对数据安全的重视。这也符合Ofer Maor倡导的“了解、准备和响应”策略——通过预先备份（做好充足准备）避免了损失。

事件五

从本地蔓延到云端的勒索攻击

最后这起事件与上一起勒索病毒攻击的发起路径不同，是一起典型的跨混合云攻击。

攻击者首先通过钓鱼邮件拿到了目标公司内部管理员的账号。由于该公司配置了多因子登录，攻击者尝试了多次，直到员工批准了登录。接着，攻击者拿到了公司用于提供认证服务的OktaService平台[5]的账号，并利用公司本地环境中的V**连接到了AWS上的云端环境，进而部署了多个工具用于漏洞利用和持久化。最后，攻击者加密了用户服务器上的数据。

这也是一起没有支付赎金的事件。对于服务器来说，客户选择使用之前备份的快照恢复；对于数据来说，安全人员通过分析攻击者用来导出数据的工具，发现了攻击者用来保存导出数据的服务器的访问凭证，最终成功从攻击者的服务器上下载了所有导出数据，并把这些数据从该服务器上删除。

这个案例的最后一部分确实是意料之外的好消息，不过客户预先做的备份也起到了非常大的作用。

三

防护策略：了解、准备和响应

只有承认云上攻击的存在，才愿意去了解实际发生的云上攻击；只有对已经发生过的事件深入了解，才能建立行之有效的防护体系。如何建立防护体系呢？Ofer Maor建议按照“了解、准备和响应”三步走：

图2 - 了解、准备和响应

1. 了解。持续了解已经发生或正在发生的云安全事件，并弄清楚攻击原理和受害者的处置方式。
2. 准备。建立合适的计划、工具和团队，做好应对云上攻击的准备。
3. 响应。依靠快速高效的事件响应技术和团队来减少影响、降低损失。

四

总结

综合来看，这个议题介绍的五大安全事件都没有使用过于复杂高深的技术，但是造成的影响却不容小觑。随着业务上云、业务依赖的供应链上云，不可控的技术因素逐渐增多，企业控制的技术因素在减少。同时，云安全事件的影响具有规模效应，例如，如果公有云服务（从IaaS、PaaS到SaaS）自身存在安全问题，几乎所有用户都会受到影响；如果用户使用的实例镜像（虚拟机、容器等）存在安全问题，从镜像创建的所有实例都会受到影响等。这既会导致潜在损失规模扩大，又会导致事后取证、判定影响范围的难度提高。因此，虽然Ofer Maor指出了“了解、准备和响应”三步走的策略，但是如何走好这三步仍然是一个不容易回答的问题。

另外，针对事件一涉及的源代码仓库安全问题，绿盟科技创新研究院也一直在基于测绘能力跟踪梳理国内外自建源代码仓库服务暴露案例，目前已经孵化出源代码仓库暴露核查服务，自动化进行自建源代码仓库进行测绘和敏感数据、关联实体的分析。如有意愿进一步了解，欢迎联系我们。

参考文献

1. https://www.mitiga.io

2. RSAC 2022 CSCS-R02VP - It’s Getting Real & Hitting the Fan! Real World Cloud Attacks

3. https://www.zdnet.com/article/tech-unicorn-dave-admits-to-security-breach-impacting-7-5-million-users/

4. https://www.zdnet.com/article/hackers-stole-github-and-gitlab-oauth-tokens-from-git-analytics-firm-waydev/

5. https://www.okta.com

内容编辑：创新研究院 阮博男

责任编辑：创新研究院 陈佛忠

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。